From: Vlastimil Babka <vbabka@suse.cz>
To: Marco Elver <elver@google.com>, glittao@gmail.com
Cc: cl@linux.com, penberg@kernel.org, rientjes@google.com,
iamjoonsoo.kim@lge.com, akpm@linux-foundation.org,
shuah@kernel.org, linux-kernel@vger.kernel.org,
linux-mm@kvack.org, linux-kselftest@vger.kernel.org
Subject: Re: [PATCH 1/2] selftests: add a kselftest for SLUB debugging functionality
Date: Fri, 19 Mar 2021 11:46:20 +0100 [thread overview]
Message-ID: <3ba2228a-1442-40b4-578f-f693d9a054e7@suse.cz> (raw)
In-Reply-To: <YFM96dY1pfk/rs3U@elver.google.com>
On 3/18/21 12:47 PM, Marco Elver wrote:
> On Tue, Mar 16, 2021 at 01:41PM +0100, glittao@gmail.com wrote:
>> From: Oliver Glitta <glittao@gmail.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@gmail.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
next prev parent reply other threads:[~2021-03-19 10:46 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-16 12:41 glittao
2021-03-16 12:41 ` [PATCH 2/2] slub: remove resiliency_test() function glittao
2021-03-17 11:25 ` Vlastimil Babka
2021-03-17 18:54 ` David Rientjes
2021-03-17 8:36 ` [selftests] e48d82b67a: BUG_TestSlub_RZ_alloc(Not_tainted):Redzone_overwritten kernel test robot
2021-03-17 11:29 ` Vlastimil Babka
2021-03-17 18:53 ` David Rientjes
2021-03-23 0:02 ` Vlastimil Babka
2021-03-22 5:41 ` Oliver Sang
2021-03-17 11:24 ` [PATCH 1/2] selftests: add a kselftest for SLUB debugging functionality Vlastimil Babka
2021-03-17 18:54 ` David Rientjes
2021-03-18 11:47 ` Marco Elver
2021-03-19 10:46 ` Vlastimil Babka [this message]
2021-03-19 11:19 ` Marco Elver
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3ba2228a-1442-40b4-578f-f693d9a054e7@suse.cz \
--to=vbabka@suse.cz \
--cc=akpm@linux-foundation.org \
--cc=cl@linux.com \
--cc=elver@google.com \
--cc=glittao@gmail.com \
--cc=iamjoonsoo.kim@lge.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=penberg@kernel.org \
--cc=rientjes@google.com \
--cc=shuah@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox