]> git.ipfire.org Git - thirdparty/xfsprogs-dev.git/commit
xfs_repair: do not check symlink component lengths
authorEric Sandeen <sandeen@sandeen.net>
Thu, 5 Feb 2015 23:24:36 +0000 (10:24 +1100)
committerDave Chinner <david@fromorbit.com>
Thu, 5 Feb 2015 23:24:36 +0000 (10:24 +1100)
commit2116b6a6714586e6775fd20337efa54968d08250
treeba33b0a3819a02e08e520b46b07480570884a9a2
parent247d903c1444e502f17747e6a7d323f1671690b5
xfs_repair: do not check symlink component lengths

As reported by Andy Grimm,

# ln -s $( python -c 'print "a" * 260' ) /mnt/foo

will succeed on xfs, but then xfs_repair will complain:

component of symlink in inode 131 too long
problem with symbolic link in inode 131
would have cleared inode 131

The kernel checks the total length of the symlink on both read
and write, but does not look at component paths.

Looking around the kernel, no other filesystem checks component
lengths, nor does the vfs.  And as Andy points out, the target
could even be on a different filesystem, with different limitations.

And having a "too-long" component doesn't even seem like something
likely to stem from disk corruption anyway, so I'm not sure why repair
should care.

Therefore I propose removing the component length checks from xfs_repair.

Andy Grimm <agrimm@redhat.com>
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Reviewed-by: Brian Foster <bfoster@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
repair/dinode.c