Re: [PATCH 1/3] mm: move internal mempolicy APIs to new internal header

On Wed Jul 22, 2026 at 3:15 PM UTC, Brendan Jackman wrote:
...
>>> We have a long history of people just moving stuff around in patches
>>> without knowing what the intent was if it should be moved.
>>
>> I guess this patch is not critical to the rest, if that's an issue.
>
> Well, for ALLOC_UNMAPPED we really do need an alloc_flags arg for this
> function, but we can always just go straight to what I described above.
> I.e. I can create the __ variant + wrapper from the start. It's just a
> question of whether we prefer:
>
> - "Yuck, there's a public wrapper here that we don't actually need", or
>
> - "We hid this mempolicy API and people might think we'd NACK a patch to
>   un-hide it".0
>
>   https://lore.kernel.org/all/20260703-alloc-trylock-v5-2-c87b714e19d3@go=
ogle.com/

Uh yeah so in v3 I did not depend on this patch, I just went straight to
creating __folio_alloc_mpol_noprof() here:

https://lore.kernel.org/all/20260726-page_alloc-unmapped-v3-25-6f5729aa9832=
@google.com/

So yeah I'd say we can just drop this controversial patch and move
forwards with the other two?