From: Hyeonggon Yoo <42.hyeyoo@gmail.com>
To: Vlastimil Babka <vbabka@suse.cz>
Cc: linux-mm@kvack.org, Christoph Lameter <cl@linux.com>,
Pekka Enberg <penberg@kernel.org>,
David Rientjes <rientjes@google.com>,
Joonsoo Kim <iamjoonsoo.kim@lge.com>,
Andrew Morton <akpm@linux-foundation.org>,
Roman Gushchin <roman.gushchin@linux.dev>,
Oliver Glitta <glittao@gmail.com>
Subject: Re: [PATCH] mm/slub, kunit: Make slub_kunit pass even when SLAB_RED_ZONE flag is set
Date: Thu, 17 Mar 2022 07:06:45 +0000 [thread overview]
Message-ID: <YjLeBS5kteOs16F8@ip-172-31-19-208.ap-northeast-1.compute.internal> (raw)
In-Reply-To: <46456d7a-fd35-5052-f3c0-a97d25345e79@suse.cz>
On Wed, Mar 16, 2022 at 11:11:08PM +0100, Vlastimil Babka wrote:
> On 3/16/22 15:38, Hyeonggon Yoo wrote:
> > Testcase test_next_pointer in slub_kunit fails when SLAB_RED_ZONE flag
> > is globally set. This is because on_freelist() cuts corrupted freelist
> > chain and does not update cut objects' redzone to SLUB_RED_ACTIVE.
> >
> > When the test validates a slab that whose freelist is cut, it expects
> > redzone of objects unreachable by freelist is set to SLUB_RED_ACTIVE.
> > And it reports "Left Redzone overritten" error because the expectation
> > failed.
> >
> > This patch makes slub_kunit expect two more errors for reporting and
> > fixing red overwritten error when SLAB_RED_ZONE flag is set.
> >
> > The test passes on slub_debug and slub_debug=Z after this patch.
>
> Hmm I think it's not optimal strategy for unit tests to adapt like this to
> external influence. It seems rather fragile. The test cases should be
> designed to test a specific condition and that's it. So maybe we could e.g.
> introduce a new SLAB_ flag passed to kmem_cache_create that tells it to
> ignore any globally specified slub debug flags?
Agree. It's so easy to be broken. I think your suggestion is
good for unit tests. I'll send a patch.
BTW, The situation is that SLUB makes (by cutting freelist chain)
objects invalid (invalid redzone) and reporting what caused by SLUB
itself is quite ugly.
No simple solution comes into mind but yeah... it's not a big problem
as we rarely call validate_slab_cache().
> > Signed-off-by: Hyeonggon Yoo <42.hyeyoo@gmail.com>
> > ---
> > lib/slub_kunit.c | 19 +++++++++++++++++--
> > 1 file changed, 17 insertions(+), 2 deletions(-)
> >
> > diff --git a/lib/slub_kunit.c b/lib/slub_kunit.c
> > index 8662dc6cb509..7cf1fb5a7fde 100644
> > --- a/lib/slub_kunit.c
> > +++ b/lib/slub_kunit.c
> > @@ -45,21 +45,36 @@ static void test_next_pointer(struct kunit *test)
> > * Expecting three errors.
> > * One for the corrupted freechain and the other one for the wrong
> > * count of objects in use. The third error is fixing broken cache.
> > + *
> > + * When flag SLUB_RED_ZONE is set, we expect two more errors for reporting
> > + * and fixing overwritten redzone error. This two errors are detected
> > + * because SLUB cuts corrupted freelist in on_freelist(), but does not
> > + * update its redzone to SLUB_RED_ACTIVE.
> > */
> > validate_slab_cache(s);
> > - KUNIT_EXPECT_EQ(test, 3, slab_errors);
> > +
> > + if (s->flags & SLAB_RED_ZONE)
> > + KUNIT_EXPECT_EQ(test, 5, slab_errors);
> > + else
> > + KUNIT_EXPECT_EQ(test, 3, slab_errors);
> >
> > /*
> > * Try to repair corrupted freepointer.
> > * Still expecting two errors. The first for the wrong count
> > * of objects in use.
> > * The second error is for fixing broken cache.
> > + *
> > + * When SLUB_RED_ZONE flag is set, we expect two more errors
> > + * for same reason as above.
> > */
> > *ptr_addr = tmp;
> > slab_errors = 0;
> >
> > validate_slab_cache(s);
> > - KUNIT_EXPECT_EQ(test, 2, slab_errors);
> > + if (s->flags & SLAB_RED_ZONE)
> > + KUNIT_EXPECT_EQ(test, 4, slab_errors);
> > + else
> > + KUNIT_EXPECT_EQ(test, 2, slab_errors);
> >
> > /*
> > * Previous validation repaired the count of objects in use.
>
--
Thank you, You are awesome!
Hyeonggon :-)
next prev parent reply other threads:[~2022-03-17 7:06 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-16 14:38 Hyeonggon Yoo
2022-03-16 22:11 ` Vlastimil Babka
2022-03-17 7:06 ` Hyeonggon Yoo [this message]
2022-03-17 8:10 ` [PATCH] mm/slub, kunit: Make slub_kunit unaffected by global slub debugging flags Hyeonggon Yoo
2022-04-05 10:58 ` Vlastimil Babka
2022-04-06 6:00 ` [PATCH v2] mm/slub, kunit: Make slub_kunit unaffected by user specified flags Hyeonggon Yoo
2022-04-06 8:17 ` Vlastimil Babka
2022-04-06 6:06 ` [PATCH] mm/slub, kunit: Make slub_kunit unaffected by global slub debugging flags Hyeonggon Yoo
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=YjLeBS5kteOs16F8@ip-172-31-19-208.ap-northeast-1.compute.internal \
--to=42.hyeyoo@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=cl@linux.com \
--cc=glittao@gmail.com \
--cc=iamjoonsoo.kim@lge.com \
--cc=linux-mm@kvack.org \
--cc=penberg@kernel.org \
--cc=rientjes@google.com \
--cc=roman.gushchin@linux.dev \
--cc=vbabka@suse.cz \
/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