All of lore.kernel.org
 help / color / mirror / Atom feed
From: Pedro Falcato <pfalcato@suse.de>
To: Gregg Leventhal <gleventhal@janestreet.com>
Cc: Alexander Viro <viro@zeniv.linux.org.uk>,
	 Christian Brauner <brauner@kernel.org>, Jan Kara <jack@suse.cz>,
	Matthew Wilcox <willy@infradead.org>,
	 Andrew Morton <akpm@linux-foundation.org>,
	Song Liu <song@kernel.org>,
	linux-fsdevel@vger.kernel.org,  linux-mm@kvack.org,
	linux-kernel@vger.kernel.org,
	 Eric Hagberg <ehagberg@janestreet.com>,
	David Hildenbrand <david@kernel.org>,
	 Lorenzo Stoakes <ljs@kernel.org>, Zi Yan <ziy@nvidia.com>
Subject: Re: Subject: [BUG/RFC] write-open file THP cache purge can discard dirty page cache
Date: Tue, 30 Jun 2026 20:55:12 +0100	[thread overview]
Message-ID: <akQekZUyoKadiGCH@pedro-suse.lan> (raw)
In-Reply-To: <akQO8JtTxmp89GS8@pedro-suse.lan>

[-- Attachment #1: Type: text/plain, Size: 586 bytes --]

On Tue, Jun 30, 2026 at 07:49:12PM +0100, Pedro Falcato wrote:
snip
> 
> Other idea: perhaps doing filemap_write_and_wait() after the nr_thps
> increment in collapse_file() will Just Work and result in a _much_
> simpler fix. And it avoids any weird forward-progress issues as no one can
> write to folios at that point.
> 

Gregg, if you could test this patch, it would be much appreciated. This patch
(hopefully) makes it so no dirty folio will ever coexist with a ro-THP, thus
hopefully sidestepping the entire issue in a simple way. Only compile-tested
and not reviewed.

-- 
Pedro

[-- Attachment #2: 0001-mm-khugepaged-write-all-dirty-folios-when-collapsing.patch --]
[-- Type: text/x-patch, Size: 2171 bytes --]

From 43d90a937f0b24656a8d0405035c3efcfdf0961e Mon Sep 17 00:00:00 2001
From: Pedro Falcato <pfalcato@suse.de>
Date: Tue, 30 Jun 2026 20:48:41 +0100
Subject: [PATCH] mm/khugepaged: write all dirty folios when collapsing

Signed-off-by: Pedro Falcato <pfalcato@suse.de>
---
 mm/khugepaged.c | 19 ++++++++++++++++---
 1 file changed, 16 insertions(+), 3 deletions(-)

diff --git a/mm/khugepaged.c b/mm/khugepaged.c
index a97b20617869..3f0f90ab16ba 100644
--- a/mm/khugepaged.c
+++ b/mm/khugepaged.c
@@ -60,6 +60,7 @@ enum scan_result {
 	SCAN_STORE_FAILED,
 	SCAN_COPY_MC,
 	SCAN_PAGE_FILLED,
+	SCAN_WRITEBACK_FAIL,
 };
 
 #define CREATE_TRACE_POINTS
@@ -1812,7 +1813,7 @@ static int collapse_file(struct mm_struct *mm, unsigned long addr,
 	pgoff_t index = 0, end = start + HPAGE_PMD_NR;
 	LIST_HEAD(pagelist);
 	XA_STATE_ORDER(xas, &mapping->i_pages, start, HPAGE_PMD_ORDER);
-	int nr_none = 0, result = SCAN_SUCCEED;
+	int nr_none = 0, result = SCAN_SUCCEED, err;
 	bool is_shmem = shmem_file(file);
 
 	VM_BUG_ON(!IS_ENABLED(CONFIG_READ_ONLY_THP_FOR_FS) && !is_shmem);
@@ -2043,6 +2044,17 @@ static int collapse_file(struct mm_struct *mm, unsigned long addr,
 	 */
 	try_to_unmap_flush();
 
+	/*
+	 * If collapse looks to be successful, flush any dirty pages
+	 * out the page cache. With the nr_thps incremented, there won't be
+	 * any new writers (nor new dirties).
+	 */
+	if (result == SCAN_SUCCEED && !is_shmem) {
+		err = filemap_write_and_wait(mapping);
+		if (err)
+			result = SCAN_WRITEBACK_FAIL;
+	}
+
 	if (result == SCAN_SUCCEED && nr_none &&
 	    !shmem_charge(mapping->host, nr_none))
 		result = SCAN_FAIL;
@@ -2210,9 +2222,10 @@ static int collapse_file(struct mm_struct *mm, unsigned long addr,
 	/*
 	 * Undo the updates of filemap_nr_thps_inc for non-SHMEM
 	 * file only. This undo is not needed unless failure is
-	 * due to SCAN_COPY_MC.
+	 * due to SCAN_COPY_MC or SCAN_WRITEBACK_FAIL.
 	 */
-	if (!is_shmem && result == SCAN_COPY_MC) {
+	if (!is_shmem && (result == SCAN_COPY_MC ||
+	    result == SCAN_WRITEBACK_FAIL)) {
 		filemap_nr_thps_dec(mapping);
 		/*
 		 * Paired with the fence in do_dentry_open() -> get_write_access()
-- 
2.55.0


  reply	other threads:[~2026-06-30 19:55 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-30 17:01 Subject: [BUG/RFC] write-open file THP cache purge can discard dirty page cache Gregg Leventhal
2026-06-30 17:18 ` Gregg Leventhal
2026-06-30 18:31 ` Pedro Falcato
2026-06-30 18:49   ` Pedro Falcato
2026-06-30 19:55     ` Pedro Falcato [this message]
2026-06-30 22:34       ` Matthew Wilcox
2026-06-30 22:48       ` Zi Yan
2026-07-01 12:05         ` Pedro Falcato
2026-07-01 11:54       ` Matthew Wilcox
2026-07-01 12:04         ` Pedro Falcato
2026-07-01 12:48         ` Pedro Falcato
2026-07-01 13:07           ` Gregg Leventhal
2026-07-01 14:23             ` Pedro Falcato
2026-06-30 18:36 ` Matthew Wilcox
2026-06-30 19:05   ` Zi Yan
2026-06-30 19:07     ` Matthew Wilcox

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=akQekZUyoKadiGCH@pedro-suse.lan \
    --to=pfalcato@suse.de \
    --cc=akpm@linux-foundation.org \
    --cc=brauner@kernel.org \
    --cc=david@kernel.org \
    --cc=ehagberg@janestreet.com \
    --cc=gleventhal@janestreet.com \
    --cc=jack@suse.cz \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=ljs@kernel.org \
    --cc=song@kernel.org \
    --cc=viro@zeniv.linux.org.uk \
    --cc=willy@infradead.org \
    --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.