linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Harry Yoo <harry.yoo@oracle.com>
To: Alexei Starovoitov <alexei.starovoitov@gmail.com>
Cc: bpf@vger.kernel.org, linux-mm@kvack.org, vbabka@suse.cz,
	shakeel.butt@linux.dev, mhocko@suse.com, bigeasy@linutronix.de,
	andrii@kernel.org, memxor@gmail.com, akpm@linux-foundation.org,
	peterz@infradead.org, rostedt@goodmis.org, hannes@cmpxchg.org
Subject: Re: [PATCH v3 5/6] slab: Introduce kmalloc_nolock() and kfree_nolock().
Date: Mon, 25 Aug 2025 13:45:03 +0900	[thread overview]
Message-ID: <aKvqT-BAXGkjW7JT@hyeyoo> (raw)
In-Reply-To: <20250716022950.69330-6-alexei.starovoitov@gmail.com>

On Tue, Jul 15, 2025 at 07:29:49PM -0700, Alexei Starovoitov wrote:
> From: Alexei Starovoitov <ast@kernel.org>
> 
> kmalloc_nolock() relies on ability of local_lock to detect the situation
> when it's locked.
> In !PREEMPT_RT local_lock_is_locked() is true only when NMI happened in
> irq saved region that protects _that specific_ per-cpu kmem_cache_cpu.
> In that case retry the operation in a different kmalloc bucket.
> The second attempt will likely succeed, since this cpu locked
> different kmem_cache_cpu.
> 
> Similarly, in PREEMPT_RT local_lock_is_locked() returns true when
> per-cpu rt_spin_lock is locked by current task. In this case re-entrance
> into the same kmalloc bucket is unsafe, and kmalloc_nolock() tries
> a different bucket that is most likely is not locked by the current
> task. Though it may be locked by a different task it's safe to
> rt_spin_lock() on it.
> 
> Similar to alloc_pages_nolock() the kmalloc_nolock() returns NULL
> immediately if called from hard irq or NMI in PREEMPT_RT.
> 
> kfree_nolock() defers freeing to irq_work when local_lock_is_locked()
> and in_nmi() or in PREEMPT_RT.
> 
> SLUB_TINY config doesn't use local_lock_is_locked() and relies on
> spin_trylock_irqsave(&n->list_lock) to allocate while kfree_nolock()
> always defers to irq_work.
> 
> Signed-off-by: Alexei Starovoitov <ast@kernel.org>
> ---
>  include/linux/kasan.h |  13 +-
>  include/linux/slab.h  |   4 +
>  mm/Kconfig            |   1 +
>  mm/kasan/common.c     |   5 +-
>  mm/slab.h             |   6 +
>  mm/slab_common.c      |   3 +
>  mm/slub.c             | 454 +++++++++++++++++++++++++++++++++++++-----
>  7 files changed, 434 insertions(+), 52 deletions(-)

> +static void defer_free(struct kmem_cache *s, void *head)
> +{
> +	struct defer_free *df = this_cpu_ptr(&defer_free_objects);
> +
> +	if (llist_add(head + s->offset, &df->objects))
> +		irq_work_queue(&df->work);
> +}
> +
> +static void defer_deactivate_slab(struct slab *slab)
> +{
> +	struct defer_free *df = this_cpu_ptr(&defer_free_objects);
> +
> +	if (llist_add(&slab->llnode, &df->slabs))
> +		irq_work_queue(&df->work);
> +}
> +
> +void defer_free_barrier(void)
> +{
> +	int cpu;
> +
> +	for_each_possible_cpu(cpu)
> +		irq_work_sync(&per_cpu_ptr(&defer_free_objects, cpu)->work);
> +}

I think it should also initiate deferred frees, if kfree_nolock() freed
the last object in some CPUs?

> +
>  #ifndef CONFIG_SLUB_TINY
>  /*
>   * Fastpath with forced inlining to produce a kfree and kmem_cache_free that

-- 
Cheers,
Harry / Hyeonggon


  parent reply	other threads:[~2025-08-25  4:47 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-07-16  2:29 [PATCH v3 0/6] slab: Re-entrant kmalloc_nolock() Alexei Starovoitov
2025-07-16  2:29 ` [PATCH v3 1/6] locking/local_lock: Expose dep_map in local_trylock_t Alexei Starovoitov
2025-07-16  2:29 ` [PATCH v3 2/6] locking/local_lock: Introduce local_lock_is_locked() Alexei Starovoitov
2025-07-16  2:29 ` [PATCH v3 3/6] mm: Allow GFP_ACCOUNT to be used in alloc_pages_nolock() Alexei Starovoitov
2025-07-16  2:29 ` [PATCH v3 4/6] mm: Introduce alloc_frozen_pages_nolock() Alexei Starovoitov
2025-07-16  2:29 ` [PATCH v3 5/6] slab: Introduce kmalloc_nolock() and kfree_nolock() Alexei Starovoitov
2025-07-16 10:58   ` Vlastimil Babka
2025-07-17  2:50     ` Alexei Starovoitov
2025-07-17  9:18       ` Vlastimil Babka
2025-07-17 16:23         ` Alexei Starovoitov
2025-07-18  0:09       ` Alexei Starovoitov
2025-08-25  4:45   ` Harry Yoo [this message]
2025-08-27  2:31     ` Alexei Starovoitov
2025-08-27  5:13       ` Harry Yoo
2025-07-16  2:29 ` [PATCH v3 6/6] slab: Make slub local_trylock_t more precise for LOCKDEP Alexei Starovoitov
2025-07-16 13:35   ` Vlastimil Babka
2025-07-17  3:32     ` Alexei Starovoitov
2025-07-17  9:29       ` Vlastimil Babka

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=aKvqT-BAXGkjW7JT@hyeyoo \
    --to=harry.yoo@oracle.com \
    --cc=akpm@linux-foundation.org \
    --cc=alexei.starovoitov@gmail.com \
    --cc=andrii@kernel.org \
    --cc=bigeasy@linutronix.de \
    --cc=bpf@vger.kernel.org \
    --cc=hannes@cmpxchg.org \
    --cc=linux-mm@kvack.org \
    --cc=memxor@gmail.com \
    --cc=mhocko@suse.com \
    --cc=peterz@infradead.org \
    --cc=rostedt@goodmis.org \
    --cc=shakeel.butt@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