linux-xfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Catherine Hoang <catherine.hoang@oracle.com>
To: linux-xfs@vger.kernel.org
Subject: [PATCH 6.6 CANDIDATE v2 16/21] xfs: allow symlinks with short remote targets
Date: Wed,  2 Oct 2024 10:41:03 -0700	[thread overview]
Message-ID: <20241002174108.64615-17-catherine.hoang@oracle.com> (raw)
In-Reply-To: <20241002174108.64615-1-catherine.hoang@oracle.com>

From: "Darrick J. Wong" <djwong@kernel.org>

commit 38de567906d95c397d87f292b892686b7ec6fbc3 upstream.

An internal user complained about log recovery failing on a symlink
("Bad dinode after recovery") with the following (excerpted) format:

core.magic = 0x494e
core.mode = 0120777
core.version = 3
core.format = 2 (extents)
core.nlinkv2 = 1
core.nextents = 1
core.size = 297
core.nblocks = 1
core.naextents = 0
core.forkoff = 0
core.aformat = 2 (extents)
u3.bmx[0] = [startoff,startblock,blockcount,extentflag]
0:[0,12,1,0]

This is a symbolic link with a 297-byte target stored in a disk block,
which is to say this is a symlink with a remote target.  The forkoff is
0, which is to say that there's 512 - 176 == 336 bytes in the inode core
to store the data fork.

Eventually, testing of generic/388 failed with the same inode corruption
message during inode recovery.  In writing a debugging patch to call
xfs_dinode_verify on dirty inode log items when we're committing
transactions, I observed that xfs/298 can reproduce the problem quite
quickly.

xfs/298 creates a symbolic link, adds some extended attributes, then
deletes them all.  The test failure occurs when the final removexattr
also deletes the attr fork because that does not convert the remote
symlink back into a shortform symlink.  That is how we trip this test.
The only reason why xfs/298 only triggers with the debug patch added is
that it deletes the symlink, so the final iflush shows the inode as
free.

I wrote a quick fstest to emulate the behavior of xfs/298, except that
it leaves the symlinks on the filesystem after inducing the "corrupt"
state.  Kernels going back at least as far as 4.18 have written out
symlink inodes in this manner and prior to 1eb70f54c445f they did not
object to reading them back in.

Because we've been writing out inodes this way for quite some time, the
only way to fix this is to relax the check for symbolic links.
Directories don't have this problem because di_size is bumped to
blocksize during the sf->data conversion.

Fixes: 1eb70f54c445f ("xfs: validate inode fork size against fork format")
Signed-off-by: "Darrick J. Wong" <djwong@kernel.org>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Chandan Babu R <chandanbabu@kernel.org>
Signed-off-by: Catherine Hoang <catherine.hoang@oracle.com>
---
 fs/xfs/libxfs/xfs_inode_buf.c | 28 ++++++++++++++++++++++++----
 1 file changed, 24 insertions(+), 4 deletions(-)

