From mboxrd@z Thu Jan 1 00:00:00 1970 From: Kevin Easton Subject: Re: [PATCH] mm/mincore: allow for making sys_mincore() privileged Date: Wed, 16 Jan 2019 12:18:11 +0000 Message-ID: <20190116121811.GA6971@ip-172-31-15-78> References: <20190110122442.GA21216@nautica> <5c3e7de6.1c69fb81.4aebb.3fec@mx.google.com> <9E337EA6-7CDA-457B-96C6-E91F83742587@amacapital.net> <20190116054613.GA11670@nautica> <20190116063430.GA22938@nautica> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org To: Josh Snyder Cc: Dominique Martinet , Linus Torvalds , Andy Lutomirski , Dave Chinner , Jiri Kosina , Matthew Wilcox , Jann Horn , Andrew Morton , Greg KH , Peter Zijlstra , Michal Hocko , Linux-MM , kernel list , Linux API List-Id: linux-api@vger.kernel.org On Tue, Jan 15, 2019 at 11:52:25PM -0800, Josh Snyder wrote: > On Tue, Jan 15, 2019 at 10:34 PM Dominique Martinet > wrote: > > > > There is a difference with your previous patch though, that used to list no > > page in core when it didn't know; this patch lists pages as in core when it > > refuses to tell. I don't think that's very important, though. > > Is there a reason not to return -EPERM in this case? When I was looking through the Debian Code Search results, quite a few of the hits were for code that uses mincore() as a way to check if _anything_ is mapped at an address or not. This code doesn't care about the in core / not in core result of mincore(), just whether it returned an error or not. I think a new error return would break most of the instances of that code I saw. - Kevin