[PATCH 0/3] mm: remove page_mapped()

[PATCH 0/3] mm: remove page_mapped()

[David Hildenbrand (Arm)]

While preparing my slides for an LSF/MM talk, I realized that I did not
yet remove page_mapped().

So let's do that. In the BPF arena code it's unclear which memdesc we
would want to allocate in the future: certainly something with a
refcount, but likely none with a mapcount. So let's just rely on
the page refcount instead to decide whether we want to try zapping the
page from user page tables.

Signed-off-by: David Hildenbrand (Arm) <david@kernel.org>
---
David Hildenbrand (Arm) (3):
      sh: use folio_mapped() instead of page_mapped() in sh4_flush_cache_page()
      bpf: arena: use page_ref_count() instead of page_mapped() in arena_free_pages()
      mm: remove page_mapped()

 arch/sh/mm/cache-sh4.c |  2 +-
 include/linux/mm.h     | 10 ----------
 kernel/bpf/arena.c     |  2 +-
 mm/memory.c            |  2 +-
 mm/rmap.c              |  8 ++++----
 5 files changed, 7 insertions(+), 17 deletions(-)

---

base-commit: a2ddbfd1af0f54ea84bf17f0400088815d012e8d

change-id: 20260422-page_mapped-a49a892fa432

--

Cheers,

David

[PATCH 1/3] sh: use folio_mapped() instead of page_mapped() in sh4_flush_cache_page()

[David Hildenbrand (Arm)]

We already have the folio in our hands, so let's just use
folio_mapped().

Signed-off-by: David Hildenbrand (Arm) <david@kernel.org>
---
 arch/sh/mm/cache-sh4.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/sh/mm/cache-sh4.c b/arch/sh/mm/cache-sh4.c
index 83fb34b39ca7..8bc9ce541c14 100644
--- a/arch/sh/mm/cache-sh4.c
+++ b/arch/sh/mm/cache-sh4.c
@@ -248,7 +248,7 @@ static void sh4_flush_cache_page(void *args)
 		 */
 		map_coherent = (current_cpu_data.dcache.n_aliases &&
 			test_bit(PG_dcache_clean, folio_flags(folio, 0)) &&
-			page_mapped(page));
+			folio_mapped(folio));
 		if (map_coherent)
 			vaddr = kmap_coherent(page, address);
 		else

-- 
2.43.0

[PATCH 2/3] bpf: arena: use page_ref_count() instead of page_mapped() in arena_free_pages()

[David Hildenbrand (Arm)]

Pages that BPF arena code maps are allocated through
bpf_map_alloc_pages(), which does not allocate folios but pages.

In the future, pages will not have a mapcount, only folios will.
Converting the code to use folios and rely on folio_mapped() sounds like
the wrong approach.

Should BPF arena code allocate folios and use folio_mapped() here? But
likely we would not want to use folios here longterm, as we don't really
need folio information.

Hard to tell. But in the meantime, we can simply use the page refcount
instead, as a heuristic whether the page might be mapped to user space
and we would want to try zapping it, so we can get rid of page_mapped().

Page allocation will give us a page with a refcount of 1. Any user space
mapping adds a page reference. While there can be references from other
subsystems (e.g., GUP), in the common case for this test here relying on
the page count is good enough.

Signed-off-by: David Hildenbrand (Arm) <david@kernel.org>
---
 kernel/bpf/arena.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kernel/bpf/arena.c b/kernel/bpf/arena.c
