linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Liu Bo <bo.li.liu@oracle.com>
To: Mitch Harder <mitch.harder@sabayonlinux.org>
Cc: linux-btrfs@vger.kernel.org, chris.mason@fusionio.com,
	JBacik@fusionio.com, dave@jikos.cz, kitayama@cl.bb4u.ne.jp,
	miaox@cn.fujitsu.com
Subject: Re: [PATCH V5] Btrfs: snapshot-aware defrag
Date: Sun, 27 Jan 2013 20:41:55 +0800	[thread overview]
Message-ID: <20130127124154.GA16722@liubo> (raw)
In-Reply-To: <CAKcLGm_fyGU3rXKvBfcjQtJDx+1JrbxiDAw1w0EpnPcc2xiHvA@mail.gmail.com>

On Fri, Jan 25, 2013 at 12:16:29PM -0600, Mitch Harder wrote:
[...]
> >>
> >> I've changed up my reproducer to try some things that may hit the
> >> issue quicker and more reliably.
> >>
> >> It gave me a slightly different set of warnings in dmesg, which seem
> >> to suggest issues in the dead_root list.
> >
> > Great!  Many thanks for nail it down, we really shouldn't iput()
> > after btrfs_iget().
> >
> > Could you please try this(remove iput()) and see if it gets us rid of
> > the trouble?
> >
> > thanks,
> > liubo
> >
> > diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c
> > index 1683f48..c7a0fb7 100644
> > --- a/fs/btrfs/inode.c
> > +++ b/fs/btrfs/inode.c
> > @@ -2337,7 +2337,6 @@ out_free_path:
> >  out_unlock:
> >         unlock_extent_cached(&BTRFS_I(inode)->io_tree, lock_start,
> > lock_end,
> >                              &cached, GFP_NOFS);
> > -       iput(inode);
> >         return ret;
> >  }
> >
> 
> With this patch, the cleaner never runs to delete the old roots.

Hi Mitch,

Many thanks for testing it!

Well, after some debugging, I finally figure out the whys:

(1) btrfs_ioctl_snap_destroy() will free the inode of snapshot and set
root's refs to zero(btrfs_set_root_refs()), if this inode happens to
be the only one in the rbtree of the snapshot's root at this moment,
we add this root to the dead_root list.

(2) Unfortunately, after (1), our snapshot-aware defrag work may read
another inode in this snapshot into memory during 'relink' stage, and
later after we finish relink work and iput() will force us to add the
snapshot's root to the dead_root list again.

So that's why we get double list_add and list_del corruption.

And IMO, it can also take place without snapshot-aware defrag, but it's a
rare case.

So could you please try this? 

thanks,
liubo

diff --git a/fs/btrfs/transaction.c b/fs/btrfs/transaction.c
index f154946..d4ee66b 100644
--- a/fs/btrfs/transaction.c
+++ b/fs/btrfs/transaction.c
@@ -885,7 +885,15 @@ static noinline int commit_cowonly_roots(struct btrfs_trans_handle *trans,
 int btrfs_add_dead_root(struct btrfs_root *root)
 {
 	spin_lock(&root->fs_info->trans_lock);
+	if (!list_empty(&root->root_list)) {
+		struct btrfs_root *tmp;
+		list_for_each_entry(tmp, &root->fs_info->dead_roots, root_list)
+			if (tmp == root)
+				goto unlock;
+	}
+
 	list_add(&root->root_list, &root->fs_info->dead_roots);
+unlock:
 	spin_unlock(&root->fs_info->trans_lock);
 	return 0;
 }


  reply	other threads:[~2013-01-27 12:44 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-01-16 12:36 [PATCH V5] Btrfs: snapshot-aware defrag Liu Bo
2013-01-17 14:42 ` Mitch Harder
2013-01-18  0:53   ` Liu Bo
2013-01-18  5:23     ` Mitch Harder
2013-01-18 12:19   ` David Sterba
2013-01-18 22:01     ` Mitch Harder
2013-01-22 17:41   ` Mitch Harder
2013-01-23  7:51     ` Liu Bo
2013-01-23 16:05       ` Mitch Harder
2013-01-24  0:52         ` Liu Bo
2013-01-25 14:55           ` Mitch Harder
2013-01-25 15:40             ` Stefan Behrens
2013-01-27 13:19               ` Liu Bo
2013-01-28 16:55                 ` Stefan Behrens
2013-02-16  6:47                   ` Liu Bo
2013-02-18 16:53                     ` Stefan Behrens
2013-02-19  4:29                       ` Liu Bo
2013-02-19 17:53                         ` Stefan Behrens
2013-01-25 15:42             ` Liu Bo
2013-01-25 18:16               ` Mitch Harder
2013-01-27 12:41                 ` Liu Bo [this message]
2013-01-28  5:20                   ` Mitch Harder
2013-01-28  6:54                     ` Liu Bo

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=20130127124154.GA16722@liubo \
    --to=bo.li.liu@oracle.com \
    --cc=JBacik@fusionio.com \
    --cc=chris.mason@fusionio.com \
    --cc=dave@jikos.cz \
    --cc=kitayama@cl.bb4u.ne.jp \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=miaox@cn.fujitsu.com \
    --cc=mitch.harder@sabayonlinux.org \
    /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;
as well as URLs for NNTP newsgroup(s).