All of lore.kernel.org
 help / color / mirror / Atom feed
From: Joonsoo Kim <js1304@gmail.com>
To: Christoph Lameter <cl@linux.com>
Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Pekka Enberg <penberg@kernel.org>,
	David Rientjes <rientjes@google.com>,
	Linux Memory Management List <linux-mm@kvack.org>,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] mm/slub: support left red zone
Date: Sat, 6 Feb 2016 01:28:42 +0900	[thread overview]
Message-ID: <CAAmzW4Otq7EaxyyPa7tJAjVp3JxdrH2+b+nP=wvffCNdpskC8w@mail.gmail.com> (raw)
In-Reply-To: <alpine.DEB.2.20.1602050300130.13917@east.gentwo.org>

2016-02-05 18:06 GMT+09:00 Christoph Lameter <cl@linux.com>:
> On Thu, 4 Feb 2016, Joonsoo Kim wrote:
>
>> On Thu, Feb 04, 2016 at 03:15:50PM +0900, Joonsoo Kim wrote:
>> > SLUB already has red zone debugging feature. But, it is only positioned
>> > at the end of object(aka right red zone) so it cannot catch left oob.
>> > Although current object's right red zone acts as left red zone of
>> > previous object, first object in a slab cannot take advantage of
>>
>> Oops... s/previous/next.
>>
>> > this effect. This patch explicitly add left red zone to each objects
>> > to detect left oob more precisely.
>
>
> An access before the first object is an access outside of the page
> boundaries of a page allocated by the page allocator for the slab
> allocator since the first object starts at offset 0.
>
>
>
> And the page allocator debugging methods can catch that case.
>
>
> Do we really need this code?

Someone complained to me that left OOB doesn't catched even if
KASAN is enabled which does page allocation debugging.
That page is out of our control so it would be allocated when left
OOB happens and, in this case, we can't find OOB.
Moreover, SLUB debugging feature can be enabled without page
allocator debugging and, in this case, we will miss that OOB.

Before trying to implement, I expected that changes would be
too complex, but, it doesn't look that complex to me now. Almost
changes are applied to debug specific functions so I feel okay.
It is just my feeling so if you think that it's complexity offsets benefit,
I will not strongly insist to merge this patch.

Thanks.

WARNING: multiple messages have this Message-ID (diff)
From: Joonsoo Kim <js1304@gmail.com>
To: Christoph Lameter <cl@linux.com>
Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Pekka Enberg <penberg@kernel.org>,
	David Rientjes <rientjes@google.com>,
	Linux Memory Management List <linux-mm@kvack.org>,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] mm/slub: support left red zone
Date: Sat, 6 Feb 2016 01:28:42 +0900	[thread overview]
Message-ID: <CAAmzW4Otq7EaxyyPa7tJAjVp3JxdrH2+b+nP=wvffCNdpskC8w@mail.gmail.com> (raw)
In-Reply-To: <alpine.DEB.2.20.1602050300130.13917@east.gentwo.org>

2016-02-05 18:06 GMT+09:00 Christoph Lameter <cl@linux.com>:
> On Thu, 4 Feb 2016, Joonsoo Kim wrote:
>
>> On Thu, Feb 04, 2016 at 03:15:50PM +0900, Joonsoo Kim wrote:
>> > SLUB already has red zone debugging feature. But, it is only positioned
>> > at the end of object(aka right red zone) so it cannot catch left oob.
>> > Although current object's right red zone acts as left red zone of
>> > previous object, first object in a slab cannot take advantage of
>>
>> Oops... s/previous/next.
>>
>> > this effect. This patch explicitly add left red zone to each objects
>> > to detect left oob more precisely.
>
>
> An access before the first object is an access outside of the page
> boundaries of a page allocated by the page allocator for the slab
> allocator since the first object starts at offset 0.
>
>
>
> And the page allocator debugging methods can catch that case.
>
>
> Do we really need this code?

Someone complained to me that left OOB doesn't catched even if
KASAN is enabled which does page allocation debugging.
That page is out of our control so it would be allocated when left
OOB happens and, in this case, we can't find OOB.
Moreover, SLUB debugging feature can be enabled without page
allocator debugging and, in this case, we will miss that OOB.

Before trying to implement, I expected that changes would be
too complex, but, it doesn't look that complex to me now. Almost
changes are applied to debug specific functions so I feel okay.
It is just my feeling so if you think that it's complexity offsets benefit,
I will not strongly insist to merge this patch.

Thanks.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  reply	other threads:[~2016-02-05 16:28 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-02-04  6:15 [PATCH] mm/slub: support left red zone Joonsoo Kim
2016-02-04  6:15 ` Joonsoo Kim
2016-02-04  6:21 ` Joonsoo Kim
2016-02-04  6:21   ` Joonsoo Kim
2016-02-05  9:06   ` Christoph Lameter
2016-02-05  9:06     ` Christoph Lameter
2016-02-05 16:28     ` Joonsoo Kim [this message]
2016-02-05 16:28       ` Joonsoo Kim
2016-02-05  8:58 ` Christoph Lameter
2016-02-05  8:58   ` Christoph Lameter

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAAmzW4Otq7EaxyyPa7tJAjVp3JxdrH2+b+nP=wvffCNdpskC8w@mail.gmail.com' \
    --to=js1304@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=cl@linux.com \
    --cc=iamjoonsoo.kim@lge.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=penberg@kernel.org \
    --cc=rientjes@google.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.