All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Harry Yoo (Oracle)" <harry@kernel.org>
Cc: linux-kernel@vger.kernel.org, linux-rt-devel@lists.linux.dev,
	bpf@vger.kernel.org
Subject: Re: [PATCH slab/for-next v4 6/8] mm/slab: introduce struct kvfree_rcu_head for kvfree_rcu batching
Date: Mon, 20 Jul 2026 13:09:12 +0000	[thread overview]
Message-ID: <20260720130912.8E8CC1F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260720-kfree_rcu_nolock-v4-6-964e03c41a4e@kernel.org>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] KASAN tag loss in kvmalloc_obj_start_addr() causes debugobjects memory leak, corrupted tracepoint offsets, and KASAN double-free bypass.
--

--- Patch [6]: [PATCH slab/for-next v4 6/8] mm/slab: introduce struct kvfree_rcu_head for kvfree_rcu batching ---
commit b85878f9ac539d3e206f29f7df390cb30b50c271
Author: Harry Yoo (Oracle) <harry@kernel.org>
Subject: mm/slab: introduce struct kvfree_rcu_head for kvfree_rcu batching

This patch introduces `kvfree_rcu_head` to replace `rcu_head` for
kvfree_rcu batching. It stops storing the object pointer directly and
instead calculates the object's start address dynamically via
`kvmalloc_obj_start_addr()` to reduce structure size overhead.

