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@xxxxxxxxxx>

The email should be junaids@xxxxxxxxxx, not jackmanb@xxxxxxxxxx? ;)

> Signed-off-by: Brendan Jackman <jackmanb@xxxxxxxxxx>
> ---

Otherwise LGTM!

Acked-by: Harry Yoo (Oracle) <harry@xxxxxxxxxx>

--
Cheers,
Harry / Hyeonggon