From: "Vlastimil Babka (SUSE)" <vbabka@kernel.org>
To: Brendan Jackman <jackmanb@google.com>,
Andrew Morton <akpm@linux-foundation.org>,
Suren Baghdasaryan <surenb@google.com>,
Michal Hocko <mhocko@suse.com>,
Johannes Weiner <hannes@cmpxchg.org>, Zi Yan <ziy@nvidia.com>,
Muchun Song <muchun.song@linux.dev>,
Oscar Salvador <osalvador@suse.de>,
David Hildenbrand <david@kernel.org>,
Lorenzo Stoakes <ljs@kernel.org>,
"Liam R. Howlett" <liam@infradead.org>,
Mike Rapoport <rppt@kernel.org>,
Matthew Brost <matthew.brost@intel.com>,
Joshua Hahn <joshua.hahnjy@gmail.com>,
Rakie Kim <rakie.kim@sk.com>, Byungchul Park <byungchul@sk.com>,
Ying Huang <ying.huang@linux.alibaba.com>,
Alistair Popple <apopple@nvidia.com>, Hao Li <hao.li@linux.dev>,
Christoph Lameter <cl@gentwo.org>,
David Rientjes <rientjes@google.com>,
Roman Gushchin <roman.gushchin@linux.dev>,
Sebastian Andrzej Siewior <bigeasy@linutronix.de>,
Clark Williams <clrkwllms@kernel.org>,
Steven Rostedt <rostedt@goodmis.org>
Cc: "Harry Yoo (Oracle)" <harry@kernel.org>,
Gregory Price <gourry@gourry.net>,
Alexei Starovoitov <ast@kernel.org>,
Matthew Wilcox <willy@infradead.org>, Hao Ge <hao.ge@linux.dev>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
linux-rt-devel@lists.linux.dev, derkling@google.com,
reijiw@google.com, Yosry Ahmed <yosry@kernel.org>
Subject: Re: [PATCH v4 18/18] mm: factor out can_spin_trylock()
Date: Fri, 3 Jul 2026 11:32:46 +0200 [thread overview]
Message-ID: <1e162a97-1594-495d-b48e-7dafaa0a6d82@kernel.org> (raw)
In-Reply-To: <20260702-alloc-trylock-v4-18-0af8ff387e80@google.com>
On 7/2/26 11:49, Brendan Jackman wrote:
> Deduplicate checks for whether the current context is safe for
> spin_trylock().
>
> Does this function really belong in mm/internal.h or is it generic? Not
> sure. If someone ends up duplicating this logic elsewhere in the kernel,
> that would be a shame. But goes in some generic header, someone treats
> it as documentation about where it's guaranteed safe to spin_trylock(),
> and then it emerges that there are other subtle preconditions that
> didn't affect the mm usecase, that would be worse. So, just be
> conservative and keep it local.
Agreed. We could even use page_alloc.h ?
> Suggested-by: Harry Yoo <harry@kernel.org>
> Link: https://lore.kernel.org/all/397859cb-b127-4cc6-9c71-044afc99bf0c@kernel.org/
> Signed-off-by: Brendan Jackman <jackmanb@google.com>
Reviewed-by: Vlastimil Babka (SUSE) <vbabka@kernel.org>
> ---
> mm/internal.h | 23 +++++++++++++++++++++++
> mm/page_alloc.c | 17 +----------------
> mm/slub.c | 10 +---------
> 3 files changed, 25 insertions(+), 25 deletions(-)
>
> diff --git a/mm/internal.h b/mm/internal.h
> index 3c00eaf5f45a4..e6f300693ffd7 100644
> --- a/mm/internal.h
> +++ b/mm/internal.h
> @@ -1715,4 +1715,27 @@ static inline void mm_prepare_for_swap_entries(struct mm_struct *mm)
> }
> }
>
> +static inline bool can_spin_trylock(void)
> +{
> + /*
> + * In PREEMPT_RT spin_trylock() will call raw_spin_lock() which is
> + * unsafe in NMI. If spin_trylock() is called from hard IRQ the current
> + * task may be waiting for one rt_spin_lock, but rt_spin_trylock() will
> + * mark the task as the owner of another rt_spin_lock which will
> + * confuse PI logic, so return immediately if called from hard IRQ or
> + * NMI.
> + *
> + * Note, irqs_disabled() case is ok. spin_trylock() can be called
> + * from raw_spin_lock_irqsave region.
> + */
> + if (IS_ENABLED(CONFIG_PREEMPT_RT) && (in_nmi() || in_hardirq()))
> + return false;
> +
> + /* On UP, spin_trylock() always succeeds even when it is locked */
> + if (!IS_ENABLED(CONFIG_SMP) && in_nmi())
> + return false;
> +
> + return true;
> +}
> +
> #endif /* __MM_INTERNAL_H */
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index c3b246e67ed14..a63733dac659e 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -5291,22 +5291,7 @@ static inline bool alloc_order_allowed(gfp_t gfp, unsigned int order,
>
> static inline bool alloc_nolock_allowed(void)
> {
> - /*
> - * In PREEMPT_RT spin_trylock() will call raw_spin_lock() which is
> - * unsafe in NMI. If spin_trylock() is called from hard IRQ the current
> - * task may be waiting for one rt_spin_lock, but rt_spin_trylock() will
> - * mark the task as the owner of another rt_spin_lock which will
> - * confuse PI logic, so return immediately if called from hard IRQ or
> - * NMI.
> - *
> - * Note, irqs_disabled() case is ok. This function can be called
> - * from raw_spin_lock_irqsave region.
> - */
> - if (IS_ENABLED(CONFIG_PREEMPT_RT) && (in_nmi() || in_hardirq()))
> - return false;
> -
> - /* On UP, spin_trylock() always succeeds even when it is locked */
> - if (!IS_ENABLED(CONFIG_SMP) && in_nmi())
> + if (!can_spin_trylock())
> return false;
>
> /* Bailout, since _deferred_grow_zone() needs to take a lock */
> diff --git a/mm/slub.c b/mm/slub.c
> index 3989b4758ae0a..b19dc46de73c5 100644
> --- a/mm/slub.c
> +++ b/mm/slub.c
> @@ -5408,15 +5408,7 @@ static void *__kmalloc_nolock_noprof(DECL_TOKEN_PARAMS(size, token), gfp_t gfp_f
> if (unlikely(!size))
> return ZERO_SIZE_PTR;
>
> - /*
> - * See the comment for the same check in
> - * alloc_frozen_pages_nolock_noprof()
> - */
> - if (IS_ENABLED(CONFIG_PREEMPT_RT) && (in_nmi() || in_hardirq()))
> - return NULL;
> -
> - /* On UP, spin_trylock() always succeeds even when it is locked */
> - if (!IS_ENABLED(CONFIG_SMP) && in_nmi())
> + if (!can_spin_trylock())
> return NULL;
>
> retry:
>
next prev parent reply other threads:[~2026-07-03 9:33 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-02 9:49 [PATCH v4 00/18] mm: Some cleanups for page allocator APIs Brendan Jackman
2026-07-02 9:49 ` [PATCH v4 01/18] mm/page_alloc: rename ALLOC_TRYLOCK -> ALLOC_NOLOCK Brendan Jackman
2026-07-02 9:49 ` [PATCH v4 02/18] mm/page_alloc: some renames to clarify alloc_flags scopes Brendan Jackman
2026-07-02 9:49 ` [PATCH v4 03/18] mm: name some args in a function declaration Brendan Jackman
2026-07-02 9:49 ` [PATCH v4 04/18] mm: Split out internal page_alloc.h Brendan Jackman
2026-07-02 9:49 ` [PATCH v4 05/18] mm/page_alloc: unify __alloc_frozen_pages[_nolock]_noprof() Brendan Jackman
2026-07-03 9:20 ` Vlastimil Babka (SUSE)
2026-07-02 9:49 ` [PATCH v4 06/18] mm/page_alloc: relax GFP WARN in nolock allocs Brendan Jackman
2026-07-02 9:49 ` [PATCH v4 07/18] mm: move some stuff to mm/page_alloc.h Brendan Jackman
2026-07-02 10:28 ` sashiko-bot
2026-07-03 9:25 ` Brendan Jackman
2026-07-02 9:49 ` [PATCH v4 08/18] perf/x86/intel: Use higher-level allocator API Brendan Jackman
2026-07-02 9:49 ` [PATCH v4 09/18] KVM: VMX: " Brendan Jackman
2026-07-02 9:49 ` [PATCH v4 10/18] x86/virt: " Brendan Jackman
2026-07-02 9:49 ` [PATCH v4 11/18] sgi-xp: " Brendan Jackman
2026-07-02 10:54 ` sashiko-bot
2026-07-02 9:49 ` [PATCH v4 12/18] net/funeth: Switch to " Brendan Jackman
2026-07-02 9:49 ` [PATCH v4 13/18] mm: Remove __alloc_pages_node() Brendan Jackman
2026-07-02 11:11 ` sashiko-bot
2026-07-02 9:49 ` [PATCH v4 14/18] mm: Move __alloc_pages() to mm/page_alloc.h Brendan Jackman
2026-07-02 9:49 ` [PATCH v4 15/18] mm: replace __GFP_NO_CODETAG with ALLOC_NO_CODETAG Brendan Jackman
2026-07-03 2:29 ` Hao Ge
2026-07-03 9:24 ` Vlastimil Babka (SUSE)
2026-07-02 9:49 ` [PATCH v4 16/18] mm: remove the __GFP_NO_OBJ_EXT flag Brendan Jackman
2026-07-02 9:49 ` [PATCH v4 17/18] mm/page_alloc: drop alloc_flags arg from alloc_flags_cma() Brendan Jackman
2026-07-03 9:28 ` Vlastimil Babka (SUSE)
2026-07-02 9:49 ` [PATCH v4 18/18] mm: factor out can_spin_trylock() Brendan Jackman
2026-07-02 12:28 ` sashiko-bot
2026-07-03 9:16 ` Brendan Jackman
2026-07-03 9:32 ` Vlastimil Babka (SUSE) [this message]
2026-07-03 11:43 ` Brendan Jackman
2026-07-03 9:38 ` 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=1e162a97-1594-495d-b48e-7dafaa0a6d82@kernel.org \
--to=vbabka@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=apopple@nvidia.com \
--cc=ast@kernel.org \
--cc=bigeasy@linutronix.de \
--cc=byungchul@sk.com \
--cc=cl@gentwo.org \
--cc=clrkwllms@kernel.org \
--cc=david@kernel.org \
--cc=derkling@google.com \
--cc=gourry@gourry.net \
--cc=hannes@cmpxchg.org \
--cc=hao.ge@linux.dev \
--cc=hao.li@linux.dev \
--cc=harry@kernel.org \
--cc=jackmanb@google.com \
--cc=joshua.hahnjy@gmail.com \
--cc=liam@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-rt-devel@lists.linux.dev \
--cc=ljs@kernel.org \
--cc=matthew.brost@intel.com \
--cc=mhocko@suse.com \
--cc=muchun.song@linux.dev \
--cc=osalvador@suse.de \
--cc=rakie.kim@sk.com \
--cc=reijiw@google.com \
--cc=rientjes@google.com \
--cc=roman.gushchin@linux.dev \
--cc=rostedt@goodmis.org \
--cc=rppt@kernel.org \
--cc=surenb@google.com \
--cc=willy@infradead.org \
--cc=ying.huang@linux.alibaba.com \
--cc=yosry@kernel.org \
--cc=ziy@nvidia.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.