All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Kiryl Shutsemau (Meta)" <kas@kernel.org>,
	"Andrew Morton" <akpm@linux-foundation.org>,
	"Linus Torvalds" <torvalds@linux-foundation.org>,
	"David Hildenbrand" <david@kernel.org>,
	"Matthew Wilcox" <willy@infradead.org>,
	"Vlastimil Babka" <vbabka@kernel.org>,
	"Lorenzo Stoakes" <ljs@kernel.org>, "Jan Kara" <jack@suse.cz>,
	"Hugh Dickins" <hughd@google.com>,
	"Christian Brauner" <brauner@kernel.org>,
	"Alexander Viro" <viro@zeniv.linux.org.uk>
Cc: "Miklos Szeredi" <miklos@szeredi.hu>,
	"Miaohe Lin" <linmiaohe@huawei.com>,
	"Naoya Horiguchi" <nao.horiguchi@gmail.com>,
	"Oscar Salvador" <osalvador@suse.de>,
	"Liam R . Howlett" <liam@infradead.org>,
	"Mike Rapoport" <rppt@kernel.org>,
	"Suren Baghdasaryan" <surenb@google.com>,
	"Michal Hocko" <mhocko@suse.com>,
	"Brendan Jackman" <brendan.jackman@linux.dev>,
	"Johannes Weiner" <hannes@cmpxchg.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>,
	"Kairui Song" <kasong@tencent.com>,
	"Qi Zheng" <qi.zheng@linux.dev>,
	"Shakeel Butt" <shakeel.butt@linux.dev>,
	"Axel Rasmussen" <axelrasmussen@google.com>,
	"Yuanchu Xie" <yuanchu@google.com>, "Wei Xu" <weixugc@google.com>,
	"Baoquan He" <baoquan.he@linux.dev>,
	"Paul E . McKenney" <paulmck@kernel.org>,
	"Pedro Falcato" <pfalcato@suse.de>,
	"Harry Yoo" <harry@kernel.org>,
	"Luis Chamberlain" <mcgrof@kernel.org>,
	"Ilya Gladyshev" <ilya.gladyshev@linux.dev>,
	"Jaegeuk Kim" <jaegeuk@kernel.org>,
	linux-mm@kvack.org, kernel-team@meta.com
Subject: Re: [RFC PATCH 12/18] mm/filemap: don't defer the free of folios of an inode being evicted
Date: Tue, 20 Oct 2026 15:53:11 +0000	[thread overview]
Message-ID: <sashiko-outbox-179310@kernel.org> (raw)
In-Reply-To: <20261019154913.1765974-13-kas@kernel.org>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Critical] mm/filemap: premature PG_rcu_free clear on live inodes with AS_EXITING
--

commit 47ca48a16967ca2b270af7537211abb87d17221b
Author: Kiryl Shutsemau (Meta) <kas@kernel.org>

mm/filemap: don't defer the free of folios of an inode being evicted

This commit clears PG_rcu_free on folios in page_cache_delete() and
page_cache_delete_batch() when mapping_exiting() is set, avoiding
RCU-deferred freeing during inode eviction.

