linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Josef Bacik <jbacik@fusionio.com>
To: Zach Brown <zab@zabbo.net>
Cc: Josef Bacik <JBacik@fusionio.com>,
	"linux-btrfs@vger.kernel.org" <linux-btrfs@vger.kernel.org>
Subject: Re: [PATCH] Btrfs: unlock extent when the dio completes for reads
Date: Wed, 1 Aug 2012 08:10:23 -0400	[thread overview]
Message-ID: <20120801121023.GB2263@localhost.localdomain> (raw)
In-Reply-To: <20120731213049.GB31939@lenny.home.zabbo.net>

On Tue, Jul 31, 2012 at 03:30:49PM -0600, Zach Brown wrote:
> > +static void btrfs_direct_read_iodone(struct kiocb *iocb, loff_t offset,
> > +				     ssize_t bytes, void *private, int ret,
> > +				     bool is_async)
> > +{
> > +	struct inode *inode = iocb->ki_filp->f_mapping->host;
> > +	u64 lockend;
> > +
> > +	if (get_state_private(&BTRFS_I(inode)->io_tree, offset, &lockend)) {
> > +		WARN_ON(1);
> > +		goto out;
> > +	}
> > +
> > +	unlock_extent(&BTRFS_I(inode)->io_tree, offset, lockend);
> > +out:
> > +	if (is_async)
> > +		aio_complete(iocb, ret, 0);
> > +	inode_dio_done(inode);
> > +}
> 
> Hmm.  I'm worried that this can be called from interrupt context and the
> state/extent calls there seem to use bare spin locks.  Did you run this
> with lockdep?  Am I confused?
> 

Our read completions are run in a helper thread since we need to do things like
clear the extent state stuff and such so it's safe in this regard.  Course I hit
a lockup with xfstests 91 because there are some cases where we can return
errors without doing the dio complete (rightly so since we haven't setup the dio
yet), so now I have to figure out how to know when we've been unlocked via dio
complete or that I've gotten an error back and already unlocked it...

Josef

      reply	other threads:[~2012-08-01 12:10 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-07-31 20:33 [PATCH] Btrfs: unlock extent when the dio completes for reads Josef Bacik
2012-07-31 21:30 ` Zach Brown
2012-08-01 12:10   ` 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=20120801121023.GB2263@localhost.localdomain \
    --to=jbacik@fusionio.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=zab@zabbo.net \
    /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).