[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAAmzW4Otq7EaxyyPa7tJAjVp3JxdrH2+b+nP=wvffCNdpskC8w@mail.gmail.com>
Date: Sat, 6 Feb 2016 01:28:42 +0900
From: Joonsoo Kim <js1304@...il.com>
To: Christoph Lameter <cl@...ux.com>
Cc: Joonsoo Kim <iamjoonsoo.kim@....com>,
Andrew Morton <akpm@...ux-foundation.org>,
Pekka Enberg <penberg@...nel.org>,
David Rientjes <rientjes@...gle.com>,
Linux Memory Management List <linux-mm@...ck.org>,
LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] mm/slub: support left red zone
2016-02-05 18:06 GMT+09:00 Christoph Lameter <cl@...ux.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.
Powered by blists - more mailing lists