From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.5 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS,URIBL_BLOCKED,USER_AGENT_MUTT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id A75F4C43444 for ; Fri, 11 Jan 2019 02:03:46 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 80BB520872 for ; Fri, 11 Jan 2019 02:03:46 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729543AbfAKCDp (ORCPT ); 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