Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp4512105imu; Tue, 8 Jan 2019 01:17:58 -0800 (PST) X-Google-Smtp-Source: ALg8bN5SZzp/RuCrtw/hmsrkU30HdQEfCJ5tzuXFhDbVx75wyhSuxowV5hOHJYd/wu99E0q+Qczp X-Received: by 2002:a17:902:9305:: with SMTP id bc5mr979952plb.86.1546939078848; Tue, 08 Jan 2019 01:17:58 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1546939078; cv=none; d=google.com; s=arc-20160816; b=mkyBarDzvYT2JWLKBmgSvVsyCfCeDJI4ifXItyLMn7J/G26CG7bRMZaI/Rc9JY//dV pmPC7W3Z0dHuUcoQJkAXGbyTmaAHrN0F5RZNA4TRm/zS3/n9DEw+nFr6q9/hdvtQMgki qHTm24Hr8W1sQ13H6nat8O9Nt3g1QsaWjKjOdIiRDR4/RQ0NwORVYrsVyNgkkkQZYDyK n7utcizYNcFblqH5K5hOh4S7jpSTn9V8es9IaAFbyVtxdiXh/pAMATDXp0bE67qoatU3 +jZiOS3JUJbtM6fnNmhpKj5zMV0tDWTYtIxTedBezMH1g32PZPkyWvjPi6cLljBK/D9H oR6g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject; bh=Z5lPURTnmmSilOTcOK65moJigexVVM4a9bJBqZleFXI=; b=h9UVqtXh6PaWz5DbDe51bIQwkIOzaPoy5ag01+hySsM54CWmGNvT9HQKm1dbLoT+kw 4XVDmnqvUuYu34uGoW1NlH6X+SP4wp26xcU1lcuQZjIPjWrxZZ6ljV77CGINogh8ZQsK TA4+Z5fOTc2b6k3WFtt2CTqEfTi6JCpJlWpcCMGaLN8kRnMSbRkcI+wCOSLxdZ9Rd8yi QGE02RPQ4ZABZ0om1McRluV1vFFpo5w5ZslTrYPMxLVd7hNhEccJkD2kLyb5f6S31wD3 Ofer8b8ulpMhs6qQzc1HaDZxO9U5FEnhezza0d8KZ6nydcjJQWeuK6MitSCDgQL8dKe3 xY6Q== 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 v34si64140338plg.205.2019.01.08.01.17.42; Tue, 08 Jan 2019 01:17:58 -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 S1728110AbfAHJPP (ORCPT + 99 others); Tue, 8 Jan 2019 04:15:15 -0500 Received: from esgaroth.petrovitsch.at ([78.47.184.11]:3660 "EHLO esgaroth.tuxoid.at" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727001AbfAHJPO (ORCPT ); Tue, 8 Jan 2019 04:15:14 -0500 Received: from thorin.petrovitsch.priv.at (80-110-99-3.cgn.dynamic.surfer.at [80.110.99.3]) (authenticated bits=0) by esgaroth.tuxoid.at (8.15.2/8.15.2) with ESMTPSA id x089EWLS008091 (version=TLSv1 cipher=AES128-SHA bits=128 verify=NO); Tue, 8 Jan 2019 10:14:32 +0100 Subject: Re: [PATCH] mm/mincore: allow for making sys_mincore() privileged To: Vlastimil Babka , Jiri Kosina Cc: Linus Torvalds , Andrew Morton , Greg KH , Peter Zijlstra , Michal Hocko , linux-mm@kvack.org, linux-kernel@vger.kernel.org, linux-api@vger.kernel.org References: From: Bernd Petrovitsch Message-ID: <047f0582-a4d3-490d-7284-48dfdf9e9471@petrovitsch.priv.at> Date: Tue, 8 Jan 2019 10:14:23 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-DCC-debian-Metrics: esgaroth.tuxoid.at 1169; Body=10 Fuz1=10 Fuz2=10 X-Virus-Scanned: clamav-milter 0.97 at esgaroth.tuxoid.at X-Virus-Status: Clean X-Spam-Status: No, score=-0.2 required=5.0 tests=AWL,UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Report: * 0.0 UNPARSEABLE_RELAY Informational: message has unparseable relay lines * -0.2 AWL AWL: Adjusted score from AWL reputation of From: address X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on esgaroth.tuxoid.at Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 05/01/2019 20:38, Vlastimil Babka wrote: [...] > I was thinking about "return true" here, assuming that userspace generally wants > to ensure itself there won't be page faults when it starts doing something > critical, and if it sees a "false" it will try to do some kind of prefaulting, > possibly in a loop. There might be somebody trying to make sure something is out Isn't that racy by design as the pages may get flushed out after the check? Shouldn't the application use e.g. mlock()/.... to guarantee no page faults in the first place? MfG, Bernd -- Bernd Petrovitsch Email : bernd@petrovitsch.priv.at LUGA : http://www.luga.at