Re: [PATCH v2 07/15] riscv/mm: preserve Svnapot leaf-size semantics for page-table consumers

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Single-CPU deadlock in `napotpte_ptep_get_lockless` when called from NMI/IRQ context during a partial Svnapot block update.
--

--- Patch [7]: [PATCH v2 07/15] riscv/mm: preserve Svnapot leaf-size semantics for page-table consumers ---
commit 0488a9106519eab47850cf758ecce3d0c6bdf46e
Author: Yunhui Cui <cuiyunhui@bytedance.com>

riscv/mm: preserve Svnapot leaf-size semantics for page-table consumers

Svnapot keeps a folded 64KB mapping encoded in the page table, while the
public PTE helpers may expose a logical per-page sub-PTE view. This patch
uses the original page-table entry for leaf-size queries so consumers
continue to observe the Svnapot leaf size instead of treating a folded
mapping as PAGE_SIZE entries.

> diff --git a/arch/riscv/include/asm/pgtable.h b/arch/riscv/include/asm/pgtable.h
> index da7ffea0dcd98..e4b9c05014c00 100644
> --- a/arch/riscv/include/asm/pgtable.h
> +++ b/arch/riscv/include/asm/pgtable.h
[ ... ]
> @@ -580,6 +580,17 @@ static inline pte_t pte_swp_clear_soft_dirty(pte_t pte)
>  					napot_cont_size(napot_cont_order(pte)) :\
>  					PAGE_SIZE)
>  
> +#define __ptep_leaf_size __ptep_leaf_size
> +static inline unsigned long __ptep_leaf_size(pmd_t pmd, pte_t *ptep, pte_t pte)
> +{
> +	pte_t raw_pte = READ_ONCE(*ptep);
> +
> +	if (pte_present_napot(raw_pte))
> +		return pte_leaf_size(raw_pte);
> +
> +	return PAGE_SIZE;
> +}

[Severity: High]
Can this lead to a single-CPU deadlock in NMI/IRQ context during a partial
Svnapot block update?

If a thread executing napotpte_convert() holds the page table lock (which
disables preemption but leaves NMIs and hardware IRQs enabled) and
sequentially clears PTEs in a 64KB Svnapot block:

arch/riscv/mm/contpte.c:napotpte_convert() {
...
	for (i = 0; i < nr; i++) {
		ptent_addr = start_addr + i * PAGE_SIZE;
		ptent = __ptep_get_and_clear_noptc(start_ptep + i);
...
}

And a Performance Monitoring Interrupt (PMI) interrupts this CPU after some
but not all PTEs are cleared, the PMI handler may invoke
perf_get_pgtable_size(), which eventually invokes the lockless PTE reader.

This would lead to napotpte_ptep_get_lockless() entering a retry loop:

arch/riscv/mm/contpte.c:napotpte_ptep_get_lockless() {
...
retry:
	orig_pte = READ_ONCE(*orig_ptep);
	if (!pte_present_napot(orig_pte))
		return orig_pte;

	ptep = napot_align_ptep(orig_ptep);

	for (i = 0; i < nr; i++, ptep++) {
		pte = READ_ONCE(*ptep);

		if (!napotpte_is_consistent(pte, orig_pte))
			goto retry;
...
}

Because the NMI/IRQ handler prevents the interrupted thread on the same CPU
from finishing the update, the block remains partially cleared. Does this
cause the consistency check to fail repeatedly, resulting in an infinite
loop and hard lockup?

Userspace could potentially trigger this via perf_event_open by sampling
memory accesses during Svnapot page migrations or unmapping.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/cover.1784201104.git.cuiyunhui@bytedance.com?part=7