Re: [Question] get_vma_policy() isn't compatible with {pin, get}_user_pages_remote

["Huang, Ying" <ying.huang@linux.alibaba.com>]

Jinjiang Tu <tujinjiang@huawei.com> writes:

> 在 2025/7/8 9:53, Huang, Ying 写道:
>> Hi, Jinjiang,
>>
>> Jinjiang Tu <tujinjiang@huawei.com> writes:
>>
>>> get_vma_policy() returns the mempolicy for the vma. If the vma has set
>>> mempolicy, the policy is returned. Otherwise,
>>> call get_task_policy(current) to get the mempolicy of current
>>> task. However, it isn't reasonable for
>>> pin_user_pages_remote() and get_user_pages_remote() cases.
>>>
>>> Assume task A calls pin_user_pages_remote() to pin user pages from
>>> task B. If the [start, start + nr_pages) isn't
>>> populated with pages, handle_mm_fault() will be called by task
>>> A. However, if the vma doesn't set memory policy,
>>> the mempolicy of task A instead of task B is used to allocate. It
>>> seems to be unreasonable. See
>>> dequeue_hugetlb_folio_vma()->huge_node().
>>>
>>> We can only obtain mm in get_vma_policy(), but we couldn't get the
>>> task, since a mm can be associated with multiple
>>> tasks(threads) and the task mempolicy is at thread granularity.
>>>
>>> Is this situation reasonable? And if not, how could we fix it?
>> Yes.  This sounds like an issue in theory and it's hard to be resolved
>> if possible.  Please take a look at get_user_pages_remote() usage in
>> exec().
>
> IIUC, exec() replaces current->mm with new mm, and the task_struct isn't changed,
> thus task mempolicy is same, so it is reasonable to use get_user_pages_remote() in exec().
>
>> Do you have some practical issue with pin/get_user_pages_remote()?
>
> Yes, I have a driver to pin_user_pages_remote() for other task.

Please give more details of your issue to help us to understand it.  For
example, why cannot you use pin_user_pages()?

---
Best Regards,
Huang, Ying