> diff --git a/mm/filemap.c b/mm/filemap.c
> index b732ecaa78a90..53ec922799771 100644
> --- a/mm/filemap.c
> +++ b/mm/filemap.c
> @@ -138,6 +138,9 @@ static void page_cache_delete(struct address_space *mapping,
>  	nr = folio_nr_pages(folio);
>  
>  	VM_BUG_ON_FOLIO(!folio_test_locked(folio), folio);
> +	/* No lockless reader can be in an evicted inode */
> +	if (folio_test_rcu_free(folio) && mapping_exiting(mapping))
> +		folio_clear_rcu_free(folio);
>  
>  	xas_store(&xas, shadow);
>  	xas_init_marks(&xas);
> @@ -306,6 +309,9 @@ static void page_cache_delete_batch(struct address_space *mapping,
>  		}
>  
>  		WARN_ON_ONCE(!folio_test_locked(folio));
> +		/* No lockless reader can be in an evicted inode */
> +		if (folio_test_rcu_free(folio) && mapping_exiting(mapping))
> +			folio_clear_rcu_free(folio);

[Severity: Critical]
Can clearing PG_rcu_free when mapping_exiting(mapping) is set cause a
use-after-free if truncate_inode_pages_final() is called on a live, open
file?

In mm/truncate.c, truncate_inode_pages_final() unconditionally sets
AS_EXITING via mapping_set_exiting():

mm/truncate.c:truncate_inode_pages_final() {
	mapping_set_exiting(mapping);

	if (!mapping_empty(mapping)) {
		xa_lock_irq(&mapping->i_pages);
		xa_unlock_irq(&mapping->i_pages);
	}

	truncate_inode_pages(mapping, 0);
	...
}

However, f2fs calls truncate_inode_pages_final() on live, open regular
files during atomic write operations, such as when starting an atomic
replace via ioctl(F2FS_IOC_START_ATOMIC_REPLACE):

fs/f2fs/file.c:f2fs_ioc_start_atomic_write() {
	...
	if (truncate) {
		set_inode_flag(inode, FI_ATOMIC_REPLACE);
		truncate_inode_pages_final(inode->i_mapping);
		f2fs_i_size_write(inode, 0);
		isize = 0;
	}
	...
}

and when aborting an atomic write:

fs/f2fs/segment.c:f2fs_abort_atomic_write() {
	...
	if (clean)
		truncate_inode_pages_final(inode->i_mapping);
	...
}

Buffered reads in f2fs call f2fs_file_read_iter() -> filemap_read()
without holding inode_lock() or fi->i_gc_rwsem, which marks folios with
PG_rcu_free via filemap_mark_hot() and copies from them locklessly under
rcu_read_lock().

Furthermore, because AS_EXITING is never cleared once set,
mapping_exiting(inode->i_mapping) remains true for the rest of the live
inode's lifetime in cache. During both the atomic-write
truncate_inode_pages_final() calls and any subsequent truncate(), hole
punch, fadvise(POSIX_FADV_DONTNEED) invalidation, or page reclaim on that
open file, page_cache_delete() and page_cache_delete_batch() will clear
PG_rcu_free on hot folios.

When the last reference to those folios is dropped, wouldn't
__free_pages_prepare() skip rcu_free_defer() and return the pages
immediately to the buddy allocator while concurrent lockless readers in
filemap_read() are still copying from them under rcu_read_lock()?

>  
>  		folio->mapping = NULL;
>  		/* Leave folio->index set: truncation lookup relies on it */

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261019154913.1765974-1-kas@kernel.org?part=12


  reply	other threads:[~2026-10-20 15:53 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-19 15:48 [RFC PATCH 00/18] mm: read the page cache without folio references Kiryl Shutsemau (Meta)
2026-10-19 15:48 ` [RFC PATCH 01/18] mm: free PG_rcu_free folios only after an RCU grace period Kiryl Shutsemau (Meta)
2026-10-19 15:48 ` [RFC PATCH 02/18] splice: don't steal page cache folios Kiryl Shutsemau (Meta)
2026-10-19 15:48 ` [RFC PATCH 03/18] fuse: don't move a folio with PG_rcu_free into a fuse file Kiryl Shutsemau (Meta)
2026-10-19 15:48 ` [RFC PATCH 04/18] mm: count the pages waiting for a grace period Kiryl Shutsemau (Meta)
2026-10-19 15:48 ` [RFC PATCH 05/18] mm: expedite the grace period when a CPU has many deferred frees Kiryl Shutsemau (Meta)
2026-10-19 15:48 ` [RFC PATCH 06/18] mm: free the pages waiting for a grace period before OOM Kiryl Shutsemau (Meta)
2026-10-20 15:51   ` sashiko-bot
2026-10-19 15:49 ` [RFC PATCH 07/18] mm: free the pages waiting for a grace period before isolation fails Kiryl Shutsemau (Meta)
2026-10-20 15:52   ` sashiko-bot
2026-10-19 15:49 ` [RFC PATCH 08/18] mm/memory-failure: handle folios with PG_rcu_free Kiryl Shutsemau (Meta)
2026-10-20 15:52   ` sashiko-bot
2026-10-19 15:49 ` [RFC PATCH 09/18] mm: have folio_mark_accessed() return whether the folio is hot Kiryl Shutsemau (Meta)
2026-10-19 15:49 ` [RFC PATCH 10/18] mm/filemap: mark a folio accessed in one place in filemap_read() Kiryl Shutsemau (Meta)
2026-10-19 15:49 ` [RFC PATCH 11/18] mm/filemap: set PG_rcu_free on the folios that reads keep coming back to Kiryl Shutsemau (Meta)
2026-10-19 15:49 ` [RFC PATCH 12/18] mm/filemap: don't defer the free of folios of an inode being evicted Kiryl Shutsemau (Meta)
2026-10-20 15:53   ` sashiko-bot [this message]
2026-10-19 15:49 ` [RFC PATCH 13/18] mm/filemap: store the end of a read in f_ra only when it changes Kiryl Shutsemau (Meta)
2026-10-20 21:20   ` Linus Torvalds
2026-10-19 15:49 ` [RFC PATCH 14/18] mm/filemap: read from the page cache without folio references Kiryl Shutsemau (Meta)
2026-10-20 15:53   ` sashiko-bot
2026-10-19 15:49 ` [RFC PATCH 15/18] mm/filemap: read large folios " Kiryl Shutsemau (Meta)
2026-10-20 15:54   ` sashiko-bot
2026-10-19 15:49 ` [RFC PATCH 16/18] mm/shmem: count accesses to a folio the way filemap_read() does Kiryl Shutsemau (Meta)
2026-10-19 15:49 ` [RFC PATCH 17/18] mm/shmem: read without folio references Kiryl Shutsemau (Meta)
2026-10-19 15:49 ` [RFC PATCH 18/18] mm/filemap: add a debugfs switch for lockless page cache reads Kiryl Shutsemau (Meta)
2026-10-19 21:20 ` [RFC PATCH 00/18] mm: read the page cache without folio references Harry Yoo
2026-10-20 17:27   ` Kiryl Shutsemau

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=sashiko-outbox-179310@kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=axelrasmussen@google.com \
    --cc=baohua@kernel.org \
    --cc=baolin.wang@linux.alibaba.com \
    --cc=baoquan.he@linux.dev \
    --cc=brauner@kernel.org \
    --cc=brendan.jackman@linux.dev \
    --cc=david@kernel.org \
    --cc=dev.jain@arm.com \
    --cc=hannes@cmpxchg.org \
    --cc=harry@kernel.org \
    --cc=hughd@google.com \
    --cc=ilya.gladyshev@linux.dev \
    --cc=jack@suse.cz \
    --cc=jaegeuk@kernel.org \
    --cc=kas@kernel.org \
    --cc=kasong@tencent.com \
    --cc=kernel-team@meta.com \
    --cc=lance.yang@linux.dev \
    --cc=liam@infradead.org \
    --cc=linmiaohe@huawei.com \
    --cc=linux-mm@kvack.org \
    --cc=ljs@kernel.org \
    --cc=mcgrof@kernel.org \
    --cc=mhocko@suse.com \
    --cc=miklos@szeredi.hu \
    --cc=nao.horiguchi@gmail.com \
    --cc=nico.pache@linux.dev \
    --cc=osalvador@suse.de \
    --cc=paulmck@kernel.org \
    --cc=pfalcato@suse.de \
    --cc=qi.zheng@linux.dev \
    --cc=rppt@kernel.org \
    --cc=ryan.roberts@arm.com \
    --cc=sashiko-reviews@lists.linux.dev \
    --cc=shakeel.butt@linux.dev \
    --cc=surenb@google.com \
    --cc=torvalds@linux-foundation.org \
    --cc=usama.arif@linux.dev \
    --cc=vbabka@kernel.org \
    --cc=viro@zeniv.linux.org.uk \
    --cc=weixugc@google.com \
    --cc=willy@infradead.org \
    --cc=yuanchu@google.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.