From: "David Hildenbrand (Arm)" <david@kernel.org>
To: "Jose A. Perez de Azpillaga" <azpijr@gmail.com>,
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>,
Josef Bacik <josef@toxicpanda.com>
Cc: 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,
stable@vger.kernel.org
Subject: Re: [PATCH v2 2/5] mm: limit pagecache folio refcount when splicing into pipes
Date: Mon, 9 Nov 2026 12:52:58 +0100 [thread overview]
Message-ID: <66590b61-6538-4200-8de9-68b2e1d2c697@kernel.org> (raw)
In-Reply-To: <ad09d3f5-986b-4337-9e32-1de4e5b18d71@gmail.com>
On 11/9/26 11:25, Jose A. Perez de Azpillaga wrote:
> On 11/9/26 11:08 AM, David Hildenbrand (Arm) wrote:
>> On 11/9/26 10:49, David Hildenbrand (Arm) wrote:
>>>
>>> Double checked, claude managed to confuse itself.
>>>
>>> n_hdlc_tty_read() can indeed return -EOVERFLOW.
>>>
>>> I should just have let splice keep failing, dealing with copy fallback starts to
>>> get annoying.
>>>
>>> I guess switching to -ETOOMANYREFS should work (and might be a better fitting error)
>>
>> Yeah, the following should do I think, please double check:
>>
>> From 7ce030711737e8c26fb5500f2705940e93da0d44 Mon Sep 17 00:00:00 2001
>> From: "David Hildenbrand (Arm)" <david@kernel.org>
>> Date: Wed, 4 Nov 2026 19:02:48 +0100
>> Subject: [PATCH] mm: limit pagecache folio refcount when splicing into pipes
>>
>> Similar to mapping pagecache folios into page tables, let's reject
>> additional references when splicing folios into a pipe if the refcount
>> is at its limit, similar to how we handle it during GUP.
>>
>> This will prevent more cases of possible folio refcount overflows with
>> large pagecache folios.
>>
>> Let's keep it simple and check in the two callers of
>> splice_folio_into_pipe(). Return -ETOOMANYREFS if the limit prevents any
>> progress, so do_splice_read() can fall back to copy_splice_read() when
>> read_iter is available. This keeps sendfile() and other splice users
>> working when ordinary reads would still succeed.
>>
>> Also fall back to copying in FUSE when taking another reference through
>> fuse_ref_folio() would exceed the limit.
>>
>> Also check in try_get_page() to cover pipe-buffer duplication by tee()
>> and partial pipe-to-pipe splicing.
>>
>> Fixes: 800d8c63b2e9 ("shmem: add huge pages support")
>> Fixes: 99cb0dbd47a1 ("mm,thp: add read-only THP support for (non-shmem) FS")
>> Fixes: 793917d997df ("mm/readahead: Add large folio readahead")
>> Cc: stable@vger.kernel.org
>> Signed-off-by: David Hildenbrand (Arm) <david@kernel.org>
>> ---
>> fs/fuse/dev.c | 5 +++--
>> fs/splice.c | 8 +++++++-
>> include/linux/mm.h | 9 ++++++---
>> mm/filemap.c | 11 ++++++++---
>> mm/shmem.c | 4 ++++
>> 5 files changed, 28 insertions(+), 9 deletions(-)
>>
>> diff --git a/fs/fuse/dev.c b/fs/fuse/dev.c
>> index 3641abb90d6bb..4f6b7b42bfd3e 100644
>> --- a/fs/fuse/dev.c
>> +++ b/fs/fuse/dev.c
>> @@ -1265,9 +1265,10 @@ int fuse_copy_folio(struct fuse_copy_state *cs, struct folio **foliop,
>> if (cs->write && cs->pipebufs && folio) {
>> /*
>> * Can't control lifetime of pipe buffers, so always
>> - * copy user pages.
>> + * copy user pages. Also copy folios at their refcount limit.
>> */
>> - if (cs->req->args->user_pages) {
>> + if (cs->req->args->user_pages ||
>> + unlikely(folio_ref_count_over_limit(folio))) {
>> err = fuse_copy_fill(cs);
>> if (err)
>> return err;
>> diff --git a/fs/splice.c b/fs/splice.c
>> index e6d43329ed3f0..2fc1279628af5 100644
>> --- a/fs/splice.c
>> +++ b/fs/splice.c
>> @@ -956,6 +956,7 @@ static ssize_t do_splice_read(struct file *in, loff_t *ppos,
>> unsigned int flags)
>> {
>> unsigned int p_space;
>> + ssize_t ret;
>>
>> if (unlikely(!(in->f_mode & FMODE_READ)))
>> return -EBADF;
>> @@ -977,7 +978,12 @@ static ssize_t do_splice_read(struct file *in, loff_t *ppos,
>> */
>> if ((in->f_flags & O_DIRECT) || IS_DAX(in->f_mapping->host))
>> return copy_splice_read(in, ppos, pipe, len, flags);
>> - return in->f_op->splice_read(in, ppos, pipe, len, flags);
>> + ret = in->f_op->splice_read(in, ppos, pipe, len, flags);
>> +
>> + /* Fallback to copying when hitting folio refcount limits. */
>> + if (unlikely(ret == -ETOOMANYREFS) && in->f_op->read_iter)
>> + ret = copy_splice_read(in, ppos, pipe, len, flags);
>> + return ret;
>> }
>>
>> /**
>> diff --git a/include/linux/mm.h b/include/linux/mm.h
>> index 3356f7a670d1e..dd50262a70758 100644
>> --- a/include/linux/mm.h
>> +++ b/include/linux/mm.h
>> @@ -2288,10 +2288,13 @@ static inline void get_page(struct page *page)
>>
>> static inline __must_check bool try_get_page(struct page *page)
>> {
>> - page = compound_head(page);
>> - if (WARN_ON_ONCE(page_ref_count(page) <= 0))
>> + struct folio *folio = page_folio(page);
>> +
>> + if (WARN_ON_ONCE(folio_ref_count(folio) <= 0))
>> return false;
>> - page_ref_inc(page);
>> + if (unlikely(folio_ref_count_over_limit(folio)))
>> + return false;
>> + folio_ref_inc(folio);
>> return true;
>> }
>>
>> diff --git a/mm/filemap.c b/mm/filemap.c
>> index 920bbf86dfdff..44b23c51ea45f 100644
>> --- a/mm/filemap.c
>> +++ b/mm/filemap.c
>> @@ -3094,9 +3094,10 @@ size_t splice_folio_into_pipe(struct pipe_inode_info *pipe,
>> * Return: On success, the number of bytes read will be returned and *@ppos
>> * will be updated if appropriate; 0 will be returned if there is no more data
>> * to be read; -EAGAIN will be returned if the pipe had no space, and some
>> - * other negative error code will be returned on error. A short read may occur
>> - * if the pipe has insufficient space, we reach the end of the data or we hit a
>> - * hole.
>> + * other negative error code will be returned on error; -ETOOMANYREFS will be
>> + * returned if the folio's refcount is too high and the caller can fall back to
>> + * copying. A short read may occur if the pipe has insufficient space, we reach
>> + * the end of the data or we hit a hole.
>> */
>> ssize_t filemap_splice_read(struct file *in, loff_t *ppos,
>> struct pipe_inode_info *pipe,
>> @@ -3168,6 +3169,10 @@ ssize_t filemap_splice_read(struct file *in, loff_t *ppos,
>> if (writably_mapped)
>> flush_dcache_folio(folio);
>>
>> + if (unlikely(folio_ref_count_over_limit(folio))) {
>> + error = -ETOOMANYREFS;
>> + goto out;
>> + }
>> n = min_t(loff_t, len, isize - *ppos);
>> n = splice_folio_into_pipe(pipe, folio, *ppos, n);
>> if (!n)
>> diff --git a/mm/shmem.c b/mm/shmem.c
>> index be4ab228cf67c..0b30b1de81a7c 100644
>> --- a/mm/shmem.c
>> +++ b/mm/shmem.c
>> @@ -3830,6 +3830,10 @@ static ssize_t shmem_file_splice_read(struct file *in, loff_t *ppos,
>> * Ok, we have the page, and it's up-to-date, so we can
>> * now splice it into the pipe.
>> */
>> + if (unlikely(folio_ref_count_over_limit(folio))) {
>> + error = -ETOOMANYREFS;
>> + break;
>> + }
>> n = splice_folio_into_pipe(pipe, folio, *ppos, part);
>> folio_put(folio);
>> folio = NULL;
>
> this LGTM :)
Thanks!
--
Cheers,
David
next prev parent reply other threads:[~2026-11-09 11:53 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-07 22:23 [PATCH v2 0/5] mm: limit pagecache folio refcount David Hildenbrand (Arm)
2026-11-07 22:23 ` [PATCH v2 1/5] mm: limit pagecache folio refcount when mapping pages David Hildenbrand (Arm)
2026-11-09 8:35 ` Jose A. Perez de Azpillaga
2026-11-07 22:23 ` [PATCH v2 2/5] mm: limit pagecache folio refcount when splicing into pipes David Hildenbrand (Arm)
2026-11-09 8:57 ` Jose A. Perez de Azpillaga
2026-11-09 9:30 ` David Hildenbrand (Arm)
2026-11-09 9:49 ` David Hildenbrand (Arm)
2026-11-09 10:07 ` Jose A. Perez de Azpillaga
2026-11-09 10:08 ` David Hildenbrand (Arm)
2026-11-09 10:25 ` Jose A. Perez de Azpillaga
2026-11-09 11:52 ` David Hildenbrand (Arm) [this message]
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)
2026-11-09 9:05 ` Jose A. Perez de Azpillaga
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=66590b61-6538-4200-8de9-68b2e1d2c697@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=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®