Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp135910imu; Thu, 10 Jan 2019 20:06:06 -0800 (PST) X-Google-Smtp-Source: ALg8bN7x0CruTZSmEm5P8Uad6jJKe6RsC7FXGKiP3a1lodW1iy6oXStsMBfDIgfpfXShfmGgP/tn X-Received: by 2002:a17:902:bd0a:: with SMTP id p10mr12687252pls.322.1547179566676; Thu, 10 Jan 2019 20:06:06 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1547179566; cv=none; d=google.com; s=arc-20160816; b=IvpGp4XKh12Ts8jVjJcuK5zH9QaJvOgzk+eErZ8OVBjLR+1dkVesd8kjcERYLTskyn Qi1DrBnyDlQa2B9/y5bmpvUCXz/PuWota0I6TEhwDRppEPJn/jINFSr+ozo9EVVfPHkV EMxwfmomTxRQqVq2a5HE8+oDrjgvKT2TVeCY0kt/ns7/e7zQqFV1EHSMtnvEF8vT4imk HCgK3Ziza5K8gBJYaQDorhns/BfIXJuH70kDC2cnhlV49nBaNNRyhfQERVty/kH1cR1s T4kutyOMysOc9ZeI7gxPjBNvaiE+3OYSvzHSYyIE0GCxHcGuSlhcYfehG6n88eMwuq3I 35VQ== 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=EurWhxkT5mwt0vRL4bch38Ln+rz6StTicmuxYIa45xo=; b=ByWRfYd64XJHy37KghPMfQcZJ/FopGuQqFcw9oKU8QrpGp2FXsNqYDFiDw2nM/qG21 1n3DBTsamKAHtqcIGLhELO8vmaCsE2F9MgAC+tUpJmH26xMcqwrio0Oso26eLhBuzR1f 76O+ZUpBR5AiCk3EXgLT3EX/cw9I8rDiK8pwfoxXpRtyS99ztzr4VsgHYpBP3LIwDqb5 5pY/YrxiIty9W/OOYpvkMvjjvzMRP5hljYFTa24ms1o990IowdtMifh5Qx2O2n+ZKbtU Wma0K2/qVbln5rYms88J86fmWx27YuEvaMf1TTB6QESVPNCxLhp3yC0TIQ+JnFV50esu SgDA== 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 n15si4723158pgk.27.2019.01.10.20.05.50; Thu, 10 Jan 2019 20:06:06 -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 S1729534AbfAKCDp (ORCPT + 99 others); Thu, 10 Jan 2019 21:03:45 -0500 Received: from ipmail03.adl2.internode.on.net ([150.101.137.141]:19048 "EHLO ipmail03.adl2.internode.on.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728950AbfAKCDp (ORCPT ); Thu, 10 Jan 2019 21:03:45 -0500 Received: from ppp59-167-129-252.static.internode.on.net (HELO dastard) ([59.167.129.252]) by ipmail03.adl2.internode.on.net with ESMTP; 11 Jan 2019 12:33:42 +1030 Received: from dave by dastard with local (Exim 4.80) (envelope-from ) id 1ghmAe-0003LN-CP; Fri, 11 Jan 2019 13:03:40 +1100 Date: Fri, 11 Jan 2019 13:03:40 +1100 From: Dave Chinner To: Linus Torvalds Cc: Dominique Martinet , Jiri Kosina , Matthew Wilcox , Jann Horn , Andrew Morton , Greg KH , Peter Zijlstra , Michal Hocko , Linux-MM , kernel list , Linux API Subject: Re: [PATCH] mm/mincore: allow for making sys_mincore() privileged Message-ID: <20190111020340.GM27534@dastard> References: <20190109022430.GE27534@dastard> <20190109043906.GF27534@dastard> <20190110004424.GH27534@dastard> <20190110070355.GJ27534@dastard> <20190110122442.GA21216@nautica> 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 10, 2019 at 02:11:01PM -0800, Linus Torvalds wrote: > And we *can* do sane things about RWF_NOWAIT. For example, we could > start async IO on RWF_NOWAIT, and suddenly it would go from "probe the > page cache" to "probe and fill", and be much harder to use as an > attack vector.. We can only do that if the application submits the read via AIO and has an async IO completion reporting mechanism. Otherwise we have to wait for the IO to complete to copy the data into the user's buffer. And given that the app is using RWF_NOWAIT to explicitly avoid blocking on the IO.... Also, keep in mind that RWF_NOWAIT also prevents blocking on filesystem locks and full request queues. One of the prime drivers of RWF_NOWAIT was to prevent AIO submission from blocking on filesystem locks - it allows userspace to submit other IO while it can't get all the access it requires to a single file or a single block device is congested. Hence I don't think there's a such a simple answer here - blocking for IO breaks RWF_NOWAIT. Cheers, Dave. -- Dave Chinner david@fromorbit.com