On 22/09/2023 10:14, Christophe Leroy wrote:
>
>
> Le 22/09/2023 à 10:41, Ryan Roberts a écrit :
>> On 22/09/2023 09:10, Christophe Leroy wrote:
>>>
>>>
>>>> I'm happy to take your proposed approach if that's your preference. Another
>>>> option is to use a dummy VMA, as I have done in the core code, for the one call
>>>> site that calls set_huge_pte_at() with init_mm:
>>>>
>>>> struct vm_area_struct vma = TLB_FLUSH_VMA(&init_mm, 0);
>>>>
>>>> This is an existing macro that creates a dummy vma with vma->vm_mm filled in.
>>>> Then I pass &vma to the function.
>>>
>>> I don't like that, I prefer the solution I proposed. We already have a
>>> couple places where powerpc do things based on whether vma is NULL or not.
>>>
>>>>
>>>> Or yet another option would be to keep the mm param as is in set_huge_pte_at(),
>>>> and add a size param to the function. But then all call sites have the burden of
>>>> figuring out the size of the huge pte (although I think most know already).
>>>
>>> Indeed.
>>>
>>> arch_make_huge_pte() used to take a vma until commit 79c1c594f49a
>>> ("mm/hugetlb: change parameters of arch_make_huge_pte()").
>>>
>>> Should we try and have the same approach ? Or is it irrelevant ?
>>
>> See [1]; I'm going to rework to pass mm + size parameter since the current
>> approach will break riscv.
>
> Can you pass a shift parameter instead of a size, like
> arch_make_huge_pte() ? As far as I remember it is easier to handle a
> shift than a size.
Most of the call sites already have the size, not the shift. And arm64 needs the
size, so it would have do (1UL << shift). So on that basis, I prefer to pass
size. huge_pte_clear() already passes long unsigned sz, so I'd rather follow
that pattern.
>
> Christophe
