Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp3477844imu; Fri, 18 Jan 2019 11:04:17 -0800 (PST) X-Google-Smtp-Source: ALg8bN7o7FF6lfnbWvoyMXnYkVRL/7uYnnNmmHz3uTpZIKHG8ox9i+kMo9BQcaqYpDevJRLBA5G/ X-Received: by 2002:a62:d206:: with SMTP id c6mr19228586pfg.245.1547838257125; Fri, 18 Jan 2019 11:04:17 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1547838257; cv=none; d=google.com; s=arc-20160816; b=LitTD8yCVwwhi0gFZVuCPY4YDuQaBmgwIqcm8Eti2cqVi497jwSCA7eTIONC/D516m ogy7cvCVWG76Vb0/IiHaa2lNEjrud1dTTNKEaaxVWbFK7NJVbMG+lJtNs67+A9tPZ31r +0o5YIsHLvKVo5QoYEq4DGVJ+t0wWiMi+ri7id2/rIzR0YpzNPhrHd1fypHcimIOFggS oNQsGjIhesONlMJISDcX5rfBSJ3J8VIRJApTwKW8TFpyaPj4+cpM0gyut1Bf5skTiCnQ 3nAY+wTmBXXcCrC7b+g/Dr1l9DSzNjGDd0rfRxHgruHidLQlF5WQ288WrEBhvJbK9USP loXw== 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:openpgp:from:references:cc:to:subject; bh=/Urv1SBwd5YzkeFBP2mDt6v9YcBNqAp+perU/XsaATM=; b=yhAdlfedD6E4/YhYdoSyeArHaUTSUhRCua8mkmfj/FGWHDNQg235e3ieoypNZuJb0S haAaDVH8Yk6cS1S6bLdOHnK3ezw59zba08AjpvesEjrPcSa9szeQIXE74p3MXIZVAh20 2THmzXTNRJK4HAhCB1vxYou1ufhBHfXgyduogXZ+i9m70LgMMpM9+KhAEjl66qw9l/L2 TV7FP3pwQfH5cqBn9PzOpypoS1ARY2CYAetOEUCa9UeGotgfvk25uvDh9maB59XJKm9G dWTH8av9HSEZjl9tf5Gr7ECFz0UlgggeUxUT/JYXE/sqR5Ubm0uXF6dgfQn+0UkfAzh7 PlSA== 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 n67si5427656pfk.34.2019.01.18.11.03.58; Fri, 18 Jan 2019 11:04:17 -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 S1729277AbfARTBV (ORCPT + 99 others); Fri, 18 Jan 2019 14:01:21 -0500 Received: from mx2.suse.de ([195.135.220.15]:49592 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1728583AbfARTBU (ORCPT ); Fri, 18 Jan 2019 14:01:20 -0500 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay1.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id 1BDA3ADAA; Fri, 18 Jan 2019 19:01:19 +0000 (UTC) Subject: Re: [PATCH] mm/mincore: allow for making sys_mincore() privileged To: Linus Torvalds Cc: Josh Snyder , Dominique Martinet , Andy Lutomirski , Dave Chinner , Jiri Kosina , Matthew Wilcox , Jann Horn , Andrew Morton , Greg KH , Peter Zijlstra , Michal Hocko , Linux-MM , kernel list , Linux API References: <20190110070355.GJ27534@dastard> <20190110122442.GA21216@nautica> <5c3e7de6.1c69fb81.4aebb.3fec@mx.google.com> <9E337EA6-7CDA-457B-96C6-E91F83742587@amacapital.net> <20190116054613.GA11670@nautica> <20190116063430.GA22938@nautica> From: Vlastimil Babka Openpgp: preference=signencrypt Message-ID: <362c8696-b308-53b7-2014-261530b4abcb@suse.cz> Date: Fri, 18 Jan 2019 19:58:13 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.3.3 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 1/18/19 5:49 AM, Linus Torvalds wrote: > On Fri, Jan 18, 2019 at 9:45 AM Vlastimil Babka wrote: >> >> Or maybe we could resort to the 5.0-rc1 page table check (that is now being >> reverted) but only in cases when we are not allowed the page cache residency >> check? Or would that be needlessly complicated? > > I think it would be good fallback semantics, but I'm not sure it's > worth it. Have you tried writing a patch for it? I don't think you'd > want to do the check *when* you find a hole, so you'd have to do it > upfront and then pass the cached data down with the private pointer > (or have a separate "struct mm_walk" structure, perhaps? > > So I suspect we're better off with the patch we have. But if somebody > *wants* to try to do that fancier patch, and it doesn't look > horrendous, I think it might be the "quality" solution. I thought to drop the idea because of leaking that page has been evicted, but then I realized there are other ways to check for that anyway in /proc. So I'll try, but probably not until after next week. If somebody else wants to, they are welcome. As you say, the current solution should be ok, so that would be a patch on top anyway, for bisectability etc. Vlastimil > Linus >