From: Brian Foster <bfoster@redhat.com>
To: Eric Sandeen <sandeen@sandeen.net>
Cc: Andy Grimm <agrimm@redhat.com>, xfs-oss <xfs@oss.sgi.com>
Subject: Re: [PATCH] xfs_repair: do not check symlink component lengths
Date: Thu, 18 Dec 2014 10:12:37 -0500 [thread overview]
Message-ID: <20141218151237.GB13471@laptop.bfoster> (raw)
In-Reply-To: <548215D6.5020804@sandeen.net>
On Fri, Dec 05, 2014 at 02:30:14PM -0600, Eric Sandeen wrote:
> 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.
>
Interesting, but we do enforce dentry name limits, yes? At least, I
can't create such a component on an XFS fs (haven't dug into where that
is enforced).
> 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.
>
My guess would be the intent is based on the above, where we can't
create such a long component name and thus a component that exceeds the
limits must be "invalid."
That said, a broken symlink is generally valid and not the same as
corruption, so I think I agree that this is somewhat misplaced
functionality...
> 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>
>
> diff --git a/repair/dinode.c b/repair/dinode.c
> index 38a6562..73e4b9e 100644
> --- a/repair/dinode.c
> +++ b/repair/dinode.c
> @@ -1333,7 +1333,7 @@ process_symlink(
> xfs_dinode_t *dino,
> blkmap_t *blkmap)
> {
> - char *symlink, *cptr;
> + char *symlink;
> char data[MAXPATHLEN];
>
> /*
> @@ -1380,31 +1380,6 @@ _("found illegal null character in symlink inode %" PRIu64 "\n"),
> return(1);
> }
>
> - /*
> - * check for any component being too long
> - */
> - if (be64_to_cpu(dino->di_size) >= MAXNAMELEN) {
> - cptr = strchr(symlink, '/');
> -
> - while (cptr != NULL) {
> - if (cptr - symlink >= MAXNAMELEN) {
> - do_warn(
> -_("component of symlink in inode %" PRIu64 " too long\n"),
> - lino);
> - return(1);
> - }
> - symlink = cptr + 1;
> - cptr = strchr(symlink, '/');
> - }
> -
> - if (strlen(symlink) >= MAXNAMELEN) {
> - do_warn(
> -_("component of symlink in inode %" PRIu64 " too long\n"),
> - lino);
> - return(1);
> - }
> - }
> -
> return(0);
> }
>
>
> _______________________________________________
> xfs mailing list
> xfs@oss.sgi.com
> http://oss.sgi.com/mailman/listinfo/xfs
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
prev parent reply other threads:[~2014-12-18 15:12 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-12-05 20:30 [PATCH] xfs_repair: do not check symlink component lengths Eric Sandeen
2014-12-18 15:12 ` Brian Foster [this message]
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=20141218151237.GB13471@laptop.bfoster \
--to=bfoster@redhat.com \
--cc=agrimm@redhat.com \
--cc=sandeen@sandeen.net \
--cc=xfs@oss.sgi.com \
/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