Make sure we return the right pud value and not a value that could
have been overwritten in between by a different core.

Fixes: c3cc2a4a3a23 ("riscv: Add support for PUD THP")
Cc: stable@vger.kernel.org
Signed-off-by: Alexandre Ghiti <alexghiti@rivosinc.com>
---
Note that this will conflict with
https://lore.kernel.org/linux-riscv/20250625063753.77511-1-ajd@linux.ibm.com/
if applied after 6.17.
---
 arch/riscv/include/asm/pgtable.h | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/arch/riscv/include/asm/pgtable.h b/arch/riscv/include/asm/pgtable.h
index 91697fbf1f9013005800f713797e4b6b1fc8d312..e69346307e78608dd98d8b7a77b7063c333448ee 100644
--- a/arch/riscv/include/asm/pgtable.h
+++ b/arch/riscv/include/asm/pgtable.h
@@ -942,6 +942,17 @@ static inline int pudp_test_and_clear_young(struct vm_area_struct *vma,
 	return ptep_test_and_clear_young(vma, address, (pte_t *)pudp);
 }
 
+#define __HAVE_ARCH_PUDP_HUGE_GET_AND_CLEAR
+static inline pud_t pudp_huge_get_and_clear(struct mm_struct *mm,
+					    unsigned long address, pud_t *pudp)
+{
+	pud_t pud = __pud(atomic_long_xchg((atomic_long_t *)pudp, 0));
+
+	page_table_check_pud_clear(mm, pud);
+
+	return pud;
+}
+
 static inline int pud_young(pud_t pud)
 {
 	return pte_young(pud_pte(pud));

---
base-commit: 62950c35a515743739e3d863eac25c20a5bd1613
change-id: 20250814-dev-alex-thp_pud_xchg-8153c313d946

Best regards,
-- 
Alexandre Ghiti <alexghiti@rivosinc.com>

Hi Alex,

On Thu, 14 Aug 2025, Alexandre Ghiti wrote:

> Make sure we return the right pud value and not a value that could
> have been overwritten in between by a different core.
> 
> Fixes: c3cc2a4a3a23 ("riscv: Add support for PUD THP")
> Cc: stable@vger.kernel.org
> Signed-off-by: Alexandre Ghiti <alexghiti@rivosinc.com>
> ---
> Note that this will conflict with
> https://lore.kernel.org/linux-riscv/20250625063753.77511-1-ajd@linux.ibm.com/
> if applied after 6.17.

Two quick questions on this one:

- I see that you're using atomic_long_xchg() here and in some similar 
functions in pgtable.h, rather than xchg().  Was curious about the 
rationale for that?

- x86 avoids the xchg() for !CONFIG_SMP.  Should we do the same?

thanks,

- Paul

On 9/20/25 03:39, Paul Walmsley wrote:
> Hi Alex,
>
> On Thu, 14 Aug 2025, Alexandre Ghiti wrote:
>
>> Make sure we return the right pud value and not a value that could
>> have been overwritten in between by a different core.
>>
>> Fixes: c3cc2a4a3a23 ("riscv: Add support for PUD THP")
>> Cc: stable@vger.kernel.org
>> Signed-off-by: Alexandre Ghiti <alexghiti@rivosinc.com>
>> ---
>> Note that this will conflict with
>> https://lore.kernel.org/linux-riscv/20250625063753.77511-1-ajd@linux.ibm.com/
>> if applied after 6.17.
> Two quick questions on this one:
>
> - I see that you're using atomic_long_xchg() here and in some similar
> functions in pgtable.h, rather than xchg().  Was curious about the
> rationale for that?


Both functions amount to the same, I just used the same function as for 
existing similar functions.


>
> - x86 avoids the xchg() for !CONFIG_SMP.  Should we do the same?


Sounds like micro optimization to me, but up to you.


>
> thanks,
>
> - Paul
>