All of lore.kernel.org
 help / color / mirror / Atom feed
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: stable@vger.kernel.org
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	patches@lists.linux.dev, stable@kernel.org,
	Eric Whitney <enwlinux@gmail.com>, Jan Kara <jack@suse.cz>,
	Theodore Tso <tytso@mit.edu>
Subject: [PATCH 4.14 03/21] ext4: fix RENAME_WHITEOUT handling for inline directories
Date: Wed, 15 Mar 2023 13:12:26 +0100	[thread overview]
Message-ID: <20230315115718.949678470@linuxfoundation.org> (raw)
In-Reply-To: <20230315115718.796692048@linuxfoundation.org>

From: Eric Whitney <enwlinux@gmail.com>

commit c9f62c8b2dbf7240536c0cc9a4529397bb8bf38e upstream.

A significant number of xfstests can cause ext4 to log one or more
warning messages when they are run on a test file system where the
inline_data feature has been enabled.  An example:

"EXT4-fs warning (device vdc): ext4_dirblock_csum_set:425: inode
 #16385: comm fsstress: No space for directory leaf checksum. Please
run e2fsck -D."

The xfstests include: ext4/057, 058, and 307; generic/013, 051, 068,
070, 076, 078, 083, 232, 269, 270, 390, 461, 475, 476, 482, 579, 585,
589, 626, 631, and 650.

In this situation, the warning message indicates a bug in the code that
performs the RENAME_WHITEOUT operation on a directory entry that has
been stored inline.  It doesn't detect that the directory is stored
inline, and incorrectly attempts to compute a dirent block checksum on
the whiteout inode when creating it.  This attempt fails as a result
of the integrity checking in get_dirent_tail (usually due to a failure
to match the EXT4_FT_DIR_CSUM magic cookie), and the warning message
is then emitted.

Fix this by simply collecting the inlined data state at the time the
search for the source directory entry is performed.  Existing code
handles the rest, and this is sufficient to eliminate all spurious
warning messages produced by the tests above.  Go one step further
and do the same in the code that resets the source directory entry in
the event of failure.  The inlined state should be present in the
"old" struct, but given the possibility of a race there's no harm
in taking a conservative approach and getting that information again
since the directory entry is being reread anyway.

Fixes: b7ff91fd030d ("ext4: find old entry again if failed to rename whiteout")
Cc: stable@kernel.org
Signed-off-by: Eric Whitney <enwlinux@gmail.com>
Reviewed-by: Jan Kara <jack@suse.cz>
Link: https://lore.kernel.org/r/20230210173244.679890-1-enwlinux@gmail.com
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
 fs/ext4/namei.c |   13 +++++++------
 1 file changed, 7 insertions(+), 6 deletions(-)

--- a/fs/ext4/namei.c
+++ b/fs/ext4/namei.c
@@ -1425,11 +1425,10 @@ static struct buffer_head * ext4_find_en
 		int has_inline_data = 1;
 		ret = ext4_find_inline_entry(dir, &fname, res_dir,
 					     &has_inline_data);
