linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Josef Bacik <jbacik@fusionio.com>
To: Stefan Behrens <sbehrens@giantdisaster.de>
Cc: Josef Bacik <jbacik@fusionio.com>, <linux-btrfs@vger.kernel.org>
Subject: Re: [PATCH] Btrfs: check to see if root_list is empty before adding it to dead roots
Date: Fri, 26 Jul 2013 09:09:15 -0400	[thread overview]
Message-ID: <20130726130915.GA24583@localhost.localdomain> (raw)
In-Reply-To: <51F243A7.1060907@giantdisaster.de>

On Fri, Jul 26, 2013 at 11:38:47AM +0200, Stefan Behrens wrote:
> On Thu, 25 Jul 2013 15:13:40 -0400, Josef Bacik wrote:
> > A user reported a panic when running with autodefrag and deleting snapshots.
> > This is because we could end up trying to add the root to the dead roots list
> > twice.  To fix this check to see if we are empty before adding ourselves to the
> > dead roots list.  Thanks,
> > 
> > Signed-off-by: Josef Bacik <jbacik@fusionio.com>
> 
> Tested-by: Stefan Behrens <sbehrens@giantdisaster.de>
> 
> The patch eliminates the crash. The question still is whether the double addition to the list is an indication for a problem and this patch just hides that there is a problem.

This is what is happening

start writing file
  notice it was a random write, add it to the defrag list
Delete subvol
 evict all dentry/icache
  roots inode tree is empty, add to dead root
process defrag inodes
  lookup inode based on its location and root
    do our defrag
      iput in finish_ordered_io, which removes us from the inode tree
        notice the inode tree is empty, add root to dead root 
	  EXPLOSION

So we could probably avoid this issue by checking the root's count before we go
to lookup the inode and just bailing if the used count is 0, but then if we race
between looking up the root and looking up the inode we could end up in the same
situation, because we'd have to check again after looking up the inode and iput
there if the count was 0 and we'd be in the same mess again, though with a much
smaller window.  So this patch fixes the actual problem, it's not a paper over.
I will fix us to not do anything if the root has been deleted since theres no
sense in doing the extra work, but we'll still need this for the small window
between looking up the root and looking up the inode.  Thanks,

Josef

      reply	other threads:[~2013-07-26 13:09 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-07-25 19:13 [PATCH] Btrfs: check to see if root_list is empty before adding it to dead roots Josef Bacik
2013-07-25 21:31 ` Zach Brown
2013-07-26  9:38 ` Stefan Behrens
2013-07-26 13:09   ` Josef Bacik [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=20130726130915.GA24583@localhost.localdomain \
    --to=jbacik@fusionio.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=sbehrens@giantdisaster.de \
    /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).