From: Jan Kara <jack@suse.cz>
To: Nick Piggin <npiggin@gmail.com>
Cc: Jan Kara <jack@suse.cz>, Jeff Moyer <jmoyer@redhat.com>,
Andrew Morton <akpm@linux-foundation.org>,
linux-fsdevel <linux-fsdevel@vger.kernel.org>,
linux-kernel@vger.kernel.org
Subject: Re: [patch] fs: aio fix rcu lookup
Date: Wed, 19 Jan 2011 17:50:11 +0100 [thread overview]
Message-ID: <20110119165011.GA16682@quack.suse.cz> (raw)
In-Reply-To: <AANLkTi=Z0eyXBkWL6YYdUVzA16hs=WjC7u=wfEHzAozC@mail.gmail.com>
On Thu 20-01-11 03:03:23, Nick Piggin wrote:
> On Thu, Jan 20, 2011 at 12:21 AM, Jan Kara <jack@suse.cz> wrote:
> > Well, we are not required to cancel all the outstanding AIO because of the
> > API requirement, that's granted. But we must do it because of the way how
> > the code is written. Outstanding IO requests reference ioctx but they are
> > not counted in ctx->users but in ctx->reqs_active. So the code relies on
> > the fact that the reference held by the hash table protects ctx from being
> > freed and io_destroy() waits for requests before dropping the last
> > reference to ctx. But there's the second race I describe making it possible
> > for new IO to be created after io_destroy() has waited for all IO to
> > finish...
>
> Yes there is that race too I agree. I just didn't follow through the code far
> enough to see it was a problem -- I thought it was by design.
>
> I'd like to solve it without synchronize_rcu() though.
Ah, OK. I don't find io_destroy() performance critical but I can
understand that you need not like synchronize_rcu() there. ;) Then it
should be possible to make IO requests count in ctx->users which would
solve the race as well. We'd just have to be prepared that request
completion might put the last reference to ioctx and free it but that
shouldn't be an issue. Do you like that solution better?
Honza
--
Jan Kara <jack@suse.cz>
SUSE Labs, CR
next prev parent reply other threads:[~2011-01-19 16:50 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-01-14 1:35 [patch] fs: aio fix rcu lookup Nick Piggin
2011-01-14 14:52 ` Jeff Moyer
2011-01-14 15:00 ` Nick Piggin
2011-01-17 19:07 ` Jeff Moyer
2011-01-17 23:24 ` Nick Piggin
2011-01-18 17:21 ` Jeff Moyer
2011-01-18 19:01 ` Jan Kara
2011-01-18 22:17 ` Nick Piggin
2011-01-18 23:00 ` Jeff Moyer
2011-01-18 23:05 ` Nick Piggin
2011-01-18 23:52 ` Jan Kara
2011-01-19 0:20 ` Nick Piggin
2011-01-19 13:21 ` Jan Kara
2011-01-19 16:03 ` Nick Piggin
2011-01-19 16:50 ` Jan Kara [this message]
2011-01-19 17:37 ` Nick Piggin
2011-01-20 20:21 ` Jan Kara
2011-01-19 19:13 ` Jeff Moyer
2011-01-19 19:46 ` Jeff Moyer
2011-01-19 20:18 ` Nick Piggin
2011-01-19 20:32 ` Jeff Moyer
2011-01-19 20:45 ` Nick Piggin
2011-01-19 21:03 ` Jeff Moyer
2011-01-19 21:20 ` Nick Piggin
2011-01-20 4:03 ` Paul E. McKenney
2011-01-20 18:31 ` Nick Piggin
2011-01-20 20:02 ` Paul E. McKenney
2011-01-20 20:15 ` Eric Dumazet
2011-01-21 21:22 ` Paul E. McKenney
2011-01-20 20:16 ` Jan Kara
2011-01-20 21:16 ` Jeff Moyer
2011-02-01 16:24 ` Jan Kara
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=20110119165011.GA16682@quack.suse.cz \
--to=jack@suse.cz \
--cc=akpm@linux-foundation.org \
--cc=jmoyer@redhat.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=npiggin@gmail.com \
/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).