All of lore.kernel.org
 help / color / mirror / Atom feed
From: Lance Yang <lance.yang@linux.dev>
To: david@kernel.org
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, lance.yang@linux.dev, 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 18:03:20 +0800	[thread overview]
Message-ID: <20261106100320.77084-1-lance.yang@linux.dev> (raw)
In-Reply-To: <20261105-refcount_overflow_stable-v1-2-70b9c655da3e@kernel.org>


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() ...

Cheers, Lance

>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>
>---
> include/linux/mm.h | 9 ++++++---
> mm/filemap.c       | 4 ++++
> mm/shmem.c         | 4 ++++
> 3 files changed, 14 insertions(+), 3 deletions(-)
>
>diff --git a/include/linux/mm.h b/include/linux/mm.h
>index 79ae8fc0d6bb4..a82cfbce18215 100644
>--- a/include/linux/mm.h
>+++ b/include/linux/mm.h
>@@ -2287,10 +2287,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..0f2ec790a5b65 100644
>--- a/mm/filemap.c
>+++ b/mm/filemap.c
>@@ -3168,6 +3168,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 = -ENOMEM;
>+				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 cda1a0f7db99d..1c0f6bceac486 100644
>--- a/mm/shmem.c
>+++ b/mm/shmem.c
>@@ -3819,6 +3819,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 = -ENOMEM;
>+				break;
>+			}
> 			n = splice_folio_into_pipe(pipe, folio, *ppos, part);
> 			folio_put(folio);
> 			folio = NULL;
>
>-- 
>2.43.0
>
>

  parent reply	other threads:[~2026-11-06 10:03 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 [this message]
2026-11-06 21:57     ` David Hildenbrand (Arm)
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=20261106100320.77084-1-lance.yang@linux.dev \
    --to=lance.yang@linux.dev \
    --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=david@kernel.org \
    --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=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.