From: Josef Bacik <jbacik@fusionio.com>
To: Liu Bo <bo.li.liu@oracle.com>
Cc: Josef Bacik <JBacik@fusionio.com>,
"linux-btrfs@vger.kernel.org" <linux-btrfs@vger.kernel.org>
Subject: Re: [PATCH] Btrfs: fix race in sync and freeze again
Date: Fri, 14 Sep 2012 11:03:29 -0400 [thread overview]
Message-ID: <20120914150329.GN12994@localhost.localdomain> (raw)
In-Reply-To: <50534510.1080101@oracle.com>
On Fri, Sep 14, 2012 at 08:54:08AM -0600, Liu Bo wrote:
> On 09/14/2012 10:37 PM, Josef Bacik wrote:
> > I screwed this up, there is a race between checking if there is a running
> > transaction and actually starting a transaction in sync where we could race
> > with a freezer and get ourselves into trouble. To fix this we need to make
> > a new join type to only do the try lock on the freeze stuff. If it fails
> > we'll return EPERM and just return from sync. This fixes a hang Liu Bo
> > reported when running xfstest 68 in a loop. Thanks,
> >
>
> This is also a trylock, why don't we just add a trylock for sb_start_intwrite directly
> just as what I've done before, that'd be cleaner:
>
> https://patchwork.kernel.org/patch/1318131/
>
Yeah if we get a sb_start_intwrite_trylock() then we can switch to using that in
the future, but for now I'm not going to block behind something needing to be
accepted into someone elses tree in order to get this fixed in btrfs. Also the
patch you've posted isn't right because we hold the rwsem and an ref, so we have
to drop the rwsem before calling btrfs_join_transaction and then we need to make
sure to do sb_end_intwrite() after we do the commit to clean up our ref, my
approach is cleaner since it still lets the transaction deal with all of that
cleanup and we don't have to play with the freeze rwsem. Thanks,
Josef
prev parent reply other threads:[~2012-09-14 15:03 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-09-14 14:37 [PATCH] Btrfs: fix race in sync and freeze again Josef Bacik
2012-09-14 14:54 ` Liu Bo
2012-09-14 15:03 ` 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=20120914150329.GN12994@localhost.localdomain \
--to=jbacik@fusionio.com \
--cc=bo.li.liu@oracle.com \
--cc=linux-btrfs@vger.kernel.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).