@@ -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);
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(-)