From: "Theodore Tso" <tytso@mit.edu>
To: Deepanshu Kartikey <kartikey406@gmail.com>
Cc: Zhang Yi <yi.zhang@huaweicloud.com>,
linux-ext4@vger.kernel.org, linux-kernel@vger.kernel.org,
syzbot+b0a0670332b6b3230a0a@syzkaller.appspotmail.com,
adilger.kernel@dilger.ca, djwong@kernel.org,
Matthew Wilcox <willy@infradead.org>
Subject: Re: [PATCH v2] ext4: check folio uptodate state in ext4_page_mkwrite()
Date: Wed, 3 Dec 2025 10:46:57 -0500 [thread overview]
Message-ID: <20251203154657.GC93777@macsyma.lan> (raw)
In-Reply-To: <CADhLXY4Pk60+sSLtOOuR2QdTKbYXUAjwhgb7nH8qugf4DROT7w@mail.gmail.com>
My main concern with your patch is folio_lock() is *incredibly*
heavyweight and is going to be a real scalability concern if we need
to take it every single time we need to make a page writeable.
So could we perhaps do something like this? So the first question is
do we need to take the lock at all? I'm not sure we need to worry
about the case where the page is not uptodate because we're racing
with the page being brought into memory; if we that could happen under
normal circumstances we would be triggering the warning even without
these situations such as a delayed allocaiton write failing due to a
corrupted file system image. So can we just do this?
if (!folio_test_uptodate(folio)) {
ret = VM_FAULT_SIGBUS;
goto out;
}
If it is legitmate that ext4_page_mkwrite() could be called while the
page is still being read in (and again, I don't think it is), then we
could do something like this:
if (!folio_test_uptodate(folio)) {
folio_lock(folio);
if (!folio_test_uptodate(folio)) {
folio_unlock(folio);
ret = VM_FAULT_SIGBUS;
goto out;
}
folio_unlock(folio);
}
Matthew, as the page cache maintainer, do we actually need this extra
rigamarole. Or can we just skip taking the lock before checking to
see if the folio is uptodate in ext4_page_mkwrite()?
- Ted
next prev parent reply other threads:[~2025-12-03 15:48 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-11-22 1:57 [PATCH v2] ext4: check folio uptodate state in ext4_page_mkwrite() Deepanshu Kartikey
2025-11-30 2:06 ` Deepanshu Kartikey
2025-12-02 12:24 ` Zhang Yi
2025-12-03 1:37 ` Deepanshu Kartikey
2025-12-03 6:52 ` Zhang Yi
2025-12-03 7:43 ` Deepanshu Kartikey
2025-12-03 15:46 ` Theodore Tso [this message]
2025-12-03 17:04 ` Deepanshu Kartikey
2025-12-03 18:40 ` Theodore Tso
2025-12-03 21:35 ` Matthew Wilcox
2025-12-03 22:33 ` Theodore Tso
2025-12-04 9:54 ` Deepanshu Kartikey
2025-12-05 2:18 ` Theodore Tso
2025-12-05 3:31 ` Deepanshu Kartikey
2025-12-05 3:33 ` Matthew Wilcox
2025-12-05 13:37 ` Theodore Tso
2025-12-05 14:28 ` Deepanshu Kartikey
2026-01-05 2:08 ` Deepanshu Kartikey
2025-12-03 21:54 ` 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=20251203154657.GC93777@macsyma.lan \
--to=tytso@mit.edu \
--cc=adilger.kernel@dilger.ca \
--cc=djwong@kernel.org \
--cc=kartikey406@gmail.com \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=syzbot+b0a0670332b6b3230a0a@syzkaller.appspotmail.com \
--cc=willy@infradead.org \
--cc=yi.zhang@huaweicloud.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox