[PATCH -fixes 0/2] Fix set_huge_pte_at()

[PATCH -fixes 0/2] Fix set_huge_pte_at()

[Alexandre Ghiti]

A recent report [1] from Ryan for arm64 revealed that we do not handle
swap entries when setting a hugepage backed by a NAPOT region (the
contpte riscv equivalent).

As explained in [1], the issue was discovered by a new test in kselftest
which uses poison entries, but the symptoms are different from arm64 though:

- the riscv kernel bugs because we do not handle VM_FAULT_HWPOISON*,
  this is fixed by patch 1,
- after that, the test passes because the first pte_napot() fails (the
  poison entry does not have the N bit set), and then we only set the
  first page table entry covering the NAPOT hugepage, which is enough
  for hugetlb_fault() to correctly raise a VM_FAULT_HWPOISON wherever we
  write in this mapping since only this first page table entry is
  checked
  (see https://elixir.bootlin.com/linux/v6.6-rc3/source/mm/hugetlb.c#L6071).
  But this seems fragile so patch 2 sets all page table entries of a
  NAPOT mapping.

[1]: https://lore.kernel.org/linux-arm-kernel/20230922115804.2043771-1-ryan.roberts@arm.com/


Alexandre Ghiti (2):
  riscv: Handle VM_FAULT_[HWPOISON|HWPOISON_LARGE] faults instead of
    panicking
  riscv: Fix set_huge_pte_at() for NAPOT mappings when a swap entry is
    set

 arch/riscv/mm/fault.c       |  2 +-
 arch/riscv/mm/hugetlbpage.c | 19 +++++++++++++------
 2 files changed, 14 insertions(+), 7 deletions(-)

-- 
2.39.2


_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

[PATCH -fixes 1/2] riscv: Handle VM_FAULT_[HWPOISON|HWPOISON_LARGE] faults instead of panicking

[Alexandre Ghiti]

We used to panic when such faults were encountered but we should handle
those faults gracefully for userspace by sending a SIGBUS to the process,
like most architectures do.

Signed-off-by: Alexandre Ghiti <alexghiti@rivosinc.com>
---
 arch/riscv/mm/fault.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/riscv/mm/fault.c b/arch/riscv/mm/fault.c
index 6115d7514972..90d4ba36d1d0 100644
--- a/arch/riscv/mm/fault.c
+++ b/arch/riscv/mm/fault.c
@@ -72,7 +72,7 @@ static inline void mm_fault_error(struct pt_regs *regs, unsigned long addr, vm_f
 		}
 		pagefault_out_of_memory();
 		return;
-	} else if (fault & VM_FAULT_SIGBUS) {
+	} else if (fault & (VM_FAULT_SIGBUS | VM_FAULT_HWPOISON | VM_FAULT_HWPOISON_LARGE)) {
 		/* Kernel mode? Handle exceptions or die */
 		if (!user_mode(regs)) {
 			no_context(regs, addr);
-- 
2.39.2


_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

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

[Alexandre Ghiti]

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@arm.com>
Closes: https://lore.kernel.org/linux-arm-kernel/20230922115804.2043771-1-ryan.roberts@arm.com/ [1]
Signed-off-by: Alexandre Ghiti <alexghiti@rivosinc.com>
---
 arch/riscv/mm/hugetlbpage.c | 19 +++++++++++++------
 1 file changed, 13 insertions(+), 6 deletions(-)

diff --git a/arch/riscv/mm/hugetlbpage.c b/arch/riscv/mm/hugetlbpage.c
index e4a2ace92dbe..b52f0210481f 100644
--- a/arch/riscv/mm/hugetlbpage.c
+++ b/arch/riscv/mm/hugetlbpage.c
@@ -183,15 +183,22 @@ void set_huge_pte_at(struct mm_struct *mm,
 		     pte_t pte,
 		     unsigned long sz)
 {
+	unsigned long hugepage_shift;
 	int i, pte_num;
 
-	if (!pte_napot(pte)) {
-		set_pte_at(mm, addr, ptep, pte);
-		return;
-	}
+	if (sz >= PGDIR_SIZE)
+		hugepage_shift = PGDIR_SHIFT;
+	else if (sz >= P4D_SIZE)
+		hugepage_shift = P4D_SHIFT;
+	else if (sz >= PUD_SIZE)
+		hugepage_shift = PUD_SHIFT;
+	else if (sz >= PMD_SIZE)
+		hugepage_shift = PMD_SHIFT;
+	else
+		hugepage_shift = PAGE_SHIFT;
 
-	pte_num = napot_pte_num(napot_cont_order(pte));
-	for (i = 0; i < pte_num; i++, ptep++, addr += PAGE_SIZE)
+	pte_num = sz >> hugepage_shift;
+	for (i = 0; i < pte_num; i++, ptep++, addr += (1 << hugepage_shift))
 		set_pte_at(mm, addr, ptep, pte);
 }
 
-- 
2.39.2


_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

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

[Conor Dooley]

[-- Attachment #1.1: Type: text/plain, Size: 2407 bytes --]

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@arm.com>
> Closes: https://lore.kernel.org/linux-arm-kernel/20230922115804.2043771-1-ryan.roberts@arm.com/ [1]
> Signed-off-by: Alexandre Ghiti <alexghiti@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...

Thanks,
Conor.

> ---
>  arch/riscv/mm/hugetlbpage.c | 19 +++++++++++++------
>  1 file changed, 13 insertions(+), 6 deletions(-)
> 
> diff --git a/arch/riscv/mm/hugetlbpage.c b/arch/riscv/mm/hugetlbpage.c
> index e4a2ace92dbe..b52f0210481f 100644
> --- a/arch/riscv/mm/hugetlbpage.c
> +++ b/arch/riscv/mm/hugetlbpage.c
> @@ -183,15 +183,22 @@ void set_huge_pte_at(struct mm_struct *mm,
>  		     pte_t pte,
>  		     unsigned long sz)
>  {
> +	unsigned long hugepage_shift;
>  	int i, pte_num;
>  
> -	if (!pte_napot(pte)) {
> -		set_pte_at(mm, addr, ptep, pte);
> -		return;
> -	}
> +	if (sz >= PGDIR_SIZE)
> +		hugepage_shift = PGDIR_SHIFT;
> +	else if (sz >= P4D_SIZE)
> +		hugepage_shift = P4D_SHIFT;
> +	else if (sz >= PUD_SIZE)
> +		hugepage_shift = PUD_SHIFT;
> +	else if (sz >= PMD_SIZE)
> +		hugepage_shift = PMD_SHIFT;
> +	else
> +		hugepage_shift = PAGE_SHIFT;
>  
> -	pte_num = napot_pte_num(napot_cont_order(pte));
> -	for (i = 0; i < pte_num; i++, ptep++, addr += PAGE_SIZE)
> +	pte_num = sz >> hugepage_shift;
> +	for (i = 0; i < pte_num; i++, ptep++, addr += (1 << hugepage_shift))
>  		set_pte_at(mm, addr, ptep, pte);
>  }
>  
> -- 
> 2.39.2
> 
> 
> _______________________________________________
> linux-riscv mailing list
> linux-riscv@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-riscv

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

[-- Attachment #2: Type: text/plain, Size: 161 bytes --]

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

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

[Alexandre Ghiti]

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@arm.com>
>> Closes: https://lore.kernel.org/linux-arm-kernel/20230922115804.2043771-1-ryan.roberts@arm.com/ [1]
>> Signed-off-by: Alexandre Ghiti <alexghiti@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? The patch which this series 
depends on just made it to rc4.

Thanks,

Alex


> Thanks,
> Conor.
>
>> ---
>>   arch/riscv/mm/hugetlbpage.c | 19 +++++++++++++------
>>   1 file changed, 13 insertions(+), 6 deletions(-)
>>
>> diff --git a/arch/riscv/mm/hugetlbpage.c b/arch/riscv/mm/hugetlbpage.c
>> index e4a2ace92dbe..b52f0210481f 100644
>> --- a/arch/riscv/mm/hugetlbpage.c
>> +++ b/arch/riscv/mm/hugetlbpage.c
>> @@ -183,15 +183,22 @@ void set_huge_pte_at(struct mm_struct *mm,
>>   		     pte_t pte,
>>   		     unsigned long sz)
>>   {
>> +	unsigned long hugepage_shift;
>>   	int i, pte_num;
>>   
>> -	if (!pte_napot(pte)) {
>> -		set_pte_at(mm, addr, ptep, pte);
>> -		return;
>> -	}
>> +	if (sz >= PGDIR_SIZE)
>> +		hugepage_shift = PGDIR_SHIFT;
>> +	else if (sz >= P4D_SIZE)
>> +		hugepage_shift = P4D_SHIFT;
>> +	else if (sz >= PUD_SIZE)
>> +		hugepage_shift = PUD_SHIFT;
>> +	else if (sz >= PMD_SIZE)
>> +		hugepage_shift = PMD_SHIFT;
>> +	else
>> +		hugepage_shift = PAGE_SHIFT;
>>   
>> -	pte_num = napot_pte_num(napot_cont_order(pte));
>> -	for (i = 0; i < pte_num; i++, ptep++, addr += PAGE_SIZE)
>> +	pte_num = sz >> hugepage_shift;
>> +	for (i = 0; i < pte_num; i++, ptep++, addr += (1 << hugepage_shift))
>>   		set_pte_at(mm, addr, ptep, pte);
>>   }
>>   
>> -- 
>> 2.39.2
>>
>>
>> _______________________________________________
>> linux-riscv mailing list
>> linux-riscv@lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-riscv
>>
>> _______________________________________________
>> linux-riscv mailing list
>> linux-riscv@lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-riscv

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

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

[Conor Dooley]

[-- Attachment #1.1: Type: text/plain, Size: 2283 bytes --]

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@arm.com>
> > > Closes: https://lore.kernel.org/linux-arm-kernel/20230922115804.2043771-1-ryan.roberts@arm.com/ [1]
> > > Signed-off-by: Alexandre Ghiti <alexghiti@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.

Thanks,
Conor.

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

[-- Attachment #2: Type: text/plain, Size: 161 bytes --]

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

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

[Andrew Jones]

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@arm.com>
> Closes: https://lore.kernel.org/linux-arm-kernel/20230922115804.2043771-1-ryan.roberts@arm.com/ [1]
> Signed-off-by: Alexandre Ghiti <alexghiti@rivosinc.com>
> ---
>  arch/riscv/mm/hugetlbpage.c | 19 +++++++++++++------
>  1 file changed, 13 insertions(+), 6 deletions(-)
> 
> diff --git a/arch/riscv/mm/hugetlbpage.c b/arch/riscv/mm/hugetlbpage.c
> index e4a2ace92dbe..b52f0210481f 100644
> --- a/arch/riscv/mm/hugetlbpage.c
> +++ b/arch/riscv/mm/hugetlbpage.c
> @@ -183,15 +183,22 @@ void set_huge_pte_at(struct mm_struct *mm,
>  		     pte_t pte,
>  		     unsigned long sz)
>  {
> +	unsigned long hugepage_shift;
>  	int i, pte_num;
>  
> -	if (!pte_napot(pte)) {
> -		set_pte_at(mm, addr, ptep, pte);
> -		return;
> -	}
> +	if (sz >= PGDIR_SIZE)
> +		hugepage_shift = PGDIR_SHIFT;
> +	else if (sz >= P4D_SIZE)
> +		hugepage_shift = P4D_SHIFT;
> +	else if (sz >= PUD_SIZE)
> +		hugepage_shift = PUD_SHIFT;
> +	else if (sz >= PMD_SIZE)
> +		hugepage_shift = PMD_SHIFT;
> +	else
> +		hugepage_shift = PAGE_SHIFT;
>  
> -	pte_num = napot_pte_num(napot_cont_order(pte));
> -	for (i = 0; i < pte_num; i++, ptep++, addr += PAGE_SIZE)
> +	pte_num = sz >> hugepage_shift;
> +	for (i = 0; i < pte_num; i++, ptep++, addr += (1 << hugepage_shift))
>  		set_pte_at(mm, addr, ptep, pte);
>  }
>

So a 64k napot, for example, will fall into the PAGE_SHIFT arm, but then
we'll calculate 16 for pte_num. Looks good to me.

Reviewed-by: Andrew Jones <ajones@ventanamicro.com>

Thanks,
drew

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

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

[Alexandre Ghiti]

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@arm.com>
>>>> Closes: https://lore.kernel.org/linux-arm-kernel/20230922115804.2043771-1-ryan.roberts@arm.com/ [1]
>>>> Signed-off-by: Alexandre Ghiti <alexghiti@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@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-riscv

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: [PATCH -fixes 0/2] Fix set_huge_pte_at()

[Alexandre Ghiti]

+cc Andrew: Would  you mind taking this patchset in your tree for the 
next rc? This patchset depends on a previous fix for arm64 that you 
merged in rc4 which is not in the riscv -fixes branch yet.

I saw with Palmer and he should ack this shortly.

If I can do anything else to help, let me know.

Thanks,

Alex

On 28/09/2023 17:18, Alexandre Ghiti wrote:
> A recent report [1] from Ryan for arm64 revealed that we do not handle
> swap entries when setting a hugepage backed by a NAPOT region (the
> contpte riscv equivalent).
>
> As explained in [1], the issue was discovered by a new test in kselftest
> which uses poison entries, but the symptoms are different from arm64 though:
>
> - the riscv kernel bugs because we do not handle VM_FAULT_HWPOISON*,
>    this is fixed by patch 1,
> - after that, the test passes because the first pte_napot() fails (the
>    poison entry does not have the N bit set), and then we only set the
>    first page table entry covering the NAPOT hugepage, which is enough
>    for hugetlb_fault() to correctly raise a VM_FAULT_HWPOISON wherever we
>    write in this mapping since only this first page table entry is
>    checked
>    (see https://elixir.bootlin.com/linux/v6.6-rc3/source/mm/hugetlb.c#L6071).
>    But this seems fragile so patch 2 sets all page table entries of a
>    NAPOT mapping.
>
> [1]: https://lore.kernel.org/linux-arm-kernel/20230922115804.2043771-1-ryan.roberts@arm.com/
>
>
> Alexandre Ghiti (2):
>    riscv: Handle VM_FAULT_[HWPOISON|HWPOISON_LARGE] faults instead of
>      panicking
>    riscv: Fix set_huge_pte_at() for NAPOT mappings when a swap entry is
>      set
>
>   arch/riscv/mm/fault.c       |  2 +-
>   arch/riscv/mm/hugetlbpage.c | 19 +++++++++++++------
>   2 files changed, 14 insertions(+), 7 deletions(-)
>

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: [PATCH -fixes 0/2] Fix set_huge_pte_at()

[Andrew Morton]

On Tue, 3 Oct 2023 17:43:10 +0200 Alexandre Ghiti <alex@ghiti.fr> wrote:

> +cc Andrew: Would  you mind taking this patchset in your tree for the 
> next rc? This patchset depends on a previous fix for arm64 that you 
> merged in rc4 which is not in the riscv -fixes branch yet.
> 
> I saw with Palmer and he should ack this shortly.

Well I grabbed them into mm.git's mm-hotfixes-unstable queue.  All
being well I'll move them into mm-hotfixes-stable within a week then
into Linus shortly after.

Unless something changes.  It's odd that the riscv tree(s) aren't set
up to merge fixes against -rc4?

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: [PATCH -fixes 0/2] Fix set_huge_pte_at()

[Palmer Dabbelt]

On Tue, 03 Oct 2023 09:04:43 PDT (-0700), akpm@linux-foundation.org wrote:
> On Tue, 3 Oct 2023 17:43:10 +0200 Alexandre Ghiti <alex@ghiti.fr> wrote:
>
>> +cc Andrew: Would  you mind taking this patchset in your tree for the 
>> next rc? This patchset depends on a previous fix for arm64 that you 
>> merged in rc4 which is not in the riscv -fixes branch yet.
>> 
>> I saw with Palmer and he should ack this shortly.
>
> Well I grabbed them into mm.git's mm-hotfixes-unstable queue.  All
> being well I'll move them into mm-hotfixes-stable within a week then
> into Linus shortly after.
>
> Unless something changes.  It's odd that the riscv tree(s) aren't set
> up to merge fixes against -rc4?

It's mostly that I have COVID, so everything's kind of a mess right now.

Acked-by: Palmer Dabbelt <palmer@rivosinc.com>

Thanks!

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: [PATCH -fixes 0/2] Fix set_huge_pte_at()

[Alexandre Ghiti]

Hi Andrew,

On Tue, Oct 3, 2023 at 6:04 PM Andrew Morton <akpm@linux-foundation.org> wrote:
>
> On Tue, 3 Oct 2023 17:43:10 +0200 Alexandre Ghiti <alex@ghiti.fr> wrote:
>
> > +cc Andrew: Would  you mind taking this patchset in your tree for the
> > next rc? This patchset depends on a previous fix for arm64 that you
> > merged in rc4 which is not in the riscv -fixes branch yet.
> >
> > I saw with Palmer and he should ack this shortly.
>
> Well I grabbed them into mm.git's mm-hotfixes-unstable queue.  All
> being well I'll move them into mm-hotfixes-stable within a week then
> into Linus shortly after.

Those fixes finally did not make it to 6.6, I was hoping for them to
land in -rc6 or -rc7: for the future, what should have I done to avoid
that?

Thanks,

Alex

>
> Unless something changes.  It's odd that the riscv tree(s) aren't set
> up to merge fixes against -rc4?

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: [PATCH -fixes 0/2] Fix set_huge_pte_at()

[Andrew Morton]

On Thu, 26 Oct 2023 10:57:27 +0200 Alexandre Ghiti <alexghiti@rivosinc.com> wrote:

> On Tue, Oct 3, 2023 at 6:04 PM Andrew Morton <akpm@linux-foundation.org> wrote:
> >
> > On Tue, 3 Oct 2023 17:43:10 +0200 Alexandre Ghiti <alex@ghiti.fr> wrote:
> >
> > > +cc Andrew: Would  you mind taking this patchset in your tree for the
> > > next rc? This patchset depends on a previous fix for arm64 that you
> > > merged in rc4 which is not in the riscv -fixes branch yet.
> > >
> > > I saw with Palmer and he should ack this shortly.
> >
> > Well I grabbed them into mm.git's mm-hotfixes-unstable queue.  All
> > being well I'll move them into mm-hotfixes-stable within a week then
> > into Linus shortly after.
> 
> Those fixes finally did not make it to 6.6, I was hoping for them to
> land in -rc6 or -rc7: for the future, what should have I done to avoid
> that?

They're merged in Linus's tree.

6f1bace9a9fb arm64: hugetlb: fix set_huge_pte_at() to work with all swap entries
935d4f0c6dc8 mm: hugetlb: add huge page size param to set_huge_pte_at()

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: [PATCH -fixes 0/2] Fix set_huge_pte_at()

[Alexandre Ghiti]

n 26/10/2023 16:13, Andrew Morton wrote:
> On Thu, 26 Oct 2023 10:57:27 +0200 Alexandre Ghiti <alexghiti@rivosinc.com> wrote:
>
>> On Tue, Oct 3, 2023 at 6:04 PM Andrew Morton <akpm@linux-foundation.org> wrote:
>>> On Tue, 3 Oct 2023 17:43:10 +0200 Alexandre Ghiti <alex@ghiti.fr> wrote:
>>>
>>>> +cc Andrew: Would  you mind taking this patchset in your tree for the
>>>> next rc? This patchset depends on a previous fix for arm64 that you
>>>> merged in rc4 which is not in the riscv -fixes branch yet.
>>>>
>>>> I saw with Palmer and he should ack this shortly.
>>> Well I grabbed them into mm.git's mm-hotfixes-unstable queue.  All
>>> being well I'll move them into mm-hotfixes-stable within a week then
>>> into Linus shortly after.
>> Those fixes finally did not make it to 6.6, I was hoping for them to
>> land in -rc6 or -rc7: for the future, what should have I done to avoid
>> that?
> They're merged in Linus's tree.
>
> 6f1bace9a9fb arm64: hugetlb: fix set_huge_pte_at() to work with all swap entries
> 935d4f0c6dc8 mm: hugetlb: add huge page size param to set_huge_pte_at()


Oops, sorry, I missed them this morning!

Thanks,

Alex


_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: [PATCH -fixes 0/2] Fix set_huge_pte_at()

[Ryan Roberts]

On 26/10/2023 15:15, Alexandre Ghiti wrote:
> n 26/10/2023 16:13, Andrew Morton wrote:
>> On Thu, 26 Oct 2023 10:57:27 +0200 Alexandre Ghiti <alexghiti@rivosinc.com>
>> wrote:
>>
>>> On Tue, Oct 3, 2023 at 6:04 PM Andrew Morton <akpm@linux-foundation.org> wrote:
>>>> On Tue, 3 Oct 2023 17:43:10 +0200 Alexandre Ghiti <alex@ghiti.fr> wrote:
>>>>
>>>>> +cc Andrew: Would  you mind taking this patchset in your tree for the
>>>>> next rc? This patchset depends on a previous fix for arm64 that you
>>>>> merged in rc4 which is not in the riscv -fixes branch yet.
>>>>>
>>>>> I saw with Palmer and he should ack this shortly.
>>>> Well I grabbed them into mm.git's mm-hotfixes-unstable queue.  All
>>>> being well I'll move them into mm-hotfixes-stable within a week then
>>>> into Linus shortly after.
>>> Those fixes finally did not make it to 6.6, I was hoping for them to
>>> land in -rc6 or -rc7: for the future, what should have I done to avoid
>>> that?
>> They're merged in Linus's tree.
>>
>> 6f1bace9a9fb arm64: hugetlb: fix set_huge_pte_at() to work with all swap entries
>> 935d4f0c6dc8 mm: hugetlb: add huge page size param to set_huge_pte_at()
> 
> 
> Oops, sorry, I missed them this morning!

Those two patches that Andrew highlights are the fix I did for arm64. Weren't
you referring to the corresponding patches you did for riscv, Alex?

> 
> Thanks,
> 
> Alex
> 


_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: [PATCH -fixes 0/2] Fix set_huge_pte_at()

[Andrew Morton]

On Thu, 26 Oct 2023 15:30:44 +0100 Ryan Roberts <ryan.roberts@arm.com> wrote:

> >>> Those fixes finally did not make it to 6.6, I was hoping for them to
> >>> land in -rc6 or -rc7: for the future, what should have I done to avoid
> >>> that?
> >> They're merged in Linus's tree.
> >>
> >> 6f1bace9a9fb arm64: hugetlb: fix set_huge_pte_at() to work with all swap entries
> >> 935d4f0c6dc8 mm: hugetlb: add huge page size param to set_huge_pte_at()
> > 
> > 
> > Oops, sorry, I missed them this morning!
> 
> Those two patches that Andrew highlights are the fix I did for arm64. Weren't
> you referring to the corresponding patches you did for riscv, Alex?

These are in mainline:

1de195dd0e05 riscv: fix set_huge_pte_at() for NAPOT mappings when a swap entry is set
117b1bb0cbc7 riscv: handle VM_FAULT_[HWPOISON|HWPOISON_LARGE] faults instead of panicking

I'm not sure what happened to your "riscv: hugetlb: convert
set_huge_pte_at() to take vma" - perhaps it was updated.

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: [PATCH -fixes 0/2] Fix set_huge_pte_at()

[Ryan Roberts]

On 26/10/2023 15:54, Andrew Morton wrote:
> On Thu, 26 Oct 2023 15:30:44 +0100 Ryan Roberts <ryan.roberts@arm.com> wrote:
> 
>>>>> Those fixes finally did not make it to 6.6, I was hoping for them to
>>>>> land in -rc6 or -rc7: for the future, what should have I done to avoid
>>>>> that?
>>>> They're merged in Linus's tree.
>>>>
>>>> 6f1bace9a9fb arm64: hugetlb: fix set_huge_pte_at() to work with all swap entries
>>>> 935d4f0c6dc8 mm: hugetlb: add huge page size param to set_huge_pte_at()
>>>
>>>
>>> Oops, sorry, I missed them this morning!
>>
>> Those two patches that Andrew highlights are the fix I did for arm64. Weren't
>> you referring to the corresponding patches you did for riscv, Alex?
> 
> These are in mainline:
> 
> 1de195dd0e05 riscv: fix set_huge_pte_at() for NAPOT mappings when a swap entry is set
> 117b1bb0cbc7 riscv: handle VM_FAULT_[HWPOISON|HWPOISON_LARGE] faults instead of panicking

Ahh, great - I think they were probably the ones Alex was talking about.

> 
> I'm not sure what happened to your "riscv: hugetlb: convert
> set_huge_pte_at() to take vma" - perhaps it was updated.

I modified the approach for v2 (pass size param instead of vma) and it got
squashed into 935d4f0c6dc8 mm: hugetlb: add huge page size param to
set_huge_pte_at(), which is in.


_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv