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

On 7/29/26 13:50, Brendan Jackman wrote:
> 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-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org/
> 
> 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-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org/
> 
> So yeah I'd say we can just drop this controversial patch and move
> forwards with the other two?

Ack.