Let's get rid of another page_mapcount() check and simply use
folio_likely_mapped_shared(), which is precise for hugetlb folios.

While at it, use huge_ptep_get() + pte_page() instead of ptep_get() +
vm_normal_page(), just like we do in pagemap_hugetlb_range().

No functional change intended.

Signed-off-by: David Hildenbrand <david@redhat.com>
---
 fs/proc/task_mmu.c | 13 +++++++------
 1 file changed, 7 insertions(+), 6 deletions(-)

diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c
index cd6e45e0cde8e..f4259b7edfded 100644
--- a/fs/proc/task_mmu.c
+++ b/fs/proc/task_mmu.c
@@ -730,19 +730,20 @@ static int smaps_hugetlb_range(pte_t *pte, unsigned long hmask,
 {
 	struct mem_size_stats *mss = walk->private;
 	struct vm_area_struct *vma = walk->vma;
-	struct page *page = NULL;
-	pte_t ptent = ptep_get(pte);
+	pte_t ptent = huge_ptep_get(pte);
+	struct folio *folio = NULL;
 
 	if (pte_present(ptent)) {
-		page = vm_normal_page(vma, addr, ptent);
+		folio = page_folio(pte_page(ptent));
 	} else if (is_swap_pte(ptent)) {
 		swp_entry_t swpent = pte_to_swp_entry(ptent);
 
 		if (is_pfn_swap_entry(swpent))
-			page = pfn_swap_entry_to_page(swpent);
+			folio = pfn_swap_entry_folio(swpent);
 	}
-	if (page) {
-		if (page_mapcount(page) >= 2 || hugetlb_pmd_shared(pte))
+	if (folio) {
+		if (folio_likely_mapped_shared(folio) ||
+		    hugetlb_pmd_shared(pte))
 			mss->shared_hugetlb += huge_page_size(hstate_vma(vma));
 		else
 			mss->private_hugetlb += huge_page_size(hstate_vma(vma));
-- 
2.44.0

On Wed, Apr 17, 2024 at 11:23:13AM +0200, David Hildenbrand wrote:
> Let's get rid of another page_mapcount() check and simply use
> folio_likely_mapped_shared(), which is precise for hugetlb folios.
> 
> While at it, use huge_ptep_get() + pte_page() instead of ptep_get() +
> vm_normal_page(), just like we do in pagemap_hugetlb_range().

That is fine because vm_normal_page() tries to be clever about  mappings which
hugetlb does not support, right?

> 
> No functional change intended.
> 
> Signed-off-by: David Hildenbrand <david@redhat.com>

Reviewed-by: Oscar Salvador <osalvador@suse.de>


-- 
Oscar Salvador
SUSE Labs

On 17.04.24 14:09, Oscar Salvador wrote:
> On Wed, Apr 17, 2024 at 11:23:13AM +0200, David Hildenbrand wrote:
>> Let's get rid of another page_mapcount() check and simply use
>> folio_likely_mapped_shared(), which is precise for hugetlb folios.
>>
>> While at it, use huge_ptep_get() + pte_page() instead of ptep_get() +
>> vm_normal_page(), just like we do in pagemap_hugetlb_range().
> 
> That is fine because vm_normal_page() tries to be clever about  mappings which
> hugetlb does not support, right?

Right, using vm_normal_page() is even completely bogus. Usually (but not 
always) we have PMDs/PUDs and not PTEs for mapping hugetlb pages -- 
where vm_normal_folio_pmd() would be the right thing to do.

That's also the reason why hugetlb.c has not a single user of 
vm_normal_page() and friends ... it doesn't apply to hugetlb, but likely 
also isn't currently harmful to use it.

-- 
Cheers,

David / dhildenb

On Wed, Apr 17, 2024 at 02:18:10PM +0200, David Hildenbrand wrote:
> On 17.04.24 14:09, Oscar Salvador wrote:
> > On Wed, Apr 17, 2024 at 11:23:13AM +0200, David Hildenbrand wrote:
> > > Let's get rid of another page_mapcount() check and simply use
> > > folio_likely_mapped_shared(), which is precise for hugetlb folios.
> > > 
> > > While at it, use huge_ptep_get() + pte_page() instead of ptep_get() +
> > > vm_normal_page(), just like we do in pagemap_hugetlb_range().
> > 
> > That is fine because vm_normal_page() tries to be clever about  mappings which
> > hugetlb does not support, right?
> 
> Right, using vm_normal_page() is even completely bogus. Usually (but not
> always) we have PMDs/PUDs and not PTEs for mapping hugetlb pages -- where
> vm_normal_folio_pmd() would be the right thing to do.
> 
> That's also the reason why hugetlb.c has not a single user of
> vm_normal_page() and friends ... it doesn't apply to hugetlb, but likely
> also isn't currently harmful to use it.

I guess not because we skip the special handling, but I agree that
replacing it is the right thing to do.
Thanks for explaining!
 

-- 
Oscar Salvador
SUSE Labs