From: "David Hildenbrand (Arm)" <david@kernel.org>
To: Lorenzo Stoakes <ljs@kernel.org>,
"Liam R. Howlett" <liam@infradead.org>,
Vlastimil Babka <vbabka@kernel.org>,
Mike Rapoport <rppt@kernel.org>,
Suren Baghdasaryan <surenb@google.com>,
Michal Hocko <mhocko@suse.com>,
"Matthew Wilcox (Oracle)" <willy@infradead.org>,
Jan Kara <jack@suse.cz>,
Andrew Morton <akpm@linux-foundation.org>,
Zi Yan <ziy@nvidia.com>,
Baolin Wang <baolin.wang@linux.alibaba.com>,
Nico Pache <nico.pache@linux.dev>,
Ryan Roberts <ryan.roberts@arm.com>, Dev Jain <dev.jain@arm.com>,
Barry Song <baohua@kernel.org>,
Lance Yang <lance.yang@linux.dev>,
Usama Arif <usama.arif@linux.dev>,
Kiryl Shutsemau <kas@kernel.org>,
Matthew Brost <matthew.brost@intel.com>,
Joshua Hahn <joshua.hahnjy@gmail.com>,
Byungchul Park <byungchul@sk.com>,
Gregory Price <gourry@gourry.net>,
Ying Huang <ying.huang@linux.alibaba.com>,
Alistair Popple <apopple@nvidia.com>,
Peter Xu <peterx@redhat.com>,
Johannes Weiner <hannes@cmpxchg.org>,
Song Liu <songliubraving@fb.com>,
Rik van Riel <riel@surriel.com>,
Miklos Szeredi <miklos@szeredi.hu>,
Alexander Viro <viro@zeniv.linux.org.uk>,
Christian Brauner <brauner@kernel.org>,
Hugh Dickins <hughd@google.com>, Will Deacon <will@kernel.org>,
"Aneesh Kumar K.V" <aneesh.kumar@kernel.org>,
Nick Piggin <npiggin@gmail.com>,
Peter Zijlstra <peterz@infradead.org>,
Arnd Bergmann <arnd@arndb.de>, Jason Gunthorpe <jgg@ziepe.ca>,
Kevin Tian <kevin.tian@intel.com>,
"Joerg Roedel (AMD)" <joro@8bytes.org>,
Robin Murphy <robin.murphy@arm.com>,
Steve Sistare <steven.sistare@oracle.com>,
John Hubbard <jhubbard@nvidia.com>,
"Jose A. Perez de Azpillaga" <azpijr@gmail.com>,
Josef Bacik <josef@toxicpanda.com>
Cc: "David Hildenbrand (Arm)" <david@kernel.org>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
linux-fsdevel@vger.kernel.org, fuse-devel@lists.linux.dev,
linux-arch@vger.kernel.org, iommu@lists.linux.dev,
Chris Mason <mason@kernel.org>,
stable@vger.kernel.org, Jason Gunthorpe <jgg@ziepe.ca>
Subject: [PATCH v2 0/5] mm: limit pagecache folio refcount
Date: Sat, 07 Nov 2026 23:23:36 +0100 [thread overview]
Message-ID: <20261107-refcount_overflow_stable-v2-0-c38f6809b106@kernel.org> (raw)
Users can create a lot of folio references to pagecache folios, making
it possible to overflow the refcount of large folios.
While we knew that one could in theory overflow a folio's refcount, we
mostly assumed that bad things would happen and it wouldn't go
unnoticed.
Not so sure if that is really always the case, and leaving that problem
unsolved is irresponsible, so let's limit pagecache folio refcounts.
This is really only relevant for large folios / thps in the page cache.
With anon folios (including THPs), we should not be
able to trigger folio refcount overflows (until we get PUD-sized ones ;) ).
It was likely a problem for anon folios as well before we had a
dedicated pincount.
Let's limit the refcount before it turns negative, giving admin processes
some extra reserves (to recover a problematic system). We still leave some
headroom to allow for some slight limit overshooting, to make the
implementation easier.
Then, we also check when splicing pagecache folios to a pipe, and
improve our existing checks in gup. We also have to take care of
mmu_gather, to not hold too many references when zapping (whereby new
page faults could remap pages concurrently).
This is only a temporary solution for upstream+stable, until we have
something better.
These fixes will be a bit challenging to backport to stable, but it will
be much easier compared to the RFC series I have here were we do things
properly by (what we discussed a couple of times earlier):
- Letting the mapcount of large folios be a long
- Holding a single refcount if the folio is mapped, across all mappings
- Reverting the limits introduced in this series
I'll polish that up and send it once we merged something that can be
backported to stable.
Tested on x86-64 by lowering the folio refcount limits such that limits
can easily be exceeded, to then test fault (SIGBUS), fork(), splice and GUP
behavior briefly when we run into refcount limits on a shmem THP.
Signed-off-by: David Hildenbrand (Arm) <david@kernel.org>
---
Changes in v2:
- "mm: limit pagecache folio refcount when mapping pages"
- Try not to fail fork() by skipping the PTE/PUD instead. We still have
to fail in two scenarios.
- Split helper into fast and slow path. Slow path in mm/util.c,
exported for Fuse usage in patch #2.
- Check has_capability_noaudit(current, CAP_SYS_RESOURCE) instead of
capable(CAP_SYS_RESOURCE)
- Extended patch description and improved function documentation.
- Dropped RBs due to changes.
- "mm: limit pagecache folio refcount when splicing into pipes"
- Return -EOVERFLOW from filemap_splice_read() and
shmem_file_splice_read(), and handle it in do_splice_read() by falling
back to a copy.
- Check in fuse_copy_folio() as well
- Updated patch description and updated+improved comments/doc
- Dropped RB due to changes
- "mm/mmu_gather: flush pending references early before the folio limit"
- Adjust some comments
- Update Fixes:
- Extend patch description
- "mm/gup: limit pagecache folio refcount when grabbing references"
- Keep all WARN_ON_ONCE() checks for negative/null refcounts
- Skip has_capability_noaudit(current, CAP_SYS_RESOURCE) with disabled
interrupts, skipping it for GUP-fast.
- Properly forward try_grab_folio() errors
- Adjust some comments
- Link to v1: https://patch.msgid.link/20261105-refcount_overflow_stable-v1-0-70b9c655da3e@kernel.org
To: David Hildenbrand <david@kernel.org>
To: Lorenzo Stoakes <ljs@kernel.org>
To: "Liam R. Howlett" <liam@infradead.org>
To: Vlastimil Babka <vbabka@kernel.org>
To: Mike Rapoport <rppt@kernel.org>
To: Suren Baghdasaryan <surenb@google.com>
To: Michal Hocko <mhocko@suse.com>
To: "Matthew Wilcox (Oracle)" <willy@infradead.org>
To: Jan Kara <jack@suse.cz>
To: Andrew Morton <akpm@linux-foundation.org>
To: Zi Yan <ziy@nvidia.com>
To: Baolin Wang <baolin.wang@linux.alibaba.com>
To: Nico Pache <nico.pache@linux.dev>
To: Ryan Roberts <ryan.roberts@arm.com>
To: Dev Jain <dev.jain@arm.com>
To: Barry Song <baohua@kernel.org>
To: Lance Yang <lance.yang@linux.dev>
To: Usama Arif <usama.arif@linux.dev>
To: Kiryl Shutsemau <kas@kernel.org>
To: Matthew Brost <matthew.brost@intel.com>
To: Joshua Hahn <joshua.hahnjy@gmail.com>
To: Byungchul Park <byungchul@sk.com>
To: Gregory Price <gourry@gourry.net>
To: Ying Huang <ying.huang@linux.alibaba.com>
To: Alistair Popple <apopple@nvidia.com>
To: Peter Xu <peterx@redhat.com>
To: Johannes Weiner <hannes@cmpxchg.org>
To: Song Liu <songliubraving@fb.com>
To: Rik van Riel <riel@surriel.com>
To: Miklos Szeredi <miklos@szeredi.hu>
To: Alexander Viro <viro@zeniv.linux.org.uk>
To: Christian Brauner <brauner@kernel.org>
To: Hugh Dickins <hughd@google.com>
To: Will Deacon <will@kernel.org>
To: "Aneesh Kumar K.V" <aneesh.kumar@kernel.org>
To: Nick Piggin <npiggin@gmail.com>
To: Peter Zijlstra <peterz@infradead.org>
To: Arnd Bergmann <arnd@arndb.de>
To: Jason Gunthorpe <jgg@ziepe.ca>
To: Kevin Tian <kevin.tian@intel.com>
To: "Joerg Roedel (AMD)" <joro@8bytes.org>
To: Robin Murphy <robin.murphy@arm.com>
To: Steve Sistare <steven.sistare@oracle.com>
To: John Hubbard <jhubbard@nvidia.com>
To: Jose A. Perez de Azpillaga <azpijr@gmail.com>
To: Josef Bacik <josef@toxicpanda.com>
Cc: linux-mm@kvack.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-fsdevel@vger.kernel.org
Cc: fuse-devel@lists.linux.dev
Cc: linux-arch@vger.kernel.org
Cc: iommu@lists.linux.dev
---
David Hildenbrand (Arm) (5):
mm: limit pagecache folio refcount when mapping pages
mm: limit pagecache folio refcount when splicing into pipes
mm/mmu_gather: flush pending references early before the folio limit
iommufd: fix cleanup when adding memfd folio pins fails
mm/gup: limit pagecache folio refcount when grabbing references
drivers/iommu/iommufd/pages.c | 15 +++++++++----
fs/fuse/dev.c | 5 +++--
fs/splice.c | 8 ++++++-
include/asm-generic/tlb.h | 4 ++--
include/linux/mm.h | 51 +++++++++++++++++++++++++++++++++++--------
mm/filemap.c | 17 ++++++++++++---
mm/gup.c | 24 ++++++++++++--------
mm/huge_memory.c | 29 ++++++++++++++++++++++--
mm/memory.c | 39 ++++++++++++++++++++++++++++-----
mm/migrate.c | 11 ++++++++++
mm/mmu_gather.c | 10 +++++----
mm/shmem.c | 4 ++++
mm/userfaultfd.c | 4 ++++
mm/util.c | 15 +++++++++++++
14 files changed, 194 insertions(+), 42 deletions(-)
---
base-commit: df3c65887715e66e2cba69116924020c37996cd8
change-id: 20261105-refcount_overflow_stable-542e024130fe
Best regards,
--
David Hildenbrand (Arm) <david@kernel.org>
next reply other threads:[~2026-11-07 22:24 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-07 22:23 David Hildenbrand (Arm) [this message]
2026-11-07 22:23 ` [PATCH v2 1/5] mm: limit pagecache folio refcount when mapping pages David Hildenbrand (Arm)
2026-11-07 22:23 ` [PATCH v2 2/5] mm: limit pagecache folio refcount when splicing into pipes David Hildenbrand (Arm)
2026-11-07 22:23 ` [PATCH v2 3/5] mm/mmu_gather: flush pending references early before the folio limit David Hildenbrand (Arm)
2026-11-07 22:23 ` [PATCH v2 4/5] iommufd: fix cleanup when adding memfd folio pins fails David Hildenbrand (Arm)
2026-11-07 22:23 ` [PATCH v2 5/5] mm/gup: limit pagecache folio refcount when grabbing references David Hildenbrand (Arm)
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20261107-refcount_overflow_stable-v2-0-c38f6809b106@kernel.org \
--to=david@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=aneesh.kumar@kernel.org \
--cc=apopple@nvidia.com \
--cc=arnd@arndb.de \
--cc=azpijr@gmail.com \
--cc=baohua@kernel.org \
--cc=baolin.wang@linux.alibaba.com \
--cc=brauner@kernel.org \
--cc=byungchul@sk.com \
--cc=dev.jain@arm.com \
--cc=fuse-devel@lists.linux.dev \
--cc=gourry@gourry.net \
--cc=hannes@cmpxchg.org \
--cc=hughd@google.com \
--cc=iommu@lists.linux.dev \
--cc=jack@suse.cz \
--cc=jgg@ziepe.ca \
--cc=jhubbard@nvidia.com \
--cc=joro@8bytes.org \
--cc=josef@toxicpanda.com \
--cc=joshua.hahnjy@gmail.com \
--cc=kas@kernel.org \
--cc=kevin.tian@intel.com \
--cc=lance.yang@linux.dev \
--cc=liam@infradead.org \
--cc=linux-arch@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=ljs@kernel.org \
--cc=mason@kernel.org \
--cc=matthew.brost@intel.com \
--cc=mhocko@suse.com \
--cc=miklos@szeredi.hu \
--cc=nico.pache@linux.dev \
--cc=npiggin@gmail.com \
--cc=peterx@redhat.com \
--cc=peterz@infradead.org \
--cc=riel@surriel.com \
--cc=robin.murphy@arm.com \
--cc=rppt@kernel.org \
--cc=ryan.roberts@arm.com \
--cc=songliubraving@fb.com \
--cc=stable@vger.kernel.org \
--cc=steven.sistare@oracle.com \
--cc=surenb@google.com \
--cc=usama.arif@linux.dev \
--cc=vbabka@kernel.org \
--cc=viro@zeniv.linux.org.uk \
--cc=will@kernel.org \
--cc=willy@infradead.org \
--cc=ying.huang@linux.alibaba.com \
--cc=ziy@nvidia.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®