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=-7.8 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,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 A6F97C433E0 for ; Tue, 12 Jan 2021 21:48:08 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 29C5823123 for ; Tue, 12 Jan 2021 21:48:08 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 29C5823123 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 988316B00F0; Tue, 12 Jan 2021 16:48:07 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 95F436B00F2; Tue, 12 Jan 2021 16:48:07 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 875B26B00F3; Tue, 12 Jan 2021 16:48:07 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0246.hostedemail.com [216.40.44.246]) by kanga.kvack.org (Postfix) with ESMTP id 7128B6B00F0 for ; Tue, 12 Jan 2021 16:48:07 -0500 (EST) Received: from smtpin12.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 3810C181AEF23 for ; Tue, 12 Jan 2021 21:48:07 +0000 (UTC) X-FDA: 77698461414.12.jam75_3e0eeee27518 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin12.hostedemail.com (Postfix) with ESMTP id 0DC09180559F1 for ; Tue, 12 Jan 2021 21:48:07 +0000 (UTC) X-HE-Tag: jam75_3e0eeee27518 X-Filterd-Recvd-Size: 3347 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by imf22.hostedemail.com (Postfix) with ESMTP for ; Tue, 12 Jan 2021 21:48:06 +0000 (UTC) Received: by mail.kernel.org (Postfix) with ESMTPSA id 1DBF42313C; Tue, 12 Jan 2021 21:48:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1610488085; bh=xEYKassPQC4sKkuJ/2fsneFhalU4oSuuI5/rscjtbAE=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=icrdld4c54puBOpoMHt9NPZtfqeCBNMviZxMC5FDARPEr9/3jX8GtCDAHsbVBHpxu NB0eNSp/vmkU8PDKa4tkMDYjcVKZ1NybKKK9bfIEwIJIiS2za7N9YaVVSmYDrDDlKl Yois18ZHdKDcmOpujXX4l9WUOxmdNbrBKSD6TfGqSV1mPuvHMkcTINIjtHNqoONxyM zuzGwkrXpGMDjaJBy0XEDfW1GDs79rD4pH7Ygps03ur03fsPjSDRytFmzWpewqdLfc LPbbVt2UQuN3vyhC2nzEH5hQ++y4Eq05d5Ct6komeN41vBqMsNO5W/unjq7rLSzA5W o7W9L+GLIS6VQ== Date: Tue, 12 Jan 2021 21:47:59 +0000 From: Will Deacon To: Linus Torvalds Cc: "Kirill A. Shutemov" , Linux Kernel Mailing List , Linux-MM , Linux ARM , Catalin Marinas , Jan Kara , Minchan Kim , Andrew Morton , "Kirill A . Shutemov" , Vinayak Menon , Hugh Dickins , Android Kernel Team Subject: Re: [PATCH v2 0/3] Create 'old' ptes for faultaround mappings on arm64 with hardware access flag Message-ID: <20210112214759.GC10434@willie-the-truck> References: <20210108171517.5290-1-will@kernel.org> <20210111142402.6euyktmcnpemanf7@box> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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 Mon, Jan 11, 2021 at 11:25:37AM -0800, Linus Torvalds wrote: > On Mon, Jan 11, 2021 at 6:24 AM Kirill A. Shutemov wrote: > > > > I wonder if it would be acceptable to pass down to faultaround a copy > > of vmf, so it mess with it without risking to corrupt the original one? > > I'd almost prefer to split vmf into two parts: the 'this is the fault > info' part and the 'this is the fault handling state' part. > > So the first one would be filled in by the actual page faulter (or > GUP) - and then be 'const' during the lookup, while the second one > would be set up by handle_mm_fault() and would contain that "this is > the current state of my fault state machine" and contain things like > that ->pte thing. > > And then if somebody actually needs to pass in "modified fault state" > (ie that whole "I'm doing fault-around, so I'll use multiple > addresses") they'd never modify the address in the fault info, they'd > just pass the address as an explicit argument (like most cases already > do - the "change addr or flags in vmf" is actually already _fairly_ > rare). Alright then, I'll take another crack at this for v3 and see how far I get. Will