diff --git a/fs/xfs/libxfs/xfs_inode_buf.c b/fs/xfs/libxfs/xfs_inode_buf.c
index 0f970a0b3382..51fdd29c4ddc 100644
--- a/fs/xfs/libxfs/xfs_inode_buf.c
+++ b/fs/xfs/libxfs/xfs_inode_buf.c
@@ -366,17 +366,37 @@ xfs_dinode_verify_fork(
 	/*
 	 * For fork types that can contain local data, check that the fork
 	 * format matches the size of local data contained within the fork.
-	 *
-	 * For all types, check that when the size says the should be in extent
-	 * or btree format, the inode isn't claiming it is in local format.
 	 */
 	if (whichfork == XFS_DATA_FORK) {
-		if (S_ISDIR(mode) || S_ISLNK(mode)) {
+		/*
+		 * A directory small enough to fit in the inode must be stored
+		 * in local format.  The directory sf <-> extents conversion
+		 * code updates the directory size accordingly.
+		 */
+		if (S_ISDIR(mode)) {
+			if (be64_to_cpu(dip->di_size) <= fork_size &&
+			    fork_format != XFS_DINODE_FMT_LOCAL)
+				return __this_address;
+		}
+
+		/*
+		 * A symlink with a target small enough to fit in the inode can
+		 * be stored in extents format if xattrs were added (thus
+		 * converting the data fork from shortform to remote format)
+		 * and then removed.
+		 */
+		if (S_ISLNK(mode)) {
 			if (be64_to_cpu(dip->di_size) <= fork_size &&
+			    fork_format != XFS_DINODE_FMT_EXTENTS &&
 			    fork_format != XFS_DINODE_FMT_LOCAL)
 				return __this_address;
 		}
 
+		/*
+		 * For all types, check that when the size says the fork should
+		 * be in extent or btree format, the inode isn't claiming to be
+		 * in local format.
+		 */
 		if (be64_to_cpu(dip->di_size) > fork_size &&
 		    fork_format == XFS_DINODE_FMT_LOCAL)
 			return __this_address;
-- 
2.39.3


  parent reply	other threads:[~2024-10-02 17:41 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-10-02 17:40 [PATCH 6.6 CANDIDATE v2 00/21] xfs backports for 6.6.y (from v6.10) Catherine Hoang
2024-10-02 17:40 ` [PATCH 6.6 CANDIDATE v2 01/21] xfs: fix error returns from xfs_bmapi_write Catherine Hoang
2024-10-02 17:40 ` [PATCH 6.6 CANDIDATE v2 02/21] xfs: fix xfs_bmap_add_extent_delay_real for partial conversions Catherine Hoang
2024-10-02 17:40 ` [PATCH 6.6 CANDIDATE v2 03/21] xfs: remove a racy if_bytes check in xfs_reflink_end_cow_extent Catherine Hoang
2024-10-02 17:40 ` [PATCH 6.6 CANDIDATE v2 04/21] xfs: require XFS_SB_FEAT_INCOMPAT_LOG_XATTRS for attr log intent item recovery Catherine Hoang
2024-10-02 17:40 ` [PATCH 6.6 CANDIDATE v2 05/21] xfs: check opcode and iovec count match in xlog_recover_attri_commit_pass2 Catherine Hoang
2024-10-02 17:40 ` [PATCH 6.6 CANDIDATE v2 06/21] xfs: fix missing check for invalid attr flags Catherine Hoang
2024-10-02 17:40 ` [PATCH 6.6 CANDIDATE v2 07/21] xfs: check shortform attr entry flags specifically Catherine Hoang
2024-10-02 17:40 ` [PATCH 6.6 CANDIDATE v2 08/21] xfs: validate recovered name buffers when recovering xattr items Catherine Hoang
2024-10-02 17:40 ` [PATCH 6.6 CANDIDATE v2 09/21] xfs: enforce one namespace per attribute Catherine Hoang
2024-10-02 17:40 ` [PATCH 6.6 CANDIDATE v2 10/21] xfs: revert commit 44af6c7e59b12 Catherine Hoang
2024-10-02 17:40 ` [PATCH 6.6 CANDIDATE v2 11/21] xfs: use dontcache for grabbing inodes during scrub Catherine Hoang
2024-10-02 17:40 ` [PATCH 6.6 CANDIDATE v2 12/21] xfs: match lock mode in xfs_buffered_write_iomap_begin() Catherine Hoang
2024-10-02 17:41 ` [PATCH 6.6 CANDIDATE v2 13/21] xfs: make the seq argument to xfs_bmapi_convert_delalloc() optional Catherine Hoang
2024-10-02 17:41 ` [PATCH 6.6 CANDIDATE v2 14/21] xfs: make xfs_bmapi_convert_delalloc() to allocate the target offset Catherine Hoang
2024-10-02 17:41 ` [PATCH 6.6 CANDIDATE v2 15/21] xfs: convert delayed extents to unwritten when zeroing post eof blocks Catherine Hoang
2024-10-02 17:41 ` Catherine Hoang [this message]
2024-10-02 17:41 ` [PATCH 6.6 CANDIDATE v2 17/21] xfs: make sure sb_fdblocks is non-negative Catherine Hoang
2024-10-02 17:41 ` [PATCH 6.6 CANDIDATE v2 18/21] xfs: fix unlink vs cluster buffer instantiation race Catherine Hoang
2024-10-02 17:41 ` [PATCH 6.6 CANDIDATE v2 19/21] xfs: fix freeing speculative preallocations for preallocated files Catherine Hoang
2024-10-02 17:41 ` [PATCH 6.6 CANDIDATE v2 20/21] xfs: restrict when we try to align cow fork delalloc to cowextsz hints Catherine Hoang
2024-10-02 17:41 ` [PATCH 6.6 CANDIDATE v2 21/21] xfs: allow unlinked symlinks and dirs with zero size Catherine Hoang

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=20241002174108.64615-17-catherine.hoang@oracle.com \
    --to=catherine.hoang@oracle.com \
    --cc=linux-xfs@vger.kernel.org \
    /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).