[PATCH -fixes 2/2] riscv: Fix set_huge_pte_at() for NAPOT mappings when a swap entry is set

Alexandre Ghiti alex at ghiti.fr
Tue Oct 3 08:35:22 PDT 2023


Hey Conor,

On 02/10/2023 15:11, Conor Dooley wrote:
> On Mon, Oct 02, 2023 at 09:18:52AM +0200, Alexandre Ghiti wrote:
>> Hi Conor,
>>
>> On 30/09/2023 11:14, Conor Dooley wrote:
>>> On Thu, Sep 28, 2023 at 05:18:46PM +0200, Alexandre Ghiti wrote:
>>>> We used to determine the number of page table entries to set for a NAPOT
>>>> hugepage by using the pte value which actually fails when the pte to set is
>>>> a swap entry.
>>>>
>>>> So take advantage of a recent fix for arm64 reported in [1] which
>>>> introduces the size of the mapping as an argument of set_huge_pte_at(): we
>>>> can then use this size to compute the number of page table entries to set
>>>> for a NAPOT region.
>>>>
>>>> Fixes: 82a1a1f3bfb6 ("riscv: mm: support Svnapot in hugetlb page")
>>>> Reported-by: Ryan Roberts <ryan.roberts at arm.com>
>>>> Closes: https://lore.kernel.org/linux-arm-kernel/20230922115804.2043771-1-ryan.roberts@arm.com/ [1]
>>>> Signed-off-by: Alexandre Ghiti <alexghiti at rivosinc.com>
>>> Breaks the build. Your $subject marks this for -fixes, but this will not
>>> build there, as it relies on content that's not yet in that branch.
>>> AFAICT, you're going to have to resend this with akpm on CC, as the
>>> dependency is in his tree...
>>
>> I see, but I still don't understand why -fixes does not point to the latest
>> rcX instead of staying on rc1?
> It's up to Palmer what he does with his fixes branch, but two thoughts.
> Doing what you suggest would require rebasing things not yet sent to Linus
> every week and fast-forwarding when PRs are actually merged.
> IIRC, Palmer used to do something like the latter, but IIRC he got some
> complaints about that and switched to the current method.
> At the very least, you should point out dependencies like this, as I
> figure an individual patch could be applied on top of -rc4 and merged
> in. Both Palmer and I have submitted things for b4 to improve support for
> doing things exactly like this ;)
>
>> The patch which this series depends on just made it to rc4.
> However, if you do not mention what the deps for your patches are
> explicitly, how are people supposed to know? The reference to the
> dependency makes it look like a report for a similar problem that also
> applies to riscv, not a pre-requisite for the patch.


You're right, I saw the dependency being merged so I thought it would be 
ok but I should have mention it. I have just discussed with Palmer, and 
I'll +cc Andrew to see if he can take that in his tree.

Thanks!

Alex


>
> Thanks,
> Conor.
>
> _______________________________________________
> linux-riscv mailing list
> linux-riscv at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-riscv



More information about the linux-riscv mailing list