Re: [PATCH 1/1] riscv/mm: fix soft-dirty migration PMDs being treated as present

[Lance Yang <lance.yang@linux.dev>]

On Wed, Oct 07, 2026 at 07:33:45PM +0800, Lance Yang wrote:
>
>On Wed, Oct 07, 2026 at 01:01:14PM +0200, David Hildenbrand (Arm) wrote:
>>On 10/5/26 15:46, Lance Yang wrote:
>>> 
>>> On Mon, Oct 05, 2026 at 12:37:20PM +0200, David Hildenbrand (Arm) wrote:
>>>> On 10/4/26 05:03, Lance Yang wrote:
>>>>> RISC-V uses _PAGE_EXEC for swap soft-dirty tracking when
>>>>> CONFIG_MEM_SOFT_DIRTY is enabled and Svrsw60t59b is available. That's
>>>>> a problem for PMD migration entries, since pmd_present() also checks
>>>>> _PAGE_LEAF (R/W/X) to recognize THPs with _PAGE_PRESENT temporarily
>>>>> cleared during splitting.
>>>>
>>>> I'm curious: why do we have to set leaf indications for non-present things? The
>>>> HW sure will ignore it, right?
>>> 
>>> Yeah, that surprised me too :) Still wrapping my head around the details
>>> ...
>>> 
>>>> Is this a sw problem? Who needs that?
>>> 
>>> IIUC, it's for software during a PMD split.
>>> 
>>> __split_huge_pmd_locked() invalidates the huge PMD and flushes the TLB
>>> before installing the PTE table. Software still needs pmd_present() and
>>> pmd_trans_huge() to recognize the THP in between.
>>> 
>>> RISC-V clears V but keeps the R/W/X bits for that, so the entry is invalid
>>> to hardware but still identifiable as a THP by software.
>>> 
>>> Hopefully I didn't miss something.
>>
>>I thought some change we performed to GUP-fast wouldn't require that anymore.
>>But my memory is a bit vague ... :)
>
>Yeah, I'll have another look at that :)

Emm ... I'm back. Do you mean 4b471e8898c3, which removed the GUP-fast
pmd_trans_splitting() check after the THP refcounting rework? That check
made GUP-fast bail out during the old THP split. The refcounting rework
made extra GUP references prevent the physical split :)

RISC-V gained THP support in 2021 (e88b333142e4), after
pmd_trans_splitting() had been removed. It never implemented that helper.

Keeping R/W/X in an invalidated RISC-V PMD preserves its leaf identity for
software page-table walks. That requirement is separate from the old
GUP-fast splitting check.

For RISC-V, pmd_mkinvalid() clears V and PROT_NONE but keeps R/W/X, so
pmd_present() and pmd_trans_huge() still return true:

#define _PAGE_LEAF (_PAGE_READ | _PAGE_WRITE | _PAGE_EXEC)

static inline pmd_t pmd_mkinvalid(pmd_t pmd)
{
	return __pmd(pmd_val(pmd) & ~(_PAGE_PRESENT|_PAGE_PROT_NONE));
}

static inline int pmd_present(pmd_t pmd)
{
	/*
	 * Checking for _PAGE_LEAF is needed too because:
	 * When splitting a THP, split_huge_page() will temporarily clear
	 * the present bit, in this situation, pmd_present() and
	 * pmd_trans_huge() still needs to return true.
	 */
	return (pmd_val(pmd) & (_PAGE_PRESENT | _PAGE_PROT_NONE | _PAGE_LEAF));
}

static inline bool pmd_leaf(pmd_t pmd)
{
	return pmd_present(pmd) && (pmd_val(pmd) & _PAGE_LEAF);
}

static inline int pmd_trans_huge(pmd_t pmd)
{
	return pmd_leaf(pmd);
}

And the rmap walk also needs that leaf indication. page_vma_mapped_walk()
checks pmd_trans_huge() before taking the PMD lock, then rereads the entry
under the lock. Keeping R/W/X lets it recognize the invalidated THP and
wait for the split to finish :)

Anyway, R/W/X still have a job there (RISC-V doesn't have a separate leaf
bit), and I don't think we can just drop them yet :D

Cheers, Lance

[...]