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=-5.2 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_1 autolearn=no 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 4DB28C4742C for ; Mon, 16 Nov 2020 10:10:06 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 9CC3A2227F for ; Mon, 16 Nov 2020 10:10:05 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 9CC3A2227F Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=techsingularity.net Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id A7D696B005D; Mon, 16 Nov 2020 05:10:04 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id A06EC6B0068; Mon, 16 Nov 2020 05:10:04 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8CEC36B006C; Mon, 16 Nov 2020 05:10:04 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0210.hostedemail.com [216.40.44.210]) by kanga.kvack.org (Postfix) with ESMTP id 5BE4A6B005D for ; Mon, 16 Nov 2020 05:10:04 -0500 (EST) Received: from smtpin03.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id E95FC181AC9CB for ; Mon, 16 Nov 2020 10:10:03 +0000 (UTC) X-FDA: 77489860686.03.light46_550403527328 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin03.hostedemail.com (Postfix) with ESMTP id B206328A4EA for ; Mon, 16 Nov 2020 10:10:03 +0000 (UTC) X-HE-Tag: light46_550403527328 X-Filterd-Recvd-Size: 3763 Received: from outbound-smtp25.blacknight.com (outbound-smtp25.blacknight.com [81.17.249.193]) by imf02.hostedemail.com (Postfix) with ESMTP for ; Mon, 16 Nov 2020 10:10:02 +0000 (UTC) Received: from mail.blacknight.com (pemlinmail02.blacknight.ie [81.17.254.11]) by outbound-smtp25.blacknight.com (Postfix) with ESMTPS id 62EDDCAE5E for ; Mon, 16 Nov 2020 10:10:01 +0000 (GMT) Received: (qmail 19025 invoked from network); 16 Nov 2020 10:10:01 -0000 Received: from unknown (HELO techsingularity.net) (mgorman@techsingularity.net@[84.203.22.4]) by 81.17.254.9 with ESMTPSA (AES256-SHA encrypted, authenticated); 16 Nov 2020 10:10:00 -0000 Date: Mon, 16 Nov 2020 10:09:57 +0000 From: Mel Gorman To: Dave Hansen Cc: Matthew Wilcox , Jarkko Sakkinen , x86@kernel.org, linux-sgx@vger.kernel.org, linux-kernel@vger.kernel.org, Sean Christopherson , linux-mm@kvack.org, Andrew Morton , Jethro Beekman , andriy.shevchenko@linux.intel.com, asapek@google.com, bp@alien8.de, cedric.xing@intel.com, chenalexchen@google.com, conradparker@google.com, cyhanish@google.com, haitao.huang@intel.com, kai.huang@intel.com, kai.svahn@intel.com, kmoy@google.com, ludloff@google.com, luto@kernel.org, nhorman@redhat.com, npmccallum@redhat.com, puiterwijk@redhat.com, rientjes@google.com, tglx@linutronix.de, yaozhangx@google.com, mikko.ylinen@intel.com Subject: Re: [PATCH v41 10/24] mm: Add 'mprotect' hook to struct vm_operations_struct Message-ID: <20201116100957.GM3371@techsingularity.net> References: <20201112220135.165028-1-jarkko@kernel.org> <20201112220135.165028-11-jarkko@kernel.org> <20201115173208.GR17076@casper.infradead.org> <96318679-3320-8d7c-d178-7fa34ed11fdf@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline In-Reply-To: <96318679-3320-8d7c-d178-7fa34ed11fdf@intel.com> User-Agent: Mutt/1.10.1 (2018-07-13) X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Sun, Nov 15, 2020 at 10:36:51AM -0800, Dave Hansen wrote: > On 11/15/20 9:32 AM, Matthew Wilcox wrote: > > On Fri, Nov 13, 2020 at 12:01:21AM +0200, Jarkko Sakkinen wrote: > >> +++ b/include/linux/mm.h > >> @@ -559,6 +559,13 @@ struct vm_operations_struct { > >> void (*close)(struct vm_area_struct * area); > >> int (*split)(struct vm_area_struct * area, unsigned long addr); > >> int (*mremap)(struct vm_area_struct * area); > >> + /* > >> + * Called by mprotect() to make driver-specific permission > >> + * checks before mprotect() is finalised. The VMA must not > >> + * be modified. Returns 0 if eprotect() can proceed. > >> + */ > > > > This is the wrong place for this documentation, and it's absurdly > > specific to your implementation. It should be in > > Documentation/filesystems/locking.rst. > > I'll let you and Mel duke that one out: > I suggested placing the comment there to make it clear what the expected semantics of the hook was to reduce the chances of abuse or surprises. The hook does not affect locking so Documentation/filesystems/locking.rst didn't appear appropriate other than maybe adding a note there that it doesn't affect locks. The hook also is not expecting any filesystems-specific action that I aware of but a note could be added to the effect that filesystems should not need to take special action for it. Protections on the filesystem level are for the inode, I can't imagine what a filesystem would do with a protection change on the page table level but maybe I'm not particularly imaginative today. -- Mel Gorman SUSE Labs