From: Harry Yoo <harry.yoo@oracle.com>
To: Catalin Marinas <catalin.marinas@arm.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Vlastimil Babka <vbabka@suse.cz>,
Christoph Lameter <cl@gentwo.org>,
David Rientjes <rientjes@google.com>,
Roman Gushchin <roman.gushchin@linux.dev>,
Hao Li <hao.li@linux.dev>, Alexei Starovoitov <ast@kernel.org>,
Uladzislau Rezki <urezki@gmail.com>,
Suren Baghdasaryan <surenb@google.com>,
linux-mm@kvack.org
Subject: Re: [PATCH 1/2] mm/slab: allow freeing kmalloc_nolock()'d objects using kfree[_rcu]()
Date: Tue, 10 Feb 2026 10:50:18 +0900 [thread overview]
Message-ID: <aYqO2n5LiZi9yISo@hyeyoo> (raw)
In-Reply-To: <aYooqPNGEf3On-W_@arm.com>
On Mon, Feb 09, 2026 at 06:34:16PM +0000, Catalin Marinas wrote:
> On Mon, Feb 09, 2026 at 09:10:12PM +0900, Harry Yoo wrote:
> > Slab objects that are allocated with kmalloc_nolock() must be freed
> > using kfree_nolock() because only a subset of alloc hooks are called,
> > since kmalloc_nolock() can't spin on a lock during allocation.
> >
> > This imposes a limitation: such objects cannot be freed with kfree_rcu(),
> > forcing users to work around this limitation by calling call_rcu()
> > with a callback that frees the object using kfree_nolock().
> >
> > Remove this limitation by teaching kmemleak to gracefully ignore cases
> > when kmemleak_free() or kmemleak_ignore() (called by kvfree_call_rcu())
> > is called without a prior kmemleak_alloc().
> >
> > Unlike kmemleak, kfence already handles this case, because,
> > due to its design, only a subset of allocations are served from kfence.
> >
> > With this change, kfree() and kfree_rcu() can be used to free objects
> > that are allocated using kmalloc_nolock().
> >
> > Suggested-by: Alexei Starovoitov <ast@kernel.org>
> > Acked-by: Alexei Starovoitov <ast@kernel.org>
> > Signed-off-by: Harry Yoo <harry.yoo@oracle.com>
>
> It looks fine to me. The alternative would have been to track objects
> allocated by kmalloc_nolock() but that's not (easily) possible without
> taking more locks in kmemleak.
Haha, yeah... I wasn't brave enough to have fun with changing the locking
in kmemleak :)
> Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
Thanks a lot for quick review, Catalin!
--
Cheers,
Harry / Hyeonggon
next prev parent reply other threads:[~2026-02-10 1:50 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-09 12:10 [PATCH 0/2] mm/slab: support kmalloc_nolock() -> kfree[_rcu]() Harry Yoo
2026-02-09 12:10 ` [PATCH 1/2] mm/slab: allow freeing kmalloc_nolock()'d objects using kfree[_rcu]() Harry Yoo
2026-02-09 18:34 ` Catalin Marinas
2026-02-10 1:50 ` Harry Yoo [this message]
2026-02-09 12:10 ` [PATCH 2/2] mm/slab: free a bit in enum objexts_flags Harry Yoo
2026-02-10 1:44 ` 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=aYqO2n5LiZi9yISo@hyeyoo \
--to=harry.yoo@oracle.com \
--cc=akpm@linux-foundation.org \
--cc=ast@kernel.org \
--cc=catalin.marinas@arm.com \
--cc=cl@gentwo.org \
--cc=hao.li@linux.dev \
--cc=linux-mm@kvack.org \
--cc=rientjes@google.com \
--cc=roman.gushchin@linux.dev \
--cc=surenb@google.com \
--cc=urezki@gmail.com \
--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 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.