public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Eric Sandeen <sandeen@sandeen.net>
To: xfs-oss <xfs@oss.sgi.com>, Andy Grimm <agrimm@redhat.com>
Subject: [PATCH] xfs_repair: do not check symlink component lengths
Date: Fri, 05 Dec 2014 14:30:14 -0600	[thread overview]
Message-ID: <548215D6.5020804@sandeen.net> (raw)

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

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

             reply	other threads:[~2014-12-05 20:30 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-12-05 20:30 Eric Sandeen [this message]
2014-12-18 15:12 ` [PATCH] xfs_repair: do not check symlink component lengths Brian Foster

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=548215D6.5020804@sandeen.net \
    --to=sandeen@sandeen.net \
    --cc=agrimm@redhat.com \
    --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