On 02/02/2016 08:34 AM, Andrew Morton wrote:
> On Wed, 27 Jan 2016 19:25:06 +0100 Alexander Potapenko <glider@xxxxxxxxxx> wrote:
>
>> depending on which allocator (SLAB or SLUB) is being used
>>
>> ...
>>
>> --- a/lib/test_kasan.c
>> +++ b/lib/test_kasan.c
>> @@ -68,7 +68,22 @@ static noinline void __init kmalloc_node_oob_right(void)
>> static noinline void __init kmalloc_large_oob_right(void)
>> {
>> char *ptr;
>> - size_t size = KMALLOC_MAX_CACHE_SIZE + 10;
>> + size_t size;
>> +
>> + if (KMALLOC_MAX_CACHE_SIZE == KMALLOC_MAX_SIZE) {
>> + /*
>> + * We're using the SLAB allocator. Allocate a chunk that fits
>> + * into a slab.
>> + */
>> + size = KMALLOC_MAX_CACHE_SIZE - 256;
>> + } else {
>> + /*
>> + * KMALLOC_MAX_SIZE > KMALLOC_MAX_CACHE_SIZE.
>> + * We're using the SLUB allocator. Allocate a chunk that does
>> + * not fit into a slab to trigger the page allocator.
>> + */
>> + size = KMALLOC_MAX_CACHE_SIZE + 10;
>> + }
>
> This seems a weird way of working out whether we're using SLAB or SLUB.
>
> Can't we use, umm, #ifdef CONFIG_SLAB? If not that then let's cook up
> something standardized rather than a weird just-happens-to-work like
> this.
>
Actually it would be simpler to not use KMALLOC_MAX_CACHE_SIZE at all.
Simply replace it with 2 or 3 PAGE_SIZEs.
--
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>