[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20251203154657.GC93777@macsyma.lan>
Date: Wed, 3 Dec 2025 10:46:57 -0500
From: "Theodore Tso" <tytso@....edu>
To: Deepanshu Kartikey <kartikey406@...il.com>
Cc: Zhang Yi <yi.zhang@...weicloud.com>, linux-ext4@...r.kernel.org,
linux-kernel@...r.kernel.org,
syzbot+b0a0670332b6b3230a0a@...kaller.appspotmail.com,
adilger.kernel@...ger.ca, djwong@...nel.org,
Matthew Wilcox <willy@...radead.org>
Subject: Re: [PATCH v2] ext4: check folio uptodate state in
ext4_page_mkwrite()
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
Powered by blists - more mailing lists