All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Vlastimil Babka (SUSE)" <vbabka@kernel.org>,
	"Harry Yoo" <harry@kernel.org>,
	"Andrey Ryabinin" <ryabinin.a.a@gmail.com>
Cc: "Hao Li" <hao.li@linux.dev>, "Christoph Lameter" <cl@gentwo.org>,
	"David Rientjes" <rientjes@google.com>,
	"Roman Gushchin" <roman.gushchin@linux.dev>,
	"Geert Uytterhoeven" <geert@linux-m68k.org>,
	"Conor Dooley" <conor@kernel.org>,
	"Damien Le Moal" <dlemoal@kernel.org>,
	linux-mm@kvack.org, "Alexander Potapenko" <glider@google.com>,
	"Andrey Konovalov" <andreyknvl@gmail.com>,
	"Dmitry Vyukov" <dvyukov@google.com>,
	"Vincenzo Frascino" <vincenzo.frascino@arm.com>,
	kasan-dev@googlegroups.com
Subject: Re: [PATCH v3 02/10] kasan, kunit: pin test slabs by an extra allocation
Date: Thu, 05 Nov 2026 13:26:36 +0000	[thread overview]
Message-ID: <sashiko-outbox-199142@kernel.org> (raw)
In-Reply-To: <20261105-slub_tiny_rework-v3-2-0484ce59eabb@kernel.org>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] kasan: kunit: unbalanced migrate_disable() in kmem_cache_rcu_reuse()
--

commit 9889dce92c4935230b2785629413456302c4d31c
Author: Vlastimil Babka (SUSE) <vbabka@kernel.org>

kasan, kunit: pin test slabs by an extra allocation

This commit adds an extra object allocation to kmem_cache_double_free() and
kmem_cache_rcu_reuse() in mm/kasan/kasan_test_c.c to keep the test slab from
being freed when s->min_partial is zero.

> diff --git a/mm/kasan/kasan_test_c.c b/mm/kasan/kasan_test_c.c
> index b9e167ed5be32..580a9bf007ec4 100644
> --- a/mm/kasan/kasan_test_c.c
> +++ b/mm/kasan/kasan_test_c.c

[ ... ]

> @@ -1152,7 +1160,7 @@ static void kmem_cache_rcu_uaf(struct kunit *test)
>   */
>  static void kmem_cache_rcu_reuse(struct kunit *test)
>  {
> -	char *p, *p2;
> +	char *p, *p2, *pin;
>  	struct kmem_cache *cache;
>  
>  	KASAN_TEST_NEEDS_CONFIG_OFF(test, CONFIG_SLUB_RCU_DEBUG);
> @@ -1162,6 +1170,12 @@ static void kmem_cache_rcu_reuse(struct kunit *test)
>  	KUNIT_ASSERT_NOT_ERR_OR_NULL(test, cache);
>  
>  	migrate_disable();
> +	pin = kmem_cache_alloc(cache, GFP_KERNEL);
> +	if (!pin) {
> +		kunit_err(test, "Allocation failed: %s\n", __func__);
> +		goto destroy;
> +	}
> +
>  	p = kmem_cache_alloc(cache, GFP_KERNEL);
>  	if (!p) {
>  		kunit_err(test, "Allocation failed: %s\n", __func__);
> @@ -1178,8 +1192,12 @@ static void kmem_cache_rcu_reuse(struct kunit *test)
>  
>  	kmem_cache_free(cache, p2);
>  
> +
>  out:
>  	migrate_enable();
> +	kmem_cache_free(cache, pin);
> +
> +destroy:
>  	kmem_cache_destroy(cache);
>  }

[Severity: Medium]
If kmem_cache_alloc() for pin fails in kmem_cache_rcu_reuse(), jumping to the
destroy label skips migrate_enable(), leaving migration disabled when
kmem_cache_destroy() is called and after the function returns. Should
migrate_enable() be called under the destroy label, or before jumping to
destroy?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261105-slub_tiny_rework-v3-0-0484ce59eabb@kernel.org?part=2


  parent reply	other threads:[~2026-11-05 13:26 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-11-05  8:43 [PATCH v3 00/10] replace CONFIG_SLUB_TINY with a slab_tiny boot parameter Vlastimil Babka (SUSE)
2026-11-05  8:43 ` [PATCH v3 01/10] slab, kunit: pin test slabs by an extra allocation Vlastimil Babka (SUSE)
2026-11-05 12:59   ` Harry Yoo
2026-11-05  8:43 ` [PATCH v3 02/10] kasan, " Vlastimil Babka (SUSE)
2026-11-05 13:03   ` Harry Yoo
2026-11-05 13:26   ` sashiko-bot [this message]
2026-11-05  8:43 ` [PATCH v3 03/10] mm, slab: refactor slab_min/max_order handling Vlastimil Babka (SUSE)
2026-11-05 13:12   ` Harry Yoo
2026-11-05  8:43 ` [PATCH v3 04/10] mm, slab: introduce slab_debug=N Vlastimil Babka (SUSE)
2026-11-05 13:26   ` sashiko-bot
2026-11-05 14:30   ` Harry Yoo
2026-11-05 14:36     ` Vlastimil Babka (SUSE)
2026-11-05 15:02       ` Harry Yoo
2026-11-05  8:43 ` [PATCH v3 05/10] mm, slab: rework KMALLOC_RECLAIM handling of SLUB_TINY Vlastimil Babka (SUSE)
2026-11-08 17:00   ` Harry Yoo
2026-11-05  8:43 ` [PATCH v3 06/10] mm, slab: make SLUB_TINY handling dynamic for sizing decisions Vlastimil Babka (SUSE)
2026-11-08 17:58   ` Harry Yoo
2026-11-05  8:43 ` [PATCH v3 07/10] mm, slab: convert CONFIG_SLUB_TINY checks to kmem_cache_debug() Vlastimil Babka (SUSE)
2026-11-10 14:12   ` Harry Yoo
2026-11-05  8:43 ` [PATCH v3 08/10] mm, slab: remove remaining compile-time checks for CONFIG_SLUB_TINY Vlastimil Babka (SUSE)
2026-11-10 14:19   ` Harry Yoo
2026-11-05  8:43 ` [PATCH v3 09/10] mm, slab: add slab_tiny boot param Vlastimil Babka (SUSE)
2026-11-10 14:24   ` Harry Yoo
2026-11-05  8:43 ` [PATCH v3 10/10] mm, slab: deprecate CONFIG_SLUB_TINY and reduce its Kconfig effects Vlastimil Babka (SUSE)
2026-11-10 14:39   ` Harry Yoo
2026-11-10 14:46 ` [PATCH v3 00/10] replace CONFIG_SLUB_TINY with a slab_tiny boot parameter Harry 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=sashiko-outbox-199142@kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=andreyknvl@gmail.com \
    --cc=cl@gentwo.org \
    --cc=conor@kernel.org \
    --cc=dlemoal@kernel.org \
    --cc=dvyukov@google.com \
    --cc=geert@linux-m68k.org \
    --cc=glider@google.com \
    --cc=hao.li@linux.dev \
    --cc=harry@kernel.org \
    --cc=kasan-dev@googlegroups.com \
    --cc=linux-mm@kvack.org \
    --cc=rientjes@google.com \
    --cc=roman.gushchin@linux.dev \
    --cc=ryabinin.a.a@gmail.com \
    --cc=sashiko-reviews@lists.linux.dev \
    --cc=vbabka@kernel.org \
    --cc=vincenzo.frascino@arm.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.