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 16:03:47 -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: Received: from mx1.redhat.com ([209.132.183.28]:35133 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753901Ab1ASVD4 convert rfc822-to-8bit (ORCPT ); Wed, 19 Jan 2011 16:03:56 -0500 In-Reply-To: (Nick Piggin's message of "Thu, 20 Jan 2011 07:45:42 +1100") Sender: linux-fsdevel-owner@vger.kernel.org List-ID: Nick Piggin writes: > On Thu, Jan 20, 2011 at 7:32 AM, Jeff Moyer wrote= : >> Nick Piggin writes: >> >>> On Thu, Jan 20, 2011 at 6:46 AM, Jeff Moyer wro= te: >>>> 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 I= O to >>>>>> finish... >>>>> >>>>> Can't that be solved by introducing memory barriers around the ac= cesses >>>>> to ->dead? >>>> >>>> Upon further consideration, I don't think so. >>>> >>>> Given the options, I think adding the synchronize rcu to the io_de= stroy >>>> path is the best way forward. =C2=A0You're already waiting for a b= unch of >>>> queued I/O to finish, so there is no guarantee that you're going t= o >>>> finish that call quickly. >>> >>> I think synchronize_rcu() is not something to sprinkle around outsi= de >>> very slow paths. It can be done without synchronize_rcu. >> >> I'm not sure I understand what you're saying. =C2=A0Do you mean to i= mply that >> io_destroy is not a very slow path? =C2=A0Because it is. =C2=A0I pre= fer a solution >> that doesn't re-architecht things in order to solve a theoretical is= sue >> that's never been observed. > > Even something that happens once per process lifetime, like in fork/e= xit > is not necessarily suitable for RCU. Now you've really lost me. ;-) Processes which utilize the in-kernel aio interface typically create an ioctx at process startup, use that fo= r submitting all of their io, then destroy it on exit. Think of a database. Every time you call io_submit, you're doing a lookup of the ioctx. > I don't know exactly how all programs use io_destroy -- of the small > number that do, probably an even smaller number would care here. But = I > don't think it simplifies things enough to use synchronize_rcu for it= =2E Above it sounded like you didn't think AIO should be using RCU at all. Here it sounds like you are just against synchronize_rcu. Which is it? And if the latter, then please tell me in what cases you feel one would be justified in calling synchronize_rcu. For now, I simply disagree with you. As I said before, you're already potentially waiting for dis= k I/O to complete. It doesn't get much worse than that for latency. Cheers, Jeff -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel= " in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html