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>,
	"David Hildenbrand (Arm)" <david@kernel.org>,
	"Pedro Falcato" <pfalcato@suse.de>
Cc: "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>,
	"Hugh Dickins" <hughd@google.com>,
	"Chris Mason" <mason@kernel.org>,
	linux-mm@kvack.org, kernel-team@meta.com
Subject: Re: [PATCH v2 1/2] mm/memory: recheck PG_uptodate after ->page_mkwrite()
Date: Tue, 10 Nov 2026 12:04:35 +0000	[thread overview]
Message-ID: <sashiko-outbox-206973@kernel.org> (raw)
In-Reply-To: <20261109120403.82361-2-kas@kernel.org>

Thank you for your contribution! Sashiko AI review found 1 potential
issue to consider:
- [High] mm/memory: PG_uptodate check in do_shared_fault() runs after
  ->page_mkwrite()
--

commit 700a620ccdd59b966f387e178bdcded1ac07e9a0
Author: Kiryl Shutsemau (Meta) <kas@kernel.org>

mm/memory: recheck PG_uptodate after ->page_mkwrite()

This commit rechecks whether a file folio is still uptodate in
do_shared_fault() after ->page_mkwrite() returns with the folio locked,
retrying the fault if PG_uptodate was cleared while the folio was unlocked.

> diff --git a/mm/memory.c b/mm/memory.c
> index fe72e66c9c2ee..cc1d0b7d15c75 100644
> --- a/mm/memory.c
> +++ b/mm/memory.c

[ ... ]

> @@ -6163,6 +6175,16 @@ static vm_fault_t do_shared_fault(struct vm_fault *vmf)
>  			folio_put(folio);
>  			return tmp;
>  		}
> +
> +		/*
> +		 * The folio was unlocked for ->page_mkwrite(). If it lost
> +		 * PG_uptodate meanwhile, retry the fault to read it in again.
> +		 */
> +		if (unlikely(file_folio_not_uptodate(folio))) {
> +			folio_unlock(folio);
> +			folio_put(folio);
> +			return VM_FAULT_NOPAGE;
> +		}
>  	}
>  
>  	ret |= finish_fault(vmf);

[Severity: High]
Does checking file_folio_not_uptodate(folio) after do_page_mkwrite() run too
late once ->page_mkwrite() has already dirtied the folio or set PG_uptodate
back on it?

In the race with ecryptfs_writepages(), writeback clears PG_dirty via
folio_clear_dirty_for_io() and then clears PG_uptodate when encryption fails.
When filemap_page_mkwrite() runs next, it relocks the folio, checks only
folio->mapping != mapping, and calls folio_mark_dirty():

mm/filemap.c:filemap_page_mkwrite() {
	...
	folio_lock(folio);
	if (folio->mapping != mapping) {
		folio_unlock(folio);
		ret = VM_FAULT_NOPAGE;
		goto out;
	}
	/*
	 * We mark the folio dirty already here so that when freeze is in
	 * progress, we are guaranteed that writeback during freezing will
	 * see the dirty folio and writeprotect it again.
	 */
	folio_mark_dirty(folio);
	...
}

Before returning to do_shared_fault(), folio_mark_dirty() ->
__folio_mark_dirty() triggers WARN_ON_ONCE(warn && !folio_test_uptodate(folio))
and tags the non-uptodate folio PAGECACHE_TAG_DIRTY.  When do_shared_fault()
then aborts with VM_FAULT_NOPAGE, the non-uptodate folio is left unlocked and
dirty in the page cache, where writeback can pick it up again or reclaim
cannot evict it.

On filesystems whose ->page_mkwrite() goes through block_page_mkwrite() or
btrfs_page_mkwrite(), block_commit_write() and btrfs_folio_set_uptodate() set
PG_uptodate back on a full folio without reading from disk, so
file_folio_not_uptodate(folio) returns false and the invalidated folio is
still mapped into userspace.

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


  parent reply	other threads:[~2026-11-10 12:04 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-11-09 12:04 [PATCH v2 0/2] mm/memory: refuse to map page cache folios that are not uptodate Kiryl Shutsemau (Meta)
2026-11-09 12:04 ` [PATCH v2 1/2] mm/memory: recheck PG_uptodate after ->page_mkwrite() Kiryl Shutsemau (Meta)
2026-11-09 14:11   ` Pedro Falcato
2026-11-09 14:40     ` Kiryl Shutsemau
2026-11-09 16:11   ` Lorenzo Stoakes (ARM)
2026-11-09 17:17     ` Kiryl Shutsemau
2026-11-09 17:30       ` Lorenzo Stoakes (ARM)
2026-11-09 20:30   ` Matthew Wilcox
2026-11-10 10:38     ` Kiryl Shutsemau
2026-11-10 19:25       ` Matthew Wilcox
2026-11-10 12:04   ` sashiko-bot [this message]
2026-11-09 12:04 ` [PATCH v2 2/2] mm/memory: refuse to map page cache folios that are not uptodate Kiryl Shutsemau (Meta)
2026-11-09 14:13   ` Pedro Falcato
2026-11-10 12:04   ` sashiko-bot
2026-11-11  8:05   ` David Hildenbrand (Arm)
2026-11-11 18:13     ` 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-206973@kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=david@kernel.org \
    --cc=hughd@google.com \
    --cc=kas@kernel.org \
    --cc=kernel-team@meta.com \
    --cc=liam@infradead.org \
    --cc=linux-mm@kvack.org \
    --cc=ljs@kernel.org \
    --cc=mason@kernel.org \
    --cc=mhocko@suse.com \
    --cc=pfalcato@suse.de \
    --cc=rppt@kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    --cc=surenb@google.com \
    --cc=vbabka@kernel.org \
    --cc=willy@infradead.org \
    /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.