[PATCH] mm/page_alloc: document that alloc_pages_nolock() uses RCU

[PATCH] mm/page_alloc: document that alloc_pages_nolock() uses RCU

[Brendan Jackman]

The allocator interacts with cgroups which rely on RCU. RCU does not
work everywhere, so the "any context" claim is slightly overstated here.

This should already be enforced by objtool, since this function is not
marked noinstr the x86 build should fail if you call it from a place
where RCU is not watching. But, expecting readers to make that
connection for themselves seems a bit cruel (I don't think there is even
any documentation of what noinstr means at all, let alone the connection
with RCU).

Note this is not claiming that any cgroup code called from the allocator
would actually break if this restriction was violated, it could very
well be that there's no real way for the allocator to act on a cgroup
that can disappear concurrently. But, since it's likely nobody has
verified this one way or another, better to just be safe and declare
that RCU is required. Allocating from an RCU-unsafe context seems a bit
crazy anyway.

Suggested-by: Junaid Shahid <jackmanb@google.com>
Signed-off-by: Brendan Jackman <jackmanb@google.com>
---
 mm/page_alloc.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index e262d1316259d..7e647d047a2e3 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -7938,8 +7938,8 @@ struct page *alloc_frozen_pages_nolock_noprof(gfp_t gfp_flags, int nid, unsigned
  * @order: allocation order size
  *
  * Allocates pages of a given order from the given node. This is safe to
- * call from any context (from atomic, NMI, and also reentrant
- * allocator -> tracepoint -> alloc_pages_nolock_noprof).
+ * call from any context where RCU is watching (from atomic, NMI, and also
+ * reentrant allocator -> tracepoint -> alloc_pages_nolock_noprof).
  * Allocation is best effort and to be expected to fail easily so nobody should
  * rely on the success. Failures are not reported via warn_alloc().
  * See always fail conditions below.

---
base-commit: 444fc9435e57157fcf30fc99aee44997f3458641
change-id: 20260519-nolock-rcu-comment-8e6eac83b6b8

Best regards,
-- 
Brendan Jackman <jackmanb@google.com>

Re: [PATCH] mm/page_alloc: document that alloc_pages_nolock() uses RCU

[Harry Yoo]

On 5/19/26 11:17 PM, Brendan Jackman wrote:
> The allocator interacts with cgroups which rely on RCU. RCU does not
> work everywhere, so the "any context" claim is slightly overstated here.
> 
> This should already be enforced by objtool, since this function is not
> marked noinstr the x86 build should fail if you call it from a place
> where RCU is not watching.

What prevents an NMI from triggering when RCU isn't watching?
Oh, wait. an NMI causes RCU to start watching!

> But, expecting readers to make that
> connection for themselves seems a bit cruel

Agreed.

 > (I don't think there is even> any documentation of what noinstr means 
at all, let alone the connection
> with RCU).

*flips through the documentation*
Oh, perhaps Documentation/core-api/entry.rst?

> Note this is not claiming that any cgroup code called from the allocator
> would actually break if this restriction was violated, it could very
> well be that there's no real way for the allocator to act on a cgroup
> that can disappear concurrently. But, since it's likely nobody has
> verified this one way or another, better to just be safe and declare
> that RCU is required. Allocating from an RCU-unsafe context seems a bit
> crazy anyway.
> 
> Suggested-by: Junaid Shahid <jackmanb@google.com>

The email should be junaids@google.com, not jackmanb@google.com? ;)

> Signed-off-by: Brendan Jackman <jackmanb@google.com>
> ---

Otherwise LGTM!

Acked-by: Harry Yoo (Oracle) <harry@kernel.org>

-- 
Cheers,
Harry / Hyeonggon

Re: [PATCH] mm/page_alloc: document that alloc_pages_nolock() uses RCU

[Brendan Jackman]

On Wed May 20, 2026 at 5:16 AM CEST, Harry Yoo wrote:
>  > (I don't think there is even> any documentation of what noinstr means 
> at all, let alone the connection
>> with RCU).
>
> *flips through the documentation*
> Oh, perhaps Documentation/core-api/entry.rst?

Oh, you're right. The situation is way better than I thought, and now
I realise I have read this and it's probably where I learned about
this in the first place (I thought I learned it all from Junaid). I
apologise to the Documentation/ tree for my slander.

>> Note this is not claiming that any cgroup code called from the allocator
>> would actually break if this restriction was violated, it could very
>> well be that there's no real way for the allocator to act on a cgroup
>> that can disappear concurrently. But, since it's likely nobody has
>> verified this one way or another, better to just be safe and declare
>> that RCU is required. Allocating from an RCU-unsafe context seems a bit
>> crazy anyway.
>> 
>> Suggested-by: Junaid Shahid <jackmanb@google.com>
>
> The email should be junaids@google.com, not jackmanb@google.com? ;)

Damn. It looks like this already went into mm-unstable but I guess
it's not a huge deal.

Re: [PATCH] mm/page_alloc: document that alloc_pages_nolock() uses RCU

[Vlastimil Babka (SUSE)]

On 5/26/26 12:14 PM, Brendan Jackman wrote:
> On Wed May 20, 2026 at 5:16 AM CEST, Harry Yoo wrote:
>>  > (I don't think there is even> any documentation of what noinstr means 
>> at all, let alone the connection
>>> with RCU).
>>
>> *flips through the documentation*
>> Oh, perhaps Documentation/core-api/entry.rst?
> 
> Oh, you're right. The situation is way better than I thought, and now
> I realise I have read this and it's probably where I learned about
> this in the first place (I thought I learned it all from Junaid). I
> apologise to the Documentation/ tree for my slander.
> 
>>> Note this is not claiming that any cgroup code called from the allocator
>>> would actually break if this restriction was violated, it could very
>>> well be that there's no real way for the allocator to act on a cgroup
>>> that can disappear concurrently. But, since it's likely nobody has
>>> verified this one way or another, better to just be safe and declare
>>> that RCU is required. Allocating from an RCU-unsafe context seems a bit
>>> crazy anyway.
>>>
>>> Suggested-by: Junaid Shahid <jackmanb@google.com>
>>
>> The email should be junaids@google.com, not jackmanb@google.com? ;)
> 
> Damn. It looks like this already went into mm-unstable but I guess
> it's not a huge deal.

Things in mm-unstable can be fixed up. That's why "unstable".

Acked-by: Vlastimil Babka (SUSE) <vbabka@kernel.org>