From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754788Ab1ASVD7 (ORCPT ); Wed, 19 Jan 2011 16:03:59 -0500 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 From: Jeff Moyer To: Nick Piggin Cc: Jan Kara , Andrew Morton , linux-fsdevel , linux-kernel@vger.kernel.org, "Paul E. McKenney" Subject: Re: [patch] fs: aio fix rcu lookup References: <20110118190114.GA5070@quack.suse.cz> <20110118235236.GA14087@quack.suse.cz> <20110119132123.GC4246@quack.suse.cz> X-PGP-KeyID: 1F78E1B4 X-PGP-CertKey: F6FE 280D 8293 F72C 65FD 5A58 1FF8 A7CA 1F78 E1B4 X-PCLoadLetter: What the f**k does that mean? Date: Wed, 19 Jan 2011 16:03:47 -0500 In-Reply-To: (Nick Piggin's message of "Thu, 20 Jan 2011 07:45:42 +1100") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 wrote: >>>> Jeff Moyer writes: >>>> >>>>> Jan Kara writes: >>>>> >>>>>>  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... >>>>> >>>>> Can't that be solved by introducing memory barriers around the accesses >>>>> to ->dead? >>>> >>>> Upon further consideration, I don't think so. >>>> >>>> Given the options, I think adding the synchronize rcu to the io_destroy >>>> path is the best way forward.  You're already waiting for a bunch 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 that >> io_destroy is not a very slow path?  Because it is.  I prefer a solution >> that doesn't re-architecht things in order to solve a theoretical issue >> that's never been observed. > > Even something that happens once per process lifetime, like in fork/exit > 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 for 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. 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 disk I/O to complete. It doesn't get much worse than that for latency. Cheers, Jeff