Re: [PATCH v3 2/3] mm: gup: allow long-term pins of CMA-allocated HugeTLB folios

["David Hildenbrand (Arm)" <david@kernel.org>]

On 11/11/26 11:26, Qi Zheng wrote:
> Hi David,
> 
> On 11/11/26 3:43 PM, David Hildenbrand (Arm) wrote:
>> On 11/9/26 04:10, Qi Zheng wrote:
>>>
>>>
>>>
>>
>> You resent your series way too fast.
> 
> Got it.
> 
>>
>> Now we have discussions in to threads, congratulations ;)
>>
>>> ;), got it.
>>>
>>> I moved the code to resolve a build dependency.
>>>
>>
>> Why can't that be resolved differently? What is the dependency?
> 
> The dependency is that the new check wants to use
> `folio_test_hugetlb_cma()`, which is a HugeTLB-specific inline helper
> from `include/linux/hugetlb.h`.
> 
> `folio_is_longterm_pinnable()` currently lives in `include/linux/mm.h`,
> while `include/linux/hugetlb.h` already includes `linux/mm.h`. So I
> can't simply use `folio_test_hugetlb_cma()` from `mm.h`

It's all so hacky. :)

core-mm shouldn't have to worry about hugetlb internals like
folio_test_hugetlb_cma().

>>>
>>> A generic query may need separate ownership tracking, such as an
>>> owned_bitmap recording successfully allocated pages. Its updates and
>>> lookups would also need to handle concurrency with fast GUP.
>>
>> Or simply two bitmaps? "trying allocation - allocated"
> 
> As a fix, perhaps this is a bit too complex? :(
> 
> Alternatively, we could adjust the timing for setting the bitmap, though
> this might introduce new concurrency issues.

I think we had that order reversed in the past. Likely a second bitmap would
allow us to fix it fairly easily.


-- 
Cheers,

David