Linux real-time development
 help / color / mirror / Atom feed
From: "Brendan Jackman" <brendan.jackman@linux.dev>
To: "Harry Yoo" <harry@kernel.org>,
	"Brendan Jackman" <brendan.jackman@linux.dev>,
	"Brendan Jackman" <jackmanb@google.com>,
	"Andrew Morton" <akpm@linux-foundation.org>,
	"Vlastimil Babka" <vbabka@kernel.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: "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>
Subject: Re: [PATCH v3 05/16] mm/page_alloc: unify __alloc_frozen_pages[_nolock]_noprof()
Date: Wed, 01 Jul 2026 08:40:50 +0000	[thread overview]
Message-ID: <DJN3MAVWO7YV.2FIHJGQO8I6US@linux.dev> (raw)
In-Reply-To: <791b1aee-8667-4721-ad93-2a1b8fd2aef1@kernel.org>

On Wed Jul 1, 2026 at 2:21 AM UTC, Harry Yoo wrote:
>
>
> On 7/1/26 2:04 AM, Brendan Jackman wrote:
>>>> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
>>>> index a3ba63c7f9199..8d409d075e3e9 100644
>>>> --- a/mm/page_alloc.c
>>>> +++ b/mm/page_alloc.c
>>>> @@ -5271,24 +5271,98 @@ void free_pages_bulk(struct page **page_array, unsigned long nr_pages)
>>>>  	}
>>>>  }
>>>>  
>>>> +static inline bool alloc_trylock_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())
>>>> +		return false;
>>>
>>> Except for deferred_pages_enabled(), it's not specific to the page
>>> allocator. SLUB has
>>>
>>> 	/*
>>> 	 * See the comment for the same check in
>>> 	 * alloc_frozen_pages_nolock_noprof()
>>> 	 */
>>>
>>> ... and repeats the same thing as above.
>>>
>>> Perhaps let's factor it out into a helper
>>> rather than trying not to forget to update the other place?
>> 
>> Hm, not sure about this. I think I would say it's a "coincidence" that
>> these two bits of code look the same? Like, page_alloc.c uses
>> spin_trylock() so you can't do alloc_pages_nolock() from IRQ on
>> PREEMPT_RT. slub.c ALSO uses spin_trylock(), so you ALSO can't use
>> kmalloc_nolock() in those scenarios. But those are two different facts
>> that just happen to be isomorphic? Putting them into a shared helper
>> would kinda imply that these are part of a single system with inherently
>> coupled constraints.
>
> But as long as they use spinlocks and can be called in unknown contexts,
> they are supposed to have the same constraint?
>
> And actually, the only reason free_pages_nolock() or kfree_nolock()
> don't have these checks is just because we don't allow kmalloc() ->
> kfree_nolock() or alloc_pages() -> free_pages_nolock(). Once we allow
> them, we'll need to repeat this again.
>
> I think it doesn't even belong page/slab allocators,
> probably should be spin_trylock_allowed()?

You are right. I was imagining a function called alloc_nolock_allowed()
but actually now I see the name spin_trylock_allowed() I realise it's
not about the allocators (which both just happen to use spin_trylock())
at all, it makes perfect sense.

>> But I'd lean towards leaving this out of> the patchset since the
> potential deduplication isn't really related to
>> the other cleanups anyway.
>
> Ack.

Patchset is getting pretty big already but most stuff is already acked
and also most of the patches are trivial so maybe I'll tack it on after
all...

  reply	other threads:[~2026-07-01  8:41 UTC|newest]

