All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jan Kara <jack@suse.cz>
To: "J. Bruce Fields" <bfields@fieldses.org>
Cc: Jan Kara <jack@suse.cz>, Ted Ts'o <tytso@mit.edu>,
	Andreas Dilger <adilger@dilger.ca>,
	linux-fsdevel@vger.kernel.org,
	Ext4 Developers List <linux-ext4@vger.kernel.org>,
	viro@ZenIV.linux.org.uk, sami.liedes@iki.fi
Subject: Re: [PATCH] vfs: avoid hang caused by attempting to rmdir an invalid file system
Date: Wed, 30 May 2012 22:12:57 +0200	[thread overview]
Message-ID: <20120530201256.GA32477@quack.suse.cz> (raw)
In-Reply-To: <20120530173709.GB16317@fieldses.org>

On Wed 30-05-12 13:37:09, J. Bruce Fields wrote:
> On Tue, May 29, 2012 at 10:08:56PM +0200, Jan Kara wrote:
> > On Tue 29-05-12 21:50:19, Jan Kara wrote:
> > > On Mon 28-05-12 17:05:11, Ted Tso wrote:
> > > > On Mon, May 28, 2012 at 02:29:05PM -0600, Andreas Dilger wrote:
> > > > > This patch is good from the POV of covering all filesystems, and
> > > > > avoiding the deadlock at the dcache level.  It would be possible to
> > > > > detect this problem in the filesystem itself during lookup, before
> > > > > the bad link got into the dcache itself.  Something like:
> > > > 
> > > > I like that as a solution for detecting the problem in ext4.  As you
> > > > say, it's still an issue for other file systems, and so the patch I
> > > > proposed is still probably a good idea for the VFS.  But this way ext4
> > > > (and ext3 when Jan backports it) will be able to detect the problem
> > > > and mark the file system as being corrupted.
> > >   Actually, I think there's even better way. d_splice_alias() can rather
> > > easily detect the problem and report it to filesystem. The advantage is
> > > that the check in d_splice_alias() can catch any "hardlinks" to
> > > directories, not just self loops. The patch is attached, I also have
> > > corresponding handling written for ext? filesystems but that's trivial.
> > > I'll post the whole series to Al to have a look.
> >   And now with the attachment. Sorry.
> 
> Well, my understanding of d_splice_alias is that it should just return
> the existing dentry instead of failing.  (It does that now for
> DISCONNECTED dentries, but I don't understand why they're special.)
> So that's what:
> 
> http://git.kernel.org/?p=linux/kernel/git/viro/vfs.git;a=commit;h=9d345b3217b384813680901d42eae3fb380b9f77
> 
> does.
  Thanks for the pointer. In the case I tried to solve, returning the
existing dentry will solve the deadlocks, just user won't be warned that
the filesystem is corrupted. Since you seem to describe a valid case where
we can spot other !DISCONNECTED dentry of a directory, I guess we have no
other choice than using your approach.

We could do some sanity checks in ->lookup method (like Andreas suggested)
but they are not that powerful as a check in d_splice_alias() can be. But
what can one do...

								Honza


> > >From 0715b656ac88ce1bb62800b14d99ef2e25c26d28 Mon Sep 17 00:00:00 2001
> > From: Jan Kara <jack@suse.cz>
> > Date: Tue, 29 May 2012 21:19:01 +0200
> > Subject: [PATCH 1/4] vfs: Avoid creation of directory loops for corrupted filesystems
> > 
> > When a directory hierarchy is corrupted (e. g. due to a bit flip on the media),
> > it can happen that it contains loops of directories. That creates possibilities
> > for deadlock when locking directories.
> > 
> > Fix the problem by checking in d_splice_alias() that when we splice a
> > directory, it does not have any other connected alias.
> > 
> > Reported-by: Sami Liedes <sami.liedes@iki.fi>
> > Signed-off-by: Jan Kara <jack@suse.cz>
> > ---
> >  fs/dcache.c |    4 ++++
> >  1 files changed, 4 insertions(+), 0 deletions(-)
> > 
> > diff --git a/fs/dcache.c b/fs/dcache.c
> > index 4435d8b..ca31a1e 100644
> > --- a/fs/dcache.c
> > +++ b/fs/dcache.c
> > @@ -1658,6 +1658,10 @@ struct dentry *d_splice_alias(struct inode *inode, struct dentry *dentry)
> >  			d_move(new, dentry);
> >  			iput(inode);
> >  		} else {
> > +			if (unlikely(!list_empty(&inode->i_dentry))) {
> > +				spin_unlock(&inode->i_lock);
> > +				return ERR_PTR(-EIO);
> > +			}
> >  			/* already taking inode->i_lock, so d_add() by hand */
> >  			__d_instantiate(dentry, inode);
> >  			spin_unlock(&inode->i_lock);
> > -- 
> > 1.7.1
> > 
> 
-- 
Jan Kara <jack@suse.cz>
SUSE Labs, CR

  reply	other threads:[~2012-05-30 20:13 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-05-28 17:33 [PATCH] vfs: avoid hang caused by attempting to rmdir an invalid file system Theodore Ts'o
2012-05-28 20:29 ` Andreas Dilger
2012-05-28 21:05   ` Ted Ts'o
2012-05-29 19:50     ` Jan Kara
2012-05-29 20:08       ` Jan Kara
2012-05-30 17:37         ` J. Bruce Fields
2012-05-30 20:12           ` Jan Kara [this message]
2012-06-18 21:19             ` J. Bruce Fields
2012-06-20  9:57               ` Jan Kara
2012-05-29  8:21 ` Greg KH
2012-05-29 12:18   ` Ted Ts'o
2012-05-29 11:25 ` Bernd Schubert
  -- strict thread matches above, loose matches on Subject: below --
2012-05-28 17:31 ext2 hang on (intentionally) corrupted filesystem Ted Ts'o
2012-05-28 17:34 ` [PATCH] vfs: avoid hang caused by attempting to rmdir an invalid file system Theodore Ts'o

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=20120530201256.GA32477@quack.suse.cz \
    --to=jack@suse.cz \
    --cc=adilger@dilger.ca \
    --cc=bfields@fieldses.org \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=sami.liedes@iki.fi \
    --cc=tytso@mit.edu \
    --cc=viro@ZenIV.linux.org.uk \
    /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.