Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp1335712imu; Wed, 23 Jan 2019 15:13:31 -0800 (PST) X-Google-Smtp-Source: ALg8bN47h6eMMTGvQWf7yy8oLCWxsqQaeo4A0XDHUtTXe37oD4u96Ohn5pDYT9VpPUECpZGt5jTx X-Received: by 2002:a65:62da:: with SMTP id m26mr3806901pgv.278.1548285210990; Wed, 23 Jan 2019 15:13:30 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1548285210; cv=none; d=google.com; s=arc-20160816; b=tHu/jAWkCchK1QMrSuVwtS4G45kmgOhJBB+rIbWqCUvPRdk7lLzS5Yp7aAEhhD1B7A ul52XER/D3cX77VLqF8ndrvW9jlWGXEm8Zvg+Jsp+9QpRZLV+xLLStjwasG9n9tzWT3Q 8cB1lYhYcDIBDsGmENFByhSZ6NGWQ2d9vLHlXGiQVpi0ICxJDhx+2iJyos3RX5NDQ3Nb OBsJGmiyGzV4Y/QSPTHBSD6mzDNAngArB4fx5j2tyA0HSjFNeCPutSiPCm8KM5OskAgD /wheajxYCdOHcnRGTPVVZ7IqUEewLjZeJg2MoZSaM1FnjlTs6Z7EKkF4zCCauqYXjVw6 qPKg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:user-agent:references :message-id:in-reply-to:subject:cc:to:from:date; bh=T0fX1kgDHDO4Xh4qKeBJ34bpp642Veh5A09kgU+526k=; b=jmvjDzxh/2R1oKd1853dNUgCs0twTY771asy1U85+ujeu031ul7ugmhtnZiPpODx8l tuTMG520rgdl2YDAJiPguMmUXxe2pXNWFRGkXzr4DQPUTXHD21rdaaCJbZ18q4ZeLChE HcWce/Ya+4CQJn8gdx//EQKQiEqIZuZeLTab0s2XEjSB3eG9YLOq02VPS5a7SgNqUS+h ZdrU7Y+/wUgTvLjRncStcJTiHkr+QggDP2qI4QYAHhVVtdy5t1ecK5FG/y61zufUg8GS qs+zApu11e/OMANcmJXXi/qIF2ig4737WyeO5IdyQpbZ7Y0bIXedy3m6jQ3/wi6tTzxx g3ew== 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id c30si19824581pgn.52.2019.01.23.15.13.15; Wed, 23 Jan 2019 15:13:30 -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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726183AbfAWXMv (ORCPT + 99 others); Wed, 23 Jan 2019 18:12:51 -0500 Received: from mx2.suse.de ([195.135.220.15]:53524 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726220AbfAWXMu (ORCPT ); Wed, 23 Jan 2019 18:12:50 -0500 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id 1E373AF26; Wed, 23 Jan 2019 23:12:49 +0000 (UTC) Date: Thu, 24 Jan 2019 00:12:47 +0100 (CET) From: Jiri Kosina To: Linus Torvalds cc: Dominique Martinet , Andy Lutomirski , Josh Snyder , Dave Chinner , 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 In-Reply-To: Message-ID: References: <20190110004424.GH27534@dastard> <20190110070355.GJ27534@dastard> <20190110122442.GA21216@nautica> <5c3e7de6.1c69fb81.4aebb.3fec@mx.google.com> <9E337EA6-7CDA-457B-96C6-E91F83742587@amacapital.net> <20190116054613.GA11670@nautica> User-Agent: Alpine 2.21 (LSU 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 24 Jan 2019, Linus Torvalds wrote: > Side note: the inode_permission() addition to can_do_mincore() in that > patch 0002, seems to be questionable. We do > > +static inline bool can_do_mincore(struct vm_area_struct *vma) > +{ > + return vma_is_anonymous(vma) > + || (vma->vm_file && (vma->vm_file->f_mode & FMODE_WRITE)) > + || inode_permission(file_inode(vma->vm_file), MAY_WRITE) == 0; > +} > > note how it tests whether vma->vm_file is NULL for the FMODE_WRITE > test, but not for the inode_permission() test. > > So either we test unnecessarily in the second line, or we don't > properly test it in the third one. > > I think the "test vm_file" thing may be unnecessary, because a > non-anonymous mapping should always have a file pointer and an inode. > But I could imagine some odd case (vdso mapping, anyone?) that > doesn't have a vm_file, but also isn't anonymous. Hmm, good point. So dropping the 'vma->vm_file' test and checking whether given vma is special mapping should hopefully provide the desired semantics, shouldn't it? -- Jiri Kosina SUSE Labs