Re: [PATCH v3 09/13] mm: slub: add kernel address sanitizer support for slub allocator

[Dmitry Vyukov]

On Fri, Sep 26, 2014 at 7:22 AM, Christoph Lameter <cl@xxxxxxxxx> wrote:
> On Thu, 25 Sep 2014, Dmitry Vyukov wrote:
>
>> > +       depends on SLUB_DEBUG
>>
>>
>> What does SLUB_DEBUG do? I think that generally we don't want any
>> other *heavy* debug checks to be required for kasan.
>
> SLUB_DEBUG includes the capabilties for debugging. It does not switch
> debug on by default. SLUB_DEBUG_ON will results in a kernel that boots
> with active debugging. Without SLUB_DEBUG_ON a kernel parameter activates
> debugging.

Ack
thanks for explanation


>> > +{
>> > +       unsigned long size = cache->size;
>> > +       unsigned long rounded_up_size = round_up(size, KASAN_SHADOW_SCALE_SIZE);
>> > +
>>
>> Add a comment saying that SLAB_DESTROY_BY_RCU objects can be "legally"
>> used after free.
>
> Add "within the rcu period"
>
>> >  static struct page *new_slab(struct kmem_cache *s, gfp_t flags, int node)
>> > @@ -1416,8 +1426,10 @@ static struct page *new_slab(struct kmem_cache *s, gfp_t flags, int node)
>> >                 setup_object(s, page, p);
>> >                 if (likely(idx < page->objects))
>> >                         set_freepointer(s, p, p + s->size);
>>
>> Sorry, I don't fully follow this code, so I will just ask some questions.
>> Can we have some slab padding after last object in this case as well?
>
> This is the free case. If poisoing is enabled then the object will be
> overwritten on free. Padding is used depending on the need to align the
> object and is optional. Redzoning will occur if requested. Are you asking
> for redzoning?

I am not asking for redzoning yet.


>> kasan_mark_slab_padding poisons only up to end of the page. Can there
>> be multiple pages that we need to poison?
>
> If there is a higher order page then only the end portion needs to be
> poisoned. Objects may straddle order 0 boundaries then.
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/