Re: [PATCH v6] mm, kasan: switch SLUB to stackdepot, enable memory quarantine for SLUB

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Jul 12, 2016 at 03:02:19PM +0200, Alexander Potapenko wrote:
> >> +
> >>       /* Add alloc meta. */
> >>       cache->kasan_info.alloc_meta_offset = *size;
> >>       *size += sizeof(struct kasan_alloc_meta);
> >> @@ -392,17 +385,36 @@ void kasan_cache_create(struct kmem_cache *cache, size_t *size,
> >>           cache->object_size < sizeof(struct kasan_free_meta)) {
> >>               cache->kasan_info.free_meta_offset = *size;
> >>               *size += sizeof(struct kasan_free_meta);
> >> +     } else {
> >> +             cache->kasan_info.free_meta_offset = 0;
> >>       }
> >>       redzone_adjust = optimal_redzone(cache->object_size) -
> >>               (*size - cache->object_size);
> >> +
> >>       if (redzone_adjust > 0)
> >>               *size += redzone_adjust;
> >> -     *size = min(KMALLOC_MAX_CACHE_SIZE,
> >> +
> >> +#ifdef CONFIG_SLAB
> >> +     *size = min(KMALLOC_MAX_SIZE,
> >>                   max(*size,
> >>                       cache->object_size +
> >>                       optimal_redzone(cache->object_size)));
> >> -}
> >> +     /*
> >> +      * If the metadata doesn't fit, don't enable KASAN at all.
> >> +      */
> >> +     if (*size <= cache->kasan_info.alloc_meta_offset ||
> >> +                     *size <= cache->kasan_info.free_meta_offset) {
> >> +             *size = orig_size;
> >> +             return;
> >> +     }
> >> +#else
> >> +     *size = max(*size,
> >> +                     cache->object_size +
> >> +                     optimal_redzone(cache->object_size));
> >> +
> >>  #endif
> >
> > Hmm... could you explain why SLAB needs min(KMALLOC_MAX_SIZE, XX) but
> > not SLUB?
> 
> Because if the size is bigger than KMALLOC_MAX_SIZE then
> __kmem_cache_create() returns -E2BIG for SLAB. This happens right at
> startup in create_boot_cache().
> As far as I understand, SLUB doesn't have the upper limit (or is it
> that we just aren't hitting it?)

Perhaps, SLUB also has the upper limit although it wasn't triggered
easily since there is no such kmem_cache. Unlikely, SLAB has a such
sized kmem_cache in default (kmalloc-XXXXX). I haven't look at
calculate_order() in detail but it would give you some insight.

Thanks.

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



[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]