Re: [PATCH v4 02/12] mm/rmap: Add try_to_unmap_hugetlb_one

[David Hildenbrand (Arm)]

On 6/18/26 11:09, Lance Yang wrote:
> 
> 
> On 2026/6/18 15:55, David Hildenbrand (Arm) wrote:
>>>     return __rste_to_pte(pte_val(*ptep));
>>> }
>>>
>>>
>>> So plain ptep_get() can feed raw huge-entry bits into pte_pfn(), and the
>>> derived subpage can be wrong.
>>
>> Good question which impact that might have in practice?
> 
> The subpage check can warn, but we still pass that subpage to
> make_hwpoison_entry(). So the hwpoison marker can end up with the
> wrong PFN?
> 
> +    subpage = folio_page(folio, pte_pfn(pteval) - folio_pfn(folio));
> +    VM_WARN_ON(folio_page(folio, 0) != subpage);
> [...]
> +    pteval = swp_entry_to_pte(make_hwpoison_entry(subpage));

My s390x page table knowledge is a bit rusty.

IIUC, it would be a problem if some PTE bits in segment/region entries (pmd/pud/
...) would pass the

	 pte_pfn(x) -> (pte_val(x) >> PAGE_SHIFT)

check. I don't think this applies, because

While
	#define _SEGMENT_ENTRY_ORIGIN_LARGE ~0xfffffUL

We also have

	#define _SEGMENT_ENTRY_ORIGIN ~0x7ffUL

So these bits are not actually used.

What __rste_to_pte() primarily does is reshuffling present bits etc.

So using any other bits besides the PFN would be problematic I guess.

Am I wrong or isn't the present bit already at a different location? For
prot-none hugetlb folios there might be a real issue, as the PTE present bit
corresponds to the PMD/PUD read-permission bit.


Oh my :)

So yeah, we should probably fix that ahead of time unless I am missing
something? Good that we separate that hugetlb crap out.

-- 
Cheers,

David