Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932963AbcCTBp1 (ORCPT ); Sat, 19 Mar 2016 21:45:27 -0400 Received: from mail-io0-f195.google.com ([209.85.223.195]:33611 "EHLO mail-io0-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932653AbcCTBpU (ORCPT ); Sat, 19 Mar 2016 21:45:20 -0400 MIME-Version: 1.0 In-Reply-To: <20160320012610.GX17997@ZenIV.linux.org.uk> References: <20160115202131.GH6330@kvack.org> <20160120195957.GV6033@dastard> <20160120204449.GC12249@kvack.org> <20160120214546.GX6033@dastard> <20160123043922.GF6033@dastard> <20160314171737.GK17923@kvack.org> <20160320012610.GX17997@ZenIV.linux.org.uk> Date: Sat, 19 Mar 2016 18:45:19 -0700 X-Google-Sender-Auth: Ku4hXdQa6rQUzopZLvhxVzMQgtg Message-ID: Subject: Re: aio openat Re: [PATCH 07/13] aio: enabled thread based async fsync From: Linus Torvalds To: Al Viro Cc: Benjamin LaHaise , Dave Chinner , Andrew Morton , linux-fsdevel , Linux API , Linux Kernel Mailing List , linux-aio@kvack.org, linux-mm Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1509 Lines: 33 On Sat, Mar 19, 2016 at 6:26 PM, Al Viro wrote: > > Umm... You do realize that LOOKUP_RCU in flags does *NOT* guarantee that > it won't block, right? At the very least one would need to refuse to > fall back on non-RCU mode without a full restart. It actually does seem to do that, although in an admittedly rather questionable way. I think it should use path_openat() rather than do_filp_open(), but passing in LOOKUP_RCU to do_filp_open() actually does work: it just means that the retry after ECHILD/ESTALE will just do it *again* with LOOKUP_RCU. It won't fall back to non-rcu mode, it just won't or in the LOOKUP_RCU flag that is already set. So I agree that it should be cleaned up, but the basic model seems fine. I'm sure you're right about do_last() not necessarily being the best place either. But that doesn't really change that the approach seems *much* better than the old unconditional "do in a work queue". Also, the whole "no guarantees of never blocking" is a specious argument. Just copying the iocb from user space can block. Copying the pathname likewise (or copying the iovec in the case of reads and writes). So the aio interface at no point is "guaranteed to never block". Blocking will happen. You can block on allocating the "struct file", or on extending the filp table. In the end it's about _performance_, and if the performance is better with very unlikely blocking synchronous calls, then that's the right thing to do. Linus