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
prev parent 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).