From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jeff Moyer Subject: Re: [patch] fs: aio fix rcu lookup Date: Wed, 19 Jan 2011 15:32:54 -0500 Message-ID: References: <20110118190114.GA5070@quack.suse.cz> <20110118235236.GA14087@quack.suse.cz> <20110119132123.GC4246@quack.suse.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: Jan Kara , Andrew Morton , linux-fsdevel , linux-kernel@vger.kernel.org, "Paul E. McKenney" To: Nick Piggin Return-path: In-Reply-To: (Nick Piggin's message of "Thu, 20 Jan 2011 07:18:53 +1100") Sender: linux-kernel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org Nick Piggin writes: > On Thu, Jan 20, 2011 at 6:46 AM, Jeff Moyer wrote= : >> Jeff Moyer writes: >> >>> Jan Kara writes: >>> >>>> =C2=A0But 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... >>> >>> Can't that be solved by introducing memory barriers around the acce= sses >>> to ->dead? >> >> Upon further consideration, I don't think so. >> >> Given the options, I think adding the synchronize rcu to the io_dest= roy >> path is the best way forward. =C2=A0You're already waiting for a bun= ch of >> queued I/O to finish, so there is no guarantee that you're going to >> finish that call quickly. > > I think synchronize_rcu() is not something to sprinkle around outside > very slow paths. It can be done without synchronize_rcu. I'm not sure I understand what you're saying. Do you mean to imply tha= t io_destroy is not a very slow path? Because it is. I prefer a solutio= n that doesn't re-architecht things in order to solve a theoretical issue that's never been observed. Cheers, Jeff