[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <3ba2228a-1442-40b4-578f-f693d9a054e7@suse.cz>
Date: Fri, 19 Mar 2021 11:46:20 +0100
From: Vlastimil Babka <vbabka@...e.cz>
To: Marco Elver <elver@...gle.com>, glittao@...il.com
Cc: cl@...ux.com, penberg@...nel.org, rientjes@...gle.com,
iamjoonsoo.kim@....com, akpm@...ux-foundation.org,
shuah@...nel.org, linux-kernel@...r.kernel.org, linux-mm@...ck.org,
linux-kselftest@...r.kernel.org
Subject: Re: [PATCH 1/2] selftests: add a kselftest for SLUB debugging
functionality
On 3/18/21 12:47 PM, Marco Elver wrote:
> On Tue, Mar 16, 2021 at 01:41PM +0100, glittao@...il.com wrote:
>> From: Oliver Glitta <glittao@...il.com>
>>
>> SLUB has resiliency_test() function which is hidden behind #ifdef
>> SLUB_RESILIENCY_TEST that is not part of Kconfig, so nobody
>> runs it. Kselftest should proper replacement for it.
>>
>> Try changing byte in redzone after allocation and changing
>> pointer to next free node, first byte, 50th byte and redzone
>> byte. Check if validation finds errors.
>>
>> There are several differences from the original resiliency test:
>> Tests create own caches with known state instead of corrupting
>> shared kmalloc caches.
>>
>> The corruption of freepointer uses correct offset, the original
>> resiliency test got broken with freepointer changes.
>>
>> Scratch changing random byte test, because it does not have
>> meaning in this form where we need deterministic results.
>>
>> Add new option CONFIG_TEST_SLUB in Kconfig.
>>
>> Add parameter to function validate_slab_cache() to return
>> number of errors in cache.
>>
>> Signed-off-by: Oliver Glitta <glittao@...il.com>
>
> No objection per-se, but have you considered a KUnit-based test instead?
To be honest, we didn't realize about that option.
> There is no user space portion required to run this test, and a pure
> in-kernel KUnit test would be cleaner. Various boiler-plate below,
> including pr_err()s, the kselftest script etc. would simply not be
> necessary.
>
> This is only a suggestion, but just want to make sure you've considered
> the option and weighed its pros/cons.
Thanks for the suggestion. But I hope we would expand the tests later to e.g.
check the contents of various SLUB related sysfs files or even write to them,
and for that goal kselftest seems to be a better starting place?
Vlastimil
Powered by blists - more mailing lists