> diff --git a/mm/slab.h b/mm/slab.h
> index fdd293b3efa56..1efeaceb7db32 100644
> --- a/mm/slab.h
> +++ b/mm/slab.h
> @@ -351,6 +351,33 @@ static inline int objs_per_slab(const struct kmem_cache *cache,

[ ... ]

> +/* kvfree_rcu_head offset can be only less than page size */
> +static inline void *kvmalloc_obj_start_addr(void *head)
> +{
> +	void *obj = head;
> +
> +	if (unlikely(is_vmalloc_addr(obj))) {
> +		obj = (void *) PAGE_ALIGN_DOWN((unsigned long)obj);
> +	} else {
> +		struct page *page = virt_to_page(obj);
> +		struct slab *slab = page_slab(page);
> +
> +		if (!slab) {
> +			obj = (void *) PAGE_ALIGN_DOWN((unsigned long)obj);
> +		} else if (is_kfence_address(obj)) {
> +			obj = kfence_object_start(obj);
> +		} else {
> +			struct kmem_cache *s = slab->slab_cache;
> +			unsigned int idx = __obj_to_index(s, slab_address(slab), obj);
> +
> +			obj = slab_address(slab) + s->size * idx;

[Severity: High]
Does reconstructing the base address using slab_address(slab) drop the KASAN
tag from the original allocation?

slab_address() returns a tagless linear map address, so the resulting obj
pointer will be untagged.

> +			obj = fixup_red_left(s, obj);
> +		}
> +	}
> +
> +	return obj;
> +}
> +
> diff --git a/mm/slab_common.c b/mm/slab_common.c
> index 8c631bf97cd5b..c1c32909fa528 100644
> --- a/mm/slab_common.c
> +++ b/mm/slab_common.c

[ ... ]

>  static void
> -kvfree_rcu_list(struct rcu_head *head)
> +kvfree_rcu_list(struct kvfree_rcu_head *head)
>  {
> -	struct rcu_head *next;
> +	struct kvfree_rcu_head *next;
>  
>  	for (; head; head = next) {
> -		void *ptr = (void *) head->func;
> +		void *ptr = kvmalloc_obj_start_addr(head);
>  		unsigned long offset = (void *) head - ptr;

[Severity: High]
If ptr is untagged but head still has its KASAN tag, could this cause the
offset calculation to yield a massive value due to the tag difference in the
upper bits?

Additionally, does passing the untagged ptr to debug_rcu_head_unqueue()
(called slightly later in this function) cause an exact-match hash failure
and permanently leak the tracking object?

>  
>  		next = head->next;
> diff --git a/mm/slub.c b/mm/slub.c
> index deac315d0f23e..d0976396d703d 100644
> --- a/mm/slub.c
> +++ b/mm/slub.c
> @@ -6699,43 +6699,21 @@ static void free_large_kmalloc(struct page *page, void *object)
>   */
>  void kvfree_rcu_cb(struct rcu_head *head)
>  {
> -	void *obj = head;

[ ... ]

> +	obj = kvmalloc_obj_start_addr(head);
>  
>  	if (is_vmalloc_addr(obj)) {
>  		vfree(obj);
>  	} else {
> -		unsigned int idx = __obj_to_index(s, slab_addr, obj);
> +		struct page *page = virt_to_page(obj);
> +		struct slab *slab = page_slab(page);
>  
> -		obj = slab_addr + s->size * idx;
> -		obj = fixup_red_left(s, obj);
> +		if (slab)
> +			slab_free(slab->slab_cache, slab, obj, _RET_IP_);

[Severity: High]
Does passing the untagged obj pointer into slab_free() silently bypass
KASAN quarantine and double-free/use-after-free validation checks that
rely on the tag?

> +		else
> +			free_large_kmalloc(page, obj);
>  	}
>  }

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260720-kfree_rcu_nolock-v4-0-964e03c41a4e@kernel.org?part=6

  reply	other threads:[~2026-07-20 13:09 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-20 12:44 [PATCH slab/for-next v4 0/8] mm/slab: introduce kfree_rcu_nolock() and improve slub_kunit coverage Harry Yoo (Oracle)
2026-07-20 12:44 ` [PATCH slab/for-next v4 1/8] mm/slab, slub_kunit: register kprobe to trigger _nolock APIs Harry Yoo (Oracle)
2026-07-20 12:56   ` sashiko-bot
2026-07-22  3:27   ` hu.shengming
2026-07-20 12:44 ` [PATCH slab/for-next v4 2/8] mm/slab: handle the !allow_spin case in kfree_rcu_sheaf() Harry Yoo (Oracle)
2026-07-20 13:11   ` sashiko-bot
2026-07-21 10:07   ` Vlastimil Babka (SUSE)
2026-07-20 12:44 ` [PATCH slab/for-next v4 3/8] mm/slab: use call_rcu() in unknown context if irqs are enabled Harry Yoo (Oracle)
2026-07-20 13:01   ` sashiko-bot
2026-07-20 12:44 ` [PATCH slab/for-next v4 4/8] mm/slab: extend deferred free mechanism to handle rcu sheaves Harry Yoo (Oracle)
2026-07-20 13:03   ` sashiko-bot
2026-07-20 12:44 ` [PATCH slab/for-next v4 5/8] mm/slab: allow kfree_rcu_sheaf() on PREEMPT_RT Harry Yoo (Oracle)
2026-07-20 12:56   ` sashiko-bot
2026-07-21 10:46   ` Vlastimil Babka (SUSE)
2026-07-20 12:44 ` [PATCH slab/for-next v4 6/8] mm/slab: introduce struct kvfree_rcu_head for kvfree_rcu batching Harry Yoo (Oracle)
2026-07-20 13:09   ` sashiko-bot [this message]
2026-07-21 11:06   ` Vlastimil Babka (SUSE)
2026-07-20 12:44 ` [PATCH slab/for-next v4 7/8] mm/slab: introduce kfree_rcu_nolock() Harry Yoo (Oracle)
2026-07-20 13:07   ` sashiko-bot
2026-07-21 13:09   ` Vlastimil Babka (SUSE)
2026-07-20 12:44 ` [PATCH slab/for-next v4 8/8] slub_kunit: extend the test for kfree_rcu_nolock() Harry Yoo (Oracle)

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=20260720130912.8E8CC1F000E9@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=harry@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-rt-devel@lists.linux.dev \
    --cc=sashiko-reviews@lists.linux.dev \
    /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.