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 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.