From: "David Hildenbrand (Arm)" <david@kernel.org>
To: Lance Yang <lance.yang@linux.dev>
Cc: akpm@linux-foundation.org, ljs@kernel.org, liam@infradead.org,
vbabka@kernel.org, rppt@kernel.org, surenb@google.com,
mhocko@suse.com, willy@infradead.org, jack@suse.cz,
ziy@nvidia.com, baolin.wang@linux.alibaba.com,
nico.pache@linux.dev, ryan.roberts@arm.com, dev.jain@arm.com,
baohua@kernel.org, usama.arif@linux.dev, kas@kernel.org,
matthew.brost@intel.com, joshua.hahnjy@gmail.com,
byungchul@sk.com, gourry@gourry.net,
ying.huang@linux.alibaba.com, apopple@nvidia.com,
peterx@redhat.com, hannes@cmpxchg.org, songliubraving@fb.com,
riel@surriel.com, hughd@google.com, will@kernel.org,
aneesh.kumar@kernel.org, npiggin@gmail.com, peterz@infradead.org,
jgg@ziepe.ca, kevin.tian@intel.com, joro@8bytes.org,
robin.murphy@arm.com, steven.sistare@oracle.com,
jhubbard@nvidia.com, linux-mm@kvack.org,
linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org,
linux-arch@vger.kernel.org, iommu@lists.linux.dev,
stable@vger.kernel.org
Subject: Re: [PATCH 2/5] mm: limit pagecache folio refcount when splicing into pipes
Date: Fri, 6 Nov 2026 22:57:19 +0100 [thread overview]
Message-ID: <6b8d6030-efe7-47d2-8aa2-3f8fd77ce95c@kernel.org> (raw)
In-Reply-To: <20261106100320.77084-1-lance.yang@linux.dev>
On 11/6/26 11:03, Lance Yang wrote:
>
> On Thu, Nov 05, 2026 at 02:10:11PM +0100, David Hildenbrand (Arm) wrote:
>> Similar to mapping pagecache folios into page tables, let's reject splicing
>> folios into a pipe if the refcount is at it's 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().
>>
>> Also check in try_get_page() to cover pipe-buffer duplication by tee()
>> and partial pipe-to-pipe splicing.
>
> What about fuse_ref_folio()? Buffered FUSE_WRITE requests can carry
> pagecache folios into a pipe through /dev/fuse without going through
> splice_folio_into_pipe() or try_get_page() ...
Of course it has its own handling ... :)
Thanks! I was hoping the number of folio references would be bounded ... I guess
one reference per pipe buffer is not the end of the world, but, let's just add
it, and fallback to copying.
--
Cheers,
David
next prev parent reply other threads:[~2026-11-06 22:42 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-05 13:10 [PATCH 0/5] mm: limit pagecache folio refcount David Hildenbrand (Arm)
2026-11-05 13:10 ` [PATCH 1/5] mm: limit pagecache folio refcount when mapping pages David Hildenbrand (Arm)
2026-11-06 9:11 ` Lance Yang
2026-11-06 9:42 ` Jose A. Perez de Azpillaga
2026-11-06 10:05 ` David Hildenbrand (Arm)
2026-11-06 10:06 ` Lance Yang
2026-11-06 21:23 ` David Hildenbrand (Arm)
2026-11-06 12:38 ` Kiryl Shutsemau
2026-11-06 20:54 ` David Hildenbrand (Arm)
2026-11-06 23:25 ` David Hildenbrand (Arm)
2026-11-06 13:11 ` sashiko-bot
2026-11-05 13:10 ` [PATCH 2/5] mm: limit pagecache folio refcount when splicing into pipes David Hildenbrand (Arm)
2026-11-06 9:50 ` Jose A. Perez de Azpillaga
2026-11-06 10:03 ` Lance Yang
2026-11-06 21:57 ` David Hildenbrand (Arm) [this message]
2026-11-06 17:58 ` Josef Bacik
2026-11-06 20:09 ` David Hildenbrand (Arm)
2026-11-06 20:43 ` Jason Gunthorpe
2026-11-06 20:45 ` David Hildenbrand (Arm)
2026-11-05 13:10 ` [PATCH 3/5] mm/mmu_gather: flush pending references early before the folio limit David Hildenbrand (Arm)
2026-11-06 9:56 ` Jose A. Perez de Azpillaga
2026-11-06 15:15 ` Lance Yang
2026-11-05 13:10 ` [PATCH 4/5] iommufd: fix cleanup when adding memfd folio pins fails David Hildenbrand (Arm)
2026-11-06 15:39 ` Lance Yang
2026-11-06 20:46 ` Jason Gunthorpe
2026-11-05 13:10 ` [PATCH 5/5] mm/gup: limit pagecache folio refcount when grabbing references David Hildenbrand (Arm)
2026-11-06 10:13 ` Jose A. Perez de Azpillaga
2026-11-06 22:42 ` David Hildenbrand (Arm)
2026-11-06 13:11 ` sashiko-bot
2026-11-06 22:50 ` David Hildenbrand (Arm)
2026-11-05 17:51 ` [PATCH 0/5] mm: limit pagecache folio refcount David Hildenbrand (Arm)
2026-11-06 19:49 ` Josef Bacik
2026-11-06 20:31 ` 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=6b8d6030-efe7-47d2-8aa2-3f8fd77ce95c@kernel.org \
--to=david@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=aneesh.kumar@kernel.org \
--cc=apopple@nvidia.com \
--cc=baohua@kernel.org \
--cc=baolin.wang@linux.alibaba.com \
--cc=byungchul@sk.com \
--cc=dev.jain@arm.com \
--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=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=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=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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.