index 802656c6fd3c..608c55c260bc 100644
--- a/kernel/bpf/arena.c
+++ b/kernel/bpf/arena.c
@@ -729,7 +729,7 @@ static void arena_free_pages(struct bpf_arena *arena, long uaddr, long page_cnt,
 
 	llist_for_each_safe(pos, t, __llist_del_all(&free_pages)) {
 		page = llist_entry(pos, struct page, pcp_llist);
-		if (page_cnt == 1 && page_mapped(page)) /* mapped by some user process */
+		if (page_cnt == 1 && page_ref_count(page) > 1) /* maybe mapped by user space */
 			/* Optimization for the common case of page_cnt==1:
 			 * If page wasn't mapped into some user vma there
 			 * is no need to call zap_pages which is slow. When

-- 
2.43.0

[PATCH 3/3] mm: remove page_mapped()

[David Hildenbrand (Arm)]

Let's replace the last user of page_mapped() by folio_mapped() so we
can get rid of page_mapped().

Replace the remaining occurrences of page_mapped() in rmap documentation
by folio_mapped().

Signed-off-by: David Hildenbrand (Arm) <david@kernel.org>
---
 include/linux/mm.h | 10 ----------
 mm/memory.c        |  2 +-
 mm/rmap.c          |  8 ++++----
 3 files changed, 5 insertions(+), 15 deletions(-)

diff --git a/include/linux/mm.h b/include/linux/mm.h
index af23453e9dbd..87fcd068303a 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -1888,16 +1888,6 @@ static inline bool folio_mapped(const struct folio *folio)
 	return folio_mapcount(folio) >= 1;
 }
 
-/*
- * Return true if this page is mapped into pagetables.
- * For compound page it returns true if any sub-page of compound page is mapped,
- * even if this particular sub-page is not itself mapped by any PTE or PMD.
- */
-static inline bool page_mapped(const struct page *page)
-{
-	return folio_mapped(page_folio(page));
-}
-
 static inline struct page *virt_to_head_page(const void *x)
 {
 	struct page *page = virt_to_page(x);
diff --git a/mm/memory.c b/mm/memory.c
index ea6568571131..99854e6a2793 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -5464,7 +5464,7 @@ static vm_fault_t __do_fault(struct vm_fault *vmf)
 	if (unlikely(PageHWPoison(vmf->page))) {
 		vm_fault_t poisonret = VM_FAULT_HWPOISON;
 		if (ret & VM_FAULT_LOCKED) {
-			if (page_mapped(vmf->page))
+			if (folio_mapped(folio))
 				unmap_mapping_folio(folio);
 			/* Retry if a clean folio was removed from the cache. */
 			if (mapping_evict_folio(folio->mapping, folio))
diff --git a/mm/rmap.c b/mm/rmap.c
index 78b7fb5f367c..fb3c351f8c45 100644
--- a/mm/rmap.c
+++ b/mm/rmap.c
@@ -571,7 +571,7 @@ void __init anon_vma_init(void)
  * In case it was remapped to a different anon_vma, the new anon_vma will be a
  * child of the old anon_vma, and the anon_vma lifetime rules will therefore
  * ensure that any anon_vma obtained from the page will still be valid for as
- * long as we observe page_mapped() [ hence all those page_mapped() tests ].
+ * long as we observe folio_mapped() [ hence all those folio_mapped() tests ].
  *
  * All users of this function must be very careful when walking the anon_vma
  * chain and verify that the page in question is indeed mapped in it
@@ -1999,7 +1999,7 @@ static bool try_to_unmap_one(struct folio *folio, struct vm_area_struct *vma,
 	/*
 	 * When racing against e.g. zap_pte_range() on another cpu,
 	 * in between its ptep_get_and_clear_full() and folio_remove_rmap_*(),
-	 * try_to_unmap() may return before page_mapped() has become false,
+	 * try_to_unmap() may return before folio_mapped() has become false,
 	 * if page table locking is skipped: use TTU_SYNC to wait for that.
 	 */
 	if (flags & TTU_SYNC)
@@ -2426,7 +2426,7 @@ static bool try_to_migrate_one(struct folio *folio, struct vm_area_struct *vma,
 	/*
 	 * When racing against e.g. zap_pte_range() on another cpu,
 	 * in between its ptep_get_and_clear_full() and folio_remove_rmap_*(),
-	 * try_to_migrate() may return before page_mapped() has become false,
+	 * try_to_migrate() may return before folio_mapped() has become false,
 	 * if page table locking is skipped: use TTU_SYNC to wait for that.
 	 */
 	if (flags & TTU_SYNC)
@@ -2927,7 +2927,7 @@ static struct anon_vma *rmap_walk_anon_lock(const struct folio *folio,
 
 	/*
 	 * Note: remove_migration_ptes() cannot use folio_lock_anon_vma_read()
-	 * because that depends on page_mapped(); but not all its usages
+	 * because that depends on folio_mapped(); but not all its usages
 	 * are holding mmap_lock. Users without mmap_lock are required to
 	 * take a reference count to prevent the anon_vma disappearing
 	 */

-- 
2.43.0

Re: [PATCH 2/3] bpf: arena: use page_ref_count() instead of page_mapped() in arena_free_pages()

[Andrew Morton]

On Mon, 27 Apr 2026 13:43:15 +0200 "David Hildenbrand (Arm)" <david@kernel.org> wrote:

> Pages that BPF arena code maps are allocated through
> bpf_map_alloc_pages(), which does not allocate folios but pages.
> 
> In the future, pages will not have a mapcount, only folios will.
> Converting the code to use folios and rely on folio_mapped() sounds like
> the wrong approach.
> 
> Should BPF arena code allocate folios and use folio_mapped() here? But
> likely we would not want to use folios here longterm, as we don't really
> need folio information.
> 
> Hard to tell. But in the meantime, we can simply use the page refcount
> instead, as a heuristic whether the page might be mapped to user space
> and we would want to try zapping it, so we can get rid of page_mapped().
> 
> Page allocation will give us a page with a refcount of 1. Any user space
> mapping adds a page reference. While there can be references from other
> subsystems (e.g., GUP), in the common case for this test here relying on
> the page count is good enough.
> 
> Signed-off-by: David Hildenbrand (Arm) <david@kernel.org>
> ---
>  kernel/bpf/arena.c | 2 +-

BPF maintainers will probably want to carry this in the BPF tree. 
That's fine - please go ahead and add it.  I'll carry a duplicate in
mm.git so it compiles.

Re: [PATCH 1/3] sh: use folio_mapped() instead of page_mapped() in sh4_flush_cache_page()

[Matthew Wilcox]

On Mon, Apr 27, 2026 at 01:43:14PM +0200, David Hildenbrand (Arm) wrote:
> We already have the folio in our hands, so let's just use
> folio_mapped().
> 
> Signed-off-by: David Hildenbrand (Arm) <david@kernel.org>

Thanks; that was an oversight on my part.

Reviewed-by: Matthew Wilcox (Oracle) <willy@infradead.org>

Re: [PATCH 2/3] bpf: arena: use page_ref_count() instead of page_mapped() in arena_free_pages()

[Matthew Wilcox]

On Mon, Apr 27, 2026 at 01:43:15PM +0200, David Hildenbrand (Arm) wrote:
> Pages that BPF arena code maps are allocated through
> bpf_map_alloc_pages(), which does not allocate folios but pages.
> 
> In the future, pages will not have a mapcount, only folios will.
> Converting the code to use folios and rely on folio_mapped() sounds like
> the wrong approach.
> 
> Should BPF arena code allocate folios and use folio_mapped() here? But
> likely we would not want to use folios here longterm, as we don't really
> need folio information.
> 
> Hard to tell. But in the meantime, we can simply use the page refcount
> instead, as a heuristic whether the page might be mapped to user space
> and we would want to try zapping it, so we can get rid of page_mapped().
> 
> Page allocation will give us a page with a refcount of 1. Any user space
> mapping adds a page reference. While there can be references from other
> subsystems (e.g., GUP), in the common case for this test here relying on
> the page count is good enough.

Well, if we GUPped the page, it must have been mapped at some point ;-)

Anyway, I approve of this patch; it lets us defer the hard decisions and
work until we know what we really need.

Reviewed-by: Matthew Wilcox (Oracle) <willy@infradead.org>

Re: [PATCH 3/3] mm: remove page_mapped()

[Matthew Wilcox]

On Mon, Apr 27, 2026 at 01:43:16PM +0200, David Hildenbrand (Arm) wrote:
> Let's replace the last user of page_mapped() by folio_mapped() so we
> can get rid of page_mapped().

Yay!

> Replace the remaining occurrences of page_mapped() in rmap documentation
> by folio_mapped().

Reviewed-by: Matthew Wilcox (Oracle) <willy@infradead.org>

> +++ b/mm/memory.c
> @@ -5464,7 +5464,7 @@ static vm_fault_t __do_fault(struct vm_fault *vmf)
>  	if (unlikely(PageHWPoison(vmf->page))) {
>  		vm_fault_t poisonret = VM_FAULT_HWPOISON;
>  		if (ret & VM_FAULT_LOCKED) {
> -			if (page_mapped(vmf->page))
> +			if (folio_mapped(folio))
>  				unmap_mapping_folio(folio);

The idiot who authored 01d1e0e6b7d9 really should have done this at the
time ... Oh, wait, I see what I was trying to do.

I believe my thinking was that we only needed to unmap the folio if
this specific page that had hardware poison was mapped.  But no, we need
to unmap the entire folio if any page in it is mapped.

Does the affect recoverability from hwpoison?  I don't think so.  When
we detect hwpoison, the first thing we try to do is split the folio.
Of course that can fail, but if we do, we kill the process.

So yes, my R-b above stands.

Re: [PATCH 3/3] mm: remove page_mapped()

[Andrew Morton]

On Mon, 27 Apr 2026 13:43:16 +0200 "David Hildenbrand (Arm)" <david@kernel.org> wrote:

> Let's replace the last user of page_mapped() by folio_mapped() so we
> can get rid of page_mapped().
> 
> Replace the remaining occurrences of page_mapped() in rmap documentation
> by folio_mapped().

This broke Breno's "mm/memory-failure: add panic option for
unrecoverable pages"
(https://lore.kernel.org/20260424-ecc_panic-v5-2-a35f4b50425c@debian.org),
which added a new page_mapped() call.  I made the below adjustment to
Breno's patch:

--- a/mm/memory-failure.c~mm-memory-failure-add-panic-option-for-unrecoverable-pages-fix
+++ a/mm/memory-failure.c
@@ -1353,7 +1353,7 @@ static bool panic_on_unrecoverable_mf(un
 		cpu_relax();
 		return page_count(p) == 0 &&
 		       !PageLRU(p) &&
-		       !page_mapped(p) &&
+		       !folio_mapped(page_folio(p)) &&
 		       !page_folio(p)->mapping &&
 		       !is_free_buddy_page(p);
 	default:
_

Re: [PATCH 3/3] mm: remove page_mapped()

[David Hildenbrand (Arm)]

On 4/27/26 15:21, Andrew Morton wrote:
> On Mon, 27 Apr 2026 13:43:16 +0200 "David Hildenbrand (Arm)" <david@kernel.org> wrote:
> 
>> Let's replace the last user of page_mapped() by folio_mapped() so we
>> can get rid of page_mapped().
>>
>> Replace the remaining occurrences of page_mapped() in rmap documentation
>> by folio_mapped().
> 
> This broke Breno's "mm/memory-failure: add panic option for
> unrecoverable pages"
> (https://lore.kernel.org/20260424-ecc_panic-v5-2-a35f4b50425c@debian.org),
> which added a new page_mapped() call.  I made the below adjustment to
> Breno's patch:
> 
> --- a/mm/memory-failure.c~mm-memory-failure-add-panic-option-for-unrecoverable-pages-fix
> +++ a/mm/memory-failure.c
> @@ -1353,7 +1353,7 @@ static bool panic_on_unrecoverable_mf(un
>  		cpu_relax();
>  		return page_count(p) == 0 &&
>  		       !PageLRU(p) &&
> -		       !page_mapped(p) &&
> +		       !folio_mapped(page_folio(p)) &&
>  		       !page_folio(p)->mapping &&

If we have a folio, we should really lookup the folio once. Not 4 times.

Breno's patch likely needs some love. :)

-- 
Cheers,

David

Re: [PATCH 3/3] mm: remove page_mapped()

[Breno Leitao]

Hello David,

On Mon, Apr 27, 2026 at 03:23:33PM +0200, David Hildenbrand (Arm) wrote:
> On 4/27/26 15:21, Andrew Morton wrote:
> > On Mon, 27 Apr 2026 13:43:16 +0200 "David Hildenbrand (Arm)" <david@kernel.org> wrote:
> > 
> >> Let's replace the last user of page_mapped() by folio_mapped() so we
> >> can get rid of page_mapped().
> >>
> >> Replace the remaining occurrences of page_mapped() in rmap documentation
> >> by folio_mapped().
> > 
> > This broke Breno's "mm/memory-failure: add panic option for
> > unrecoverable pages"
> > (https://lore.kernel.org/20260424-ecc_panic-v5-2-a35f4b50425c@debian.org),
> > which added a new page_mapped() call.  I made the below adjustment to
> > Breno's patch:
> > 
> > --- a/mm/memory-failure.c~mm-memory-failure-add-panic-option-for-unrecoverable-pages-fix
> > +++ a/mm/memory-failure.c
> > @@ -1353,7 +1353,7 @@ static bool panic_on_unrecoverable_mf(un
> >  		cpu_relax();
> >  		return page_count(p) == 0 &&
> >  		       !PageLRU(p) &&
> > -		       !page_mapped(p) &&
> > +		       !folio_mapped(page_folio(p)) &&
> >  		       !page_folio(p)->mapping &&
> 
> If we have a folio, we should really lookup the folio once. Not 4 times.

Why 4 times?

> Breno's patch likely needs some love. :)

Would something like the following give it all the love in the world?

 folio = page_folio(p);
 return page_count(p) == 0 &&
        !PageLRU(p) &&
        !folio_mapped(folio) &&
        !folio->mapping &&
        !is_free_buddy_page(p);

Thanks,
--breno

Re: [PATCH 3/3] mm: remove page_mapped()

[Matthew Wilcox]

On Mon, Apr 27, 2026 at 07:42:46AM -0700, Breno Leitao wrote:
> > > @@ -1353,7 +1353,7 @@ static bool panic_on_unrecoverable_mf(un
> > >  		cpu_relax();
> > >  		return page_count(p) == 0 &&
> > >  		       !PageLRU(p) &&
> > > -		       !page_mapped(p) &&
> > > +		       !folio_mapped(page_folio(p)) &&
> > >  		       !page_folio(p)->mapping &&
> > 
> > If we have a folio, we should really lookup the folio once. Not 4 times.
> 
> Why 4 times?

Because there are page_folio() calls hidden in PageLRU, page_mapped()
and page_count().

> > Breno's patch likely needs some love. :)
> 
> Would something like the following give it all the love in the world?
> 
>  folio = page_folio(p);
>  return page_count(p) == 0 &&
>         !PageLRU(p) &&
>         !folio_mapped(folio) &&
>         !folio->mapping &&
>         !is_free_buddy_page(p);

No.  You need to immerse yourself more deeply in the folio transition
;-)

Re: [PATCH 2/3] bpf: arena: use page_ref_count() instead of page_mapped() in arena_free_pages()

[Alexei Starovoitov]

On Mon, Apr 27, 2026 at 1:18 PM Andrew Morton <akpm@linux-foundation.org> wrote:
>
> On Mon, 27 Apr 2026 13:43:15 +0200 "David Hildenbrand (Arm)" <david@kernel.org> wrote:
>
> > Pages that BPF arena code maps are allocated through
> > bpf_map_alloc_pages(), which does not allocate folios but pages.
> >
> > In the future, pages will not have a mapcount, only folios will.
> > Converting the code to use folios and rely on folio_mapped() sounds like
> > the wrong approach.
> >
> > Should BPF arena code allocate folios and use folio_mapped() here?

no

> But
> > likely we would not want to use folios here longterm, as we don't really
> > need folio information.

exactly

> > Hard to tell. But in the meantime, we can simply use the page refcount
> > instead, as a heuristic whether the page might be mapped to user space
> > and we would want to try zapping it, so we can get rid of page_mapped().
> >
> > Page allocation will give us a page with a refcount of 1. Any user space
> > mapping adds a page reference. While there can be references from other
> > subsystems (e.g., GUP), in the common case for this test here relying on
> > the page count is good enough.

makes sense to me.

> >
> > Signed-off-by: David Hildenbrand (Arm) <david@kernel.org>
> > ---
> >  kernel/bpf/arena.c | 2 +-
>
> BPF maintainers will probably want to carry this in the BPF tree.
> That's fine - please go ahead and add it.  I'll carry a duplicate in
> mm.git so it compiles.

We cannot carry the same patch in 2 trees.
Sooner or later it will create problems for linux-next
and issues during merge window if more changes
are done in the same area.
The only way to share a patch between trees is to
create a stable branch and pull it into 2 trees
then sha will be the same,
but mm tree has its own way of doing things,
so this patch needs to stay in mm only and if no one
should be touching adjacent lines :(

Re: [PATCH 2/3] bpf: arena: use page_ref_count() instead of page_mapped() in arena_free_pages()

[Andrew Morton]

On Mon, 27 Apr 2026 16:00:59 +0100 Alexei Starovoitov <alexei.starovoitov@gmail.com> wrote:

> > >
> > > Signed-off-by: David Hildenbrand (Arm) <david@kernel.org>
> > > ---
> > >  kernel/bpf/arena.c | 2 +-
> >
> > BPF maintainers will probably want to carry this in the BPF tree.
> > That's fine - please go ahead and add it.  I'll carry a duplicate in
> > mm.git so it compiles.
> 
> We cannot carry the same patch in 2 trees.

Git is fine with that.

> Sooner or later it will create problems for linux-next
> and issues during merge window if more changes
> are done in the same area.
> The only way to share a patch between trees is to
> create a stable branch and pull it into 2 trees
> then sha will be the same,

For a single one-line patch?

Re: [PATCH 2/3] bpf: arena: use page_ref_count() instead of page_mapped() in arena_free_pages()

[Alexei Starovoitov]

On Mon, Apr 27, 2026 at 4:15 PM Andrew Morton <akpm@linux-foundation.org> wrote:
>
> On Mon, 27 Apr 2026 16:00:59 +0100 Alexei Starovoitov <alexei.starovoitov@gmail.com> wrote:
>
> > > >
> > > > Signed-off-by: David Hildenbrand (Arm) <david@kernel.org>
> > > > ---
> > > >  kernel/bpf/arena.c | 2 +-
> > >
> > > BPF maintainers will probably want to carry this in the BPF tree.
> > > That's fine - please go ahead and add it.  I'll carry a duplicate in
> > > mm.git so it compiles.
> >
> > We cannot carry the same patch in 2 trees.
>
> Git is fine with that.
>
> > Sooner or later it will create problems for linux-next
> > and issues during merge window if more changes
> > are done in the same area.
> > The only way to share a patch between trees is to
> > create a stable branch and pull it into 2 trees
> > then sha will be the same,
>
> For a single one-line patch?

Number of changed lines is irrelevant.
If there will be a commit on top that moves this line
or lines within the hunk, git will be confused depending
on order of pulls.
We learned this lesson the hard way.