-		if (has_inline_data) {
-			if (inlined)
-				*inlined = 1;
+		if (inlined)
+			*inlined = has_inline_data;
+		if (has_inline_data)
 			goto cleanup_and_exit;
-		}
 	}
 
 	if ((namelen <= 2) && (name[0] == '.') &&
@@ -3520,7 +3519,8 @@ static void ext4_resetent(handle_t *hand
 	 * so the old->de may no longer valid and need to find it again
 	 * before reset old inode info.
 	 */
-	old.bh = ext4_find_entry(old.dir, &old.dentry->d_name, &old.de, NULL);
+	old.bh = ext4_find_entry(old.dir, &old.dentry->d_name, &old.de,
+				 &old.inlined);
 	if (IS_ERR(old.bh))
 		retval = PTR_ERR(old.bh);
 	if (!old.bh)
@@ -3688,7 +3688,8 @@ static int ext4_rename(struct inode *old
 			return retval;
 	}
 
-	old.bh = ext4_find_entry(old.dir, &old.dentry->d_name, &old.de, NULL);
+	old.bh = ext4_find_entry(old.dir, &old.dentry->d_name, &old.de,
+				 &old.inlined);
 	if (IS_ERR(old.bh))
 		return PTR_ERR(old.bh);
 	/*



  parent reply	other threads:[~2023-03-15 12:14 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-15 12:12 [PATCH 4.14 00/21] 4.14.310-rc1 review Greg Kroah-Hartman
2023-03-15 12:12 ` [PATCH 4.14 01/21] fs: prevent out-of-bounds array speculation when closing a file descriptor Greg Kroah-Hartman
2023-03-15 12:12 ` [PATCH 4.14 02/21] x86/CPU/AMD: Disable XSAVES on AMD family 0x17 Greg Kroah-Hartman
2023-03-15 12:12 ` Greg Kroah-Hartman [this message]
2023-03-15 12:12 ` [PATCH 4.14 04/21] ext4: fix another off-by-one fsmap error on 1k block filesystems Greg Kroah-Hartman
2023-03-15 12:12 ` [PATCH 4.14 05/21] ext4: move where set the MAY_INLINE_DATA flag is set Greg Kroah-Hartman
2023-03-15 12:12 ` [PATCH 4.14 06/21] ext4: fix WARNING in ext4_update_inline_data Greg Kroah-Hartman
2023-03-15 12:12 ` [PATCH 4.14 07/21] ext4: zero i_disksize when initializing the bootloader inode Greg Kroah-Hartman
2023-03-15 12:12 ` [PATCH 4.14 08/21] nfc: change order inside nfc_se_io error path Greg Kroah-Hartman
2023-03-15 12:12 ` [PATCH 4.14 09/21] nfc: fdp: add null check of devm_kmalloc_array in fdp_nci_i2c_read_device_properties Greg Kroah-Hartman
2023-03-15 12:12 ` [PATCH 4.14 10/21] ila: do not generate empty messages in ila_xlat_nl_cmd_get_mapping() Greg Kroah-Hartman
2023-03-15 12:12 ` [PATCH 4.14 11/21] net: caif: Fix use-after-free in cfusbl_device_notify() Greg Kroah-Hartman
2023-03-15 12:12 ` [PATCH 4.14 12/21] clk: qcom: mmcc-apq8084: remove spdm clocks Greg Kroah-Hartman
2023-03-15 12:12 ` [PATCH 4.14 13/21] MIPS: Fix a compilation issue Greg Kroah-Hartman
2023-03-15 12:12 ` [PATCH 4.14 14/21] alpha: fix R_ALPHA_LITERAL reloc for large modules Greg Kroah-Hartman
2023-03-15 12:12 ` [PATCH 4.14 15/21] macintosh: windfarm: Use unsigned type for 1-bit bitfields Greg Kroah-Hartman
2023-03-15 12:12 ` [PATCH 4.14 16/21] PCI: Add SolidRun vendor ID Greg Kroah-Hartman
2023-03-15 12:12 ` [PATCH 4.14 17/21] PCI: Avoid FLR for SolidRun SNET DPU rev 1 Greg Kroah-Hartman
2023-03-15 12:12 ` [PATCH 4.14 18/21] media: ov5640: Fix analogue gain control Greg Kroah-Hartman
2023-03-15 12:12 ` [PATCH 4.14 19/21] tipc: improve function tipc_wait_for_cond() Greg Kroah-Hartman
2023-03-15 12:12 ` [PATCH 4.14 20/21] drm/i915: Dont use BAR mappings for ring buffers with LLC Greg Kroah-Hartman
2023-03-15 12:12   ` [Intel-gfx] " Greg Kroah-Hartman
2023-03-15 12:12 ` [PATCH 4.14 21/21] x86/cpu: Fix LFENCE serialization check in init_amd() Greg Kroah-Hartman
2023-03-15 13:55 ` [PATCH 4.14 00/21] 4.14.310-rc1 review Chris Paterson

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=20230315115718.949678470@linuxfoundation.org \
    --to=gregkh@linuxfoundation.org \
    --cc=enwlinux@gmail.com \
    --cc=jack@suse.cz \
    --cc=patches@lists.linux.dev \
    --cc=stable@kernel.org \
    --cc=stable@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 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.