From: "Luis Henriques (SUSE)" <luis.henriques@linux.dev>
To: Theodore Ts'o <tytso@mit.edu>, Andreas Dilger <adilger.kernel@dilger.ca>
Cc: linux-ext4@vger.kernel.org, linux-kernel@vger.kernel.org,
"Luis Henriques (SUSE)" <luis.henriques@linux.dev>
Subject: [RFC PATCH] ext4: don't wipe data when reading inode with inlined data
Date: Fri, 11 Oct 2024 11:24:45 +0100 [thread overview]
Message-ID: <20241011102445.13305-1-luis.henriques@linux.dev> (raw)
When a filesystem has inlined data feature enabled, the ->read_folio()
callback will need to check if the read is being done within the range where
the inline data actually is. Since the inline data can only occur on the
first page, this verification is done by checking if the folio index is
zero.
However, if the index isn't zero, this callback is also zero'ing the folio,
effectively wiping the data that was there. This is a bug reported in the
link bellow, and the reproducer described there can easily trigger it in a
filesystem created with inline_data and a small block size (e.g. 1024).
This patch fixes this issue by falling back to a regular readpages when the
folio index isn't zero.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=200681
Signed-off-by: Luis Henriques (SUSE) <luis.henriques@linux.dev>
---
fs/ext4/inline.c | 18 +++++++-----------
1 file changed, 7 insertions(+), 11 deletions(-)
diff --git a/fs/ext4/inline.c b/fs/ext4/inline.c
index 3536ca7e4fcc..d2e519920252 100644
--- a/fs/ext4/inline.c
+++ b/fs/ext4/inline.c
@@ -516,22 +516,18 @@ int ext4_readpage_inline(struct inode *inode, struct folio *folio)
int ret = 0;
down_read(&EXT4_I(inode)->xattr_sem);
- if (!ext4_has_inline_data(inode)) {
- up_read(&EXT4_I(inode)->xattr_sem);
- return -EAGAIN;
- }
/*
- * Current inline data can only exist in the 1st page,
- * So for all the other pages, just set them uptodate.
+ * Current inline data can only exist in the 1st page; for all the
+ * other pages simply revert to regular readpages
*/
- if (!folio->index)
- ret = ext4_read_inline_folio(inode, folio);
- else if (!folio_test_uptodate(folio)) {
- folio_zero_segment(folio, 0, folio_size(folio));
- folio_mark_uptodate(folio);
+ if (!ext4_has_inline_data(inode) || folio->index) {
+ up_read(&EXT4_I(inode)->xattr_sem);
+ return -EAGAIN;
}
+ ret = ext4_read_inline_folio(inode, folio);
+
up_read(&EXT4_I(inode)->xattr_sem);
folio_unlock(folio);
reply other threads:[~2024-10-11 10:24 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=20241011102445.13305-1-luis.henriques@linux.dev \
--to=luis.henriques@linux.dev \
--cc=adilger.kernel@dilger.ca \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=tytso@mit.edu \
/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;
as well as URLs for NNTP newsgroup(s).