[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <Pine.LNX.4.64.0803081353110.9905@alien.or.mcafeemobile.com>
Date: Sat, 8 Mar 2008 13:55:13 -0800 (PST)
From: Davide Libenzi <davidel@...ilserver.org>
To: Jeff Roberson <jroberson@...sapeake.net>
cc: Rik van Riel <riel@...hat.com>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Zach Brown <zach.brown@...cle.com>
Subject: Re: [PATCH] eventfd signal race in aio_complete()
On Sat, 8 Mar 2008, Jeff Roberson wrote:
> On Sat, 8 Mar 2008, Davide Libenzi wrote:
>
> > On Sat, 8 Mar 2008, Rik van Riel wrote:
> >
> > > On Fri, 7 Mar 2008 20:29:20 -0800 (PST)
> > > Davide Libenzi <davidel@...ilserver.org> wrote:
> > >
> > > > The second solution/patch simply moves the eventfd_signal() call before
> > > > the __aio_put_req() call, but after the event has beed "ringed".
> > > > We should be clear to go with the shorter/nicer second solution. Those
> > > > patches builds, but I'm not even signing them off till I tested them.
> > >
> > > If there are no spinlock ordering issues between &ctx->ctx_lock
> > > and &ctx->wqh.lock (taken inside eventfd_signal), then the second
> > > patch is indeed preferable.
> > >
> > > Jeff and I did look at that briefly last night, but were not
> > > familiar enough with the code to decide whether or not that was
> > > safe.
> >
> > There's no interlocking between the two, so let's go with #2.
> > Jeff, would you mind giving patch #2 a spin in your test suite?
>
> I agree #2 would be best as well. It may take me a few days due to some
> equipment issues but I will get back to you as soon as I can.
I've just tested it here, and it's fine. My test case is not as complex as
yours though, so I'll wait your feedback before posting. Just remember to
ping me back, otherwise I'll forget to post ;)
- Davide
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists