Received: by 2002:ac0:8c9a:0:0:0:0:0 with SMTP id r26csp491531ima; Thu, 31 Jan 2019 21:28:27 -0800 (PST) X-Google-Smtp-Source: AHgI3IYwuUCx79nNug7K8cbolQcyyLr1S52JhEMkm7BsPPKwzuKVhZZ/UfK74vgQdCiF2QLrRYY/ X-Received: by 2002:a63:9f19:: with SMTP id g25mr939235pge.327.1548998907368; Thu, 31 Jan 2019 21:28:27 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1548998907; cv=none; d=google.com; s=arc-20160816; b=xtj1uQjuHMqvJ3dAOioR2LPrQotAFwhquKfhuKqcHVKak1d798yFH+VoN3Wt7NuPrt H2PHOE3NYVpn/1OXfXU1IJNwnvpbD3bzi7oQvxfuPEq0GDOp5EHq99gh/KdjQawqPw4d u5JnwhC78KAooAHs38Zk8MDaJQArve0PBcbRgo3BPEzJfpDeQQWD1CSzkVo6ETzqFemY wOo9kRReWmCFs6oTyB6Z5kuUUqGdwIBB3/nUbRXnK3rLpcs37b6EYDDgPBxFZlUis51n zcXUZdh51GXrOBVnNlKBsonocAIvbbRpdtrQvd1p7lDebKdbg9VWTTrfMoigyTW8PlN1 dmBw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=1xNzf00S/LzGkQOCjoDX4XDIJZBX+cOUOINvlfibkX8=; b=aKP5/rU+MKMajy9WMPBOGtnF7vl3HJ0cQop4ZJqgzrSPyQLNbn5Fd1NMHKfOrT6grs MJHJe1CbHy980mmF7dBFXC63to3P34jbdPU02L45xkTGBEqOqD2lh11bxblvjQBSuIiL JQIRGZA5gwxLM679sdDrOlpZG04FONkvyT7BdJkRPukWzikYh5h0PppaXtB22uSk/smT Fl8A4Fc7EsfIZ5a/QV2Iuuf3ARmOCxO8+aWkvpPPkO3CYYpAQ9YZ21AEgc+sMaiRrCjg KUDHPJ6lvynkM0rq4hbhLjgImjXnC0Ims4eHb7WMw2eoIqYwTtQ3Nku9RrLYJndESyIr fvWA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id m20si5754128pgk.323.2019.01.31.21.28.10; Thu, 31 Jan 2019 21:28:27 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726613AbfBAFQR (ORCPT + 99 others); Fri, 1 Feb 2019 00:16:17 -0500 Received: from ipmail02.adl2.internode.on.net ([150.101.137.139]:52015 "EHLO ipmail02.adl2.internode.on.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725957AbfBAFQR (ORCPT ); Fri, 1 Feb 2019 00:16:17 -0500 Received: from ppp59-167-129-252.static.internode.on.net (HELO dastard) ([59.167.129.252]) by ipmail02.adl2.internode.on.net with ESMTP; 01 Feb 2019 15:43:56 +1030 Received: from dave by dastard with local (Exim 4.80) (envelope-from ) id 1gpR9H-0003ex-Rm; Fri, 01 Feb 2019 16:13:55 +1100 Date: Fri, 1 Feb 2019 16:13:55 +1100 From: Dave Chinner To: Linus Torvalds Cc: Michal Hocko , Jiri Kosina , Vlastimil Babka , Andrew Morton , Linux List Kernel Mailing , Linux-MM , Linux API , Peter Zijlstra , Greg KH , Jann Horn , Dominique Martinet , Andy Lutomirski , Kevin Easton , Matthew Wilcox , Cyril Hrubis , Tejun Heo , "Kirill A . Shutemov" , Daniel Gruss , linux-fsdevel Subject: Re: [PATCH 2/3] mm/filemap: initiate readahead even if IOCB_NOWAIT is set for the I/O Message-ID: <20190201051355.GV6173@dastard> References: <20190130124420.1834-1-vbabka@suse.cz> <20190130124420.1834-3-vbabka@suse.cz> <20190131095644.GR18811@dhcp22.suse.cz> <20190131102348.GT18811@dhcp22.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Jan 31, 2019 at 09:54:16AM -0800, Linus Torvalds wrote: > On Thu, Jan 31, 2019 at 2:23 AM Michal Hocko wrote: > > > > OK, I guess my question was not precise. What does prevent taking fs > > locks down the path? > > IOCB_NOWAIT has never meant that, and will never mean it. I think you're wrong, Linus. IOCB_NOWAIT was specifically designed to prevent blocking on filesystem locks during AIO submission. The initial commits spell that out pretty clearly: commit b745fafaf70c0a98a2e1e7ac8cb14542889ceb0e Author: Goldwyn Rodrigues Date: Tue Jun 20 07:05:43 2017 -0500 fs: Introduce RWF_NOWAIT and FMODE_AIO_NOWAIT RWF_NOWAIT informs kernel to bail out if an AIO request will block for reasons such as file allocations, or a writeback triggered, or would block while allocating requests while performing direct I/O. RWF_NOWAIT is translated to IOCB_NOWAIT for iocb->ki_flags. FMODE_AIO_NOWAIT is a flag which identifies the file opened is capable of returning -EAGAIN if the AIO call will block. This must be set by supporting filesystems in the ->open() call. Filesystems xfs, btrfs and ext4 would be supported in the following patches. Reviewed-by: Christoph Hellwig Reviewed-by: Jan Kara Signed-off-by: Goldwyn Rodrigues Signed-off-by: Jens Axboe commit 29a5d29ec181ebdc98a26cedbd76ce9870248892 Author: Goldwyn Rodrigues Date: Tue Jun 20 07:05:48 2017 -0500 xfs: nowait aio support If IOCB_NOWAIT is set, bail if the i_rwsem is not lockable immediately. IF IOMAP_NOWAIT is set, return EAGAIN in xfs_file_iomap_begin if it needs allocation either due to file extension, writing to a hole, or COW or waiting for other DIOs to finish. Return -EAGAIN if we don't have extent list in memory. Signed-off-by: Goldwyn Rodrigues Reviewed-by: Christoph Hellwig Reviewed-by: Darrick J. Wong Signed-off-by: Jens Axboe commit 728fbc0e10b7f3ce2ee043b32e3453fd5201c055 Author: Goldwyn Rodrigues Date: Tue Jun 20 07:05:47 2017 -0500 ext4: nowait aio support Return EAGAIN if any of the following checks fail for direct I/O: + i_rwsem is lockable + Writing beyond end of file (will trigger allocation) + Blocks are not allocated at the write location Signed-off-by: Goldwyn Rodrigues Reviewed-by: Jan Kara Signed-off-by: Jens Axboe > We will never give user space those kinds of guarantees. We do locking > for various reasons. For example, we'll do the mm lock just when > fetching/storing data from/to user space if there's a page fault. You are conflating "best effort non-blocking operation" with "atomic guarantee". RWF_NOWAIT/IOCB_NOWAIT is the former, not the latter. i.e. RWF_NOWAIT addresses the "every second IO submission blocks" problems that AIO submission suffered from due to filesystem lock contention, not the rare and unusual things like "page fault during get_user_pages in direct IO submission". Maybe one day, but right now those rare cases are not pain points for applications that require nonblock AIO submission via RWF_NOWAIT. > Or - > more obviously - we'll also check for - and sleep on - mandatory locks > in rw_verify_area(). Well, only if you don't use fcntl(O_NONBLOCK) on the file to tell mandatory locking to fail with -EAGAIN instead of sleeping. -Dave. -- Dave Chinner david@fromorbit.com