Thread overview: 64+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-29 13:11 [PATCH v3 00/16] mm: Some cleanups for page allocator APIs Brendan Jackman
2026-06-29 13:11 ` [PATCH v3 01/16] mm/page_alloc: rename ALLOC_TRYLOCK -> ALLOC_NOLOCK Brendan Jackman
2026-06-30 12:27   ` Vlastimil Babka (SUSE)
2026-06-29 13:11 ` [PATCH v3 02/16] mm/page_alloc: some renames to clarify alloc_flags scopes Brendan Jackman
2026-06-30 12:38   ` Vlastimil Babka (SUSE)
2026-06-30 17:25     ` Brendan Jackman
2026-06-29 13:11 ` [PATCH v3 03/16] mm: name some args in a function declaration Brendan Jackman
2026-06-30 12:43   ` Vlastimil Babka (SUSE)
2026-06-29 13:11 ` [PATCH v3 04/16] mm: Split out internal page_alloc.h Brendan Jackman
2026-06-29 14:16   ` sashiko-bot
2026-06-30 13:54   ` Vlastimil Babka (SUSE)
2026-06-29 13:11 ` [PATCH v3 05/16] mm/page_alloc: unify __alloc_frozen_pages[_nolock]_noprof() Brendan Jackman
2026-06-29 14:29   ` sashiko-bot
2026-06-29 15:27     ` Brendan Jackman
2026-06-30 13:36   ` Harry Yoo
2026-06-30 15:34     ` Vlastimil Babka (SUSE)
2026-06-30 16:56       ` Brendan Jackman
2026-07-01  2:10         ` Harry Yoo
2026-06-30 17:04     ` Brendan Jackman
2026-07-01  2:21       ` Harry Yoo
2026-07-01  8:40         ` Brendan Jackman [this message]
2026-06-30 16:16   ` Vlastimil Babka (SUSE)
2026-06-30 18:47     ` Brendan Jackman
2026-06-29 13:11 ` [PATCH v3 06/16] mm/page_alloc: relax GFP WARN in nolock allocs Brendan Jackman
2026-06-30 13:52   ` Harry Yoo
2026-06-30 16:42   ` Vlastimil Babka (SUSE)
2026-06-29 13:11 ` [PATCH v3 07/16] mm: move some stuff to mm/page_alloc.h Brendan Jackman
2026-06-30 16:42   ` Vlastimil Babka (SUSE)
2026-06-29 13:11 ` [PATCH v3 08/16] perf/x86/intel: Use higher-level allocator API Brendan Jackman
2026-07-01  7:50   ` Vlastimil Babka (SUSE)
2026-06-29 13:11 ` [PATCH v3 09/16] KVM: VMX: " Brendan Jackman
2026-06-29 15:31   ` -EXT-[PATCH " Soderlund, David
2026-07-01  7:50   ` [PATCH " Vlastimil Babka (SUSE)
2026-06-29 13:11 ` [PATCH v3 10/16] x86/virt: " Brendan Jackman
2026-07-01  7:51   ` Vlastimil Babka (SUSE)
2026-06-29 13:12 ` [PATCH v3 11/16] sgi-xp: " Brendan Jackman
2026-06-29 15:04   ` sashiko-bot
2026-06-29 18:47   ` Steve Wahl
2026-07-01  7:52   ` Vlastimil Babka (SUSE)
2026-07-01  8:51     ` Brendan Jackman
2026-06-29 13:12 ` [PATCH v3 12/16] net/funeth: Switch to " Brendan Jackman
2026-07-01  7:53   ` Vlastimil Babka (SUSE)
2026-06-29 13:12 ` [PATCH v3 13/16] mm: Remove __alloc_pages_node() Brendan Jackman
2026-06-29 15:27   ` sashiko-bot
2026-07-01  7:54   ` Vlastimil Babka (SUSE)
2026-06-29 13:12 ` [PATCH v3 14/16] mm: Move __alloc_pages() to mm/page_alloc.h Brendan Jackman
2026-07-01  8:08   ` Vlastimil Babka (SUSE)
2026-06-29 13:12 ` [PATCH v3 15/16] mm: replace __GFP_NO_CODETAG with ALLOC_NO_CODETAG Brendan Jackman
2026-06-29 15:56   ` sashiko-bot
2026-06-30  4:34     ` Hao Ge
2026-06-30  1:55   ` Hao Ge
2026-06-30 10:10     ` Brendan Jackman
2026-07-01  1:47       ` Hao Ge
2026-07-01  1:52         ` Zi Yan
2026-06-30 12:01     ` Brendan Jackman
2026-07-01  8:30   ` Vlastimil Babka (SUSE)
2026-06-29 13:12 ` [PATCH v3 16/16] mm: remove the __GFP_NO_OBJ_EXT flag Brendan Jackman
2026-06-29 16:02   ` sashiko-bot
2026-06-30 10:04     ` Brendan Jackman
2026-07-01  8:32   ` Vlastimil Babka (SUSE)
2026-07-01  9:10     ` Brendan Jackman
2026-06-29 14:00 ` [PATCH v3 00/16] mm: Some cleanups for page allocator APIs Mike Rapoport
2026-06-29 14:30   ` Brendan Jackman
2026-06-29 15:05     ` Brendan Jackman

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=DJN3MAVWO7YV.2FIHJGQO8I6US@linux.dev \
    --to=brendan.jackman@linux.dev \
    --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=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=rientjes@google.com \
    --cc=roman.gushchin@linux.dev \
    --cc=rostedt@goodmis.org \
    --cc=rppt@kernel.org \
    --cc=surenb@google.com \
    --cc=vbabka@kernel.org \
    --cc=willy@infradead.org \
    --cc=ying.huang@linux.alibaba.com \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox