Re: [PATCH v8 02/15] mm: rename pointers to software PTE values as ptentp

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] mm: missed software PTE pointer rename in damon_hugetlb_ptep_mkold
--

commit a7aa8dc368dae477c79fe8a52a9e505b4cbf8802
Author: Muhammad Usama Anjum <usama.anjum@arm.com>

mm: rename pointers to software PTE values as ptentp

This commit renames pointers to software PTE values to ptentp in
certain functions. This ensures they are excluded from a subsequent
Coccinelle conversion of PTE table pointers to hw_pte_t *.

> Rename these parameters in the install_pte callback,
> write_protect_page(), and guard_install_set_pte() to ptentp. The later
> Coccinelle conversion skips pointers named ptentp, allowing it to convert
> the remaining PTE table pointers without changing these interfaces.

[Severity: Low]
Was damon_hugetlb_ptep_mkold() in mm/damon/vaddr.c missed during this
renaming sweep?

It appears the entry parameter in damon_hugetlb_ptep_mkold() is a pointer
to a software PTE value:

mm/damon/vaddr.c:
static bool damon_hugetlb_ptep_mkold(pte_t *pte, struct mm_struct *mm,
		struct vm_area_struct *vma, unsigned long addr, pte_t *entry)

Because this wasn't renamed to ptentp, a subsequent Coccinelle conversion
to hw_pte_t * misses this parameter. Meanwhile, the caller
damon_hugetlb_mkold() is updated to use hw_pte_t *.

On architectures like s390 where hw_pte_t is a distinct struct type rather
than a typedef, this mismatch between the caller's hw_pte_t * and the
callee's pte_t * (as well as passing a pte_t * to huge_ptep_get_and_clear
which expects hw_pte_t *) triggers an incompatible pointer type build failure
when CONFIG_HUGETLB_PAGE is enabled.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/cover.1791365932.git.agordeev@linux.ibm.com?part=2