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.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED 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 3A7A2C433DB for ; Mon, 11 Jan 2021 19:26:40 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 0C1A122C7E for ; Mon, 11 Jan 2021 19:26:40 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2391114AbhAKT0j (ORCPT ); Mon, 11 Jan 2021 14:26:39 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45250 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2391030AbhAKT0i (ORCPT ); Mon, 11 Jan 2021 14:26:38 -0500 Received: from mail-lf1-x12b.google.com (mail-lf1-x12b.google.com [IPv6:2a00:1450:4864:20::12b]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 2D340C061786 for ; Mon, 11 Jan 2021 11:25:58 -0800 (PST) Received: by mail-lf1-x12b.google.com with SMTP id u25so1236995lfc.2 for ; Mon, 11 Jan 2021 11:25:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=oKNFHHPFfD7wrwfuT7r81/lh6WrZWqpMnLmKMYRybYs=; b=T4dW7LSW7T2wg9bacwMkeXXtLd4Ok0sO57tNlnjcAH8Ux7LmYSjZ0lozL/qlAFcVMW /X7YR78gi7Ax/0lk70yZx3V9MQaMI7jS/gAfWwdp4tXVRSg+DjhZ8vv5aWsRaxJuwJRC ABafPi7lpmnzPtXbWxsMbYU5IEhVTnlyC3SEM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=oKNFHHPFfD7wrwfuT7r81/lh6WrZWqpMnLmKMYRybYs=; b=YKRvL/IyVpQWh8Y//CbgmetY5UshaXlVJD0MpqTHOtlqqxRkHSW6FC3L91tr7dlyo0 seasneBLxnWoDR+N2KUxSAersK1OUyUZAtRUbtulfJs/6I1GR8LBxy5nltse9rZE5QKT RstH6rwMrNcErDOu2X+O8k1ZWcvMdGG6jgCo2fSQ9AGUvrHxZh4Zo6JdnEA+rIh/3D4o V1oHyZM1HG42z923xTdtss2BBeru68caEovN1WSAc0R1Bv3vy251C7UvFip5dGsmLzYQ U1bU87yfW+zIlsdDX8/xiC6OnyKRU740p40jxu/LdpQliUvwBT/bAPKg5eST6lAt7Udc rmKA== X-Gm-Message-State: AOAM5324YWFgiAiDuRo7x4gX0xG6Houdgk4/2I8pBaELwVolfjWUWpqg nVJmUnAPu4c9moea5gOOb44l0BbOJyIerw== X-Google-Smtp-Source: ABdhPJxlMUpXZilwq+VegR8U7oceCgdDRyRJCtuueQh5aMeSEcvjZiHA+ADYkEsH/eLwqUzuDW9UmA== X-Received: by 2002:a19:4c06:: with SMTP id z6mr502730lfa.284.1610393156097; Mon, 11 Jan 2021 11:25:56 -0800 (PST) Received: from mail-lj1-f180.google.com (mail-lj1-f180.google.com. [209.85.208.180]) by smtp.gmail.com with ESMTPSA id x18sm87255lfe.36.2021.01.11.11.25.54 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 11 Jan 2021 11:25:54 -0800 (PST) Received: by mail-lj1-f180.google.com with SMTP id w26so165754ljo.4 for ; Mon, 11 Jan 2021 11:25:54 -0800 (PST) X-Received: by 2002:a2e:9b13:: with SMTP id u19mr420017lji.48.1610393153712; Mon, 11 Jan 2021 11:25:53 -0800 (PST) MIME-Version: 1.0 References: <20210108171517.5290-1-will@kernel.org> <20210111142402.6euyktmcnpemanf7@box> In-Reply-To: <20210111142402.6euyktmcnpemanf7@box> From: Linus Torvalds Date: Mon, 11 Jan 2021 11:25:37 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v2 0/3] Create 'old' ptes for faultaround mappings on arm64 with hardware access flag To: "Kirill A. Shutemov" Cc: Will Deacon , 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 Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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). Linus 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.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED 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 9B000C433E0 for ; Mon, 11 Jan 2021 19:25:59 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 090D922CA1 for ; Mon, 11 Jan 2021 19:25:58 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 090D922CA1 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=linux-foundation.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 5303B6B01F5; Mon, 11 Jan 2021 14:25:58 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 4E0186B01F7; Mon, 11 Jan 2021 14:25:58 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3F6626B01F8; Mon, 11 Jan 2021 14:25:58 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0161.hostedemail.com [216.40.44.161]) by kanga.kvack.org (Postfix) with ESMTP id 293426B01F5 for ; Mon, 11 Jan 2021 14:25:58 -0500 (EST) Received: from smtpin08.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id E895E181AEF00 for ; Mon, 11 Jan 2021 19:25:57 +0000 (UTC) X-FDA: 77694474354.08.bead70_070dc882750f Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin08.hostedemail.com (Postfix) with ESMTP id C15301819E766 for ; Mon, 11 Jan 2021 19:25:57 +0000 (UTC) X-HE-Tag: bead70_070dc882750f X-Filterd-Recvd-Size: 4712 Received: from mail-lf1-f52.google.com (mail-lf1-f52.google.com [209.85.167.52]) by imf17.hostedemail.com (Postfix) with ESMTP for ; Mon, 11 Jan 2021 19:25:57 +0000 (UTC) Received: by mail-lf1-f52.google.com with SMTP id v67so1259761lfa.0 for ; Mon, 11 Jan 2021 11:25:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=oKNFHHPFfD7wrwfuT7r81/lh6WrZWqpMnLmKMYRybYs=; b=T4dW7LSW7T2wg9bacwMkeXXtLd4Ok0sO57tNlnjcAH8Ux7LmYSjZ0lozL/qlAFcVMW /X7YR78gi7Ax/0lk70yZx3V9MQaMI7jS/gAfWwdp4tXVRSg+DjhZ8vv5aWsRaxJuwJRC ABafPi7lpmnzPtXbWxsMbYU5IEhVTnlyC3SEM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=oKNFHHPFfD7wrwfuT7r81/lh6WrZWqpMnLmKMYRybYs=; b=Q2Oc13u8KY5GU/tzSkbwc5PiAtDTuIB9bdx38iPpPPeUQVm6JixRUh7jJS5f4vJZtA hBIkkfztxOo65pleHwgajoBzeZ7J0KmPF53dQ1z07gMbbZa8wyl1KGWrtNuFO9a1zB69 ys8pHjjyheJy3HjaVqSw1To9d1AyiUrQRwXh8sutl+8tc0XedhK8xRLqOppnw5TPquab 4PCeodLoCus61vBmmgsLwBw2G2TObiLsj4xGF6b30cB4pe0cGn3MDIIYWIxcFNPeeyvh JdzzPcC2SnqRjPb5aFIYO0HRe619DdlQC9NkpP5C7RKxYRb6bRXK0LzbxFhcOLBJ45Zp uYjw== X-Gm-Message-State: AOAM530UkA9XwdnAByvcnDkjYItSS9yhw06xh+KGGl82e5IyaV9X6WvU SX9VrexJd2aox9XBVkIBMEgQbe6wos1hOg== X-Google-Smtp-Source: ABdhPJz8dlKFhmMDd/6DrfqvSl2AfZ0lDBZfLcVHb+0qYrc7VgrDt1Tz/LsoNWKJmASHYXrnKj3mWQ== X-Received: by 2002:a19:8213:: with SMTP id e19mr462029lfd.600.1610393155545; Mon, 11 Jan 2021 11:25:55 -0800 (PST) Received: from mail-lj1-f177.google.com (mail-lj1-f177.google.com. [209.85.208.177]) by smtp.gmail.com with ESMTPSA id o19sm84850lfd.250.2021.01.11.11.25.54 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 11 Jan 2021 11:25:54 -0800 (PST) Received: by mail-lj1-f177.google.com with SMTP id m10so182978lji.1 for ; Mon, 11 Jan 2021 11:25:54 -0800 (PST) X-Received: by 2002:a2e:9b13:: with SMTP id u19mr420017lji.48.1610393153712; Mon, 11 Jan 2021 11:25:53 -0800 (PST) MIME-Version: 1.0 References: <20210108171517.5290-1-will@kernel.org> <20210111142402.6euyktmcnpemanf7@box> In-Reply-To: <20210111142402.6euyktmcnpemanf7@box> From: Linus Torvalds Date: Mon, 11 Jan 2021 11:25:37 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v2 0/3] Create 'old' ptes for faultaround mappings on arm64 with hardware access flag To: "Kirill A. Shutemov" Cc: Will Deacon , 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 Content-Type: text/plain; charset="UTF-8" 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 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). Linus 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=-4.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED 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 08341C433DB for ; Mon, 11 Jan 2021 19:27:41 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 8E2EE22CAD for ; Mon, 11 Jan 2021 19:27:40 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 8E2EE22CAD Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=linux-foundation.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:To:Subject:Message-ID:Date:From:In-Reply-To: References:MIME-Version:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=clz2xrEz30fYBi4BBKb5rz/7mfyuLJjsksT/evVQRWI=; b=TXt6StW3HW0WGe41UuQGORa4O 9biW8xeQRDaXqMH6nhxbHamQ5MdTYyLMLrWAz9ZEO564u6KdAEUS23cBH5eto0zODjM3SpVNvOvNy +jnXIDMb8nHnYL56GeVg6US84rWGRReYCK9P87kGgdfuOjVRbpk/rj2vuwhEyPWo7VcyCy2f3L6/a Pf0oX2Yjl2ePupwZFZe3Npt7QNIEur9MM7ASE82fuQSxjZl6tQE5spqRZNdsvh5JwHugIneye+evU j0SUHEeFEQTteALwORRYLKg+Wd8D+kU7JFLtN0Csnldu6jipeWmeDOSx/kbS6S8sIX5uwllSlX2SC M9h62F/DA==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kz2pI-0000eZ-Ba; Mon, 11 Jan 2021 19:26:04 +0000 Received: from mail-lf1-x133.google.com ([2a00:1450:4864:20::133]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kz2pC-0000cg-Ml for linux-arm-kernel@lists.infradead.org; Mon, 11 Jan 2021 19:25:59 +0000 Received: by mail-lf1-x133.google.com with SMTP id o13so1230656lfr.3 for ; Mon, 11 Jan 2021 11:25:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=oKNFHHPFfD7wrwfuT7r81/lh6WrZWqpMnLmKMYRybYs=; b=T4dW7LSW7T2wg9bacwMkeXXtLd4Ok0sO57tNlnjcAH8Ux7LmYSjZ0lozL/qlAFcVMW /X7YR78gi7Ax/0lk70yZx3V9MQaMI7jS/gAfWwdp4tXVRSg+DjhZ8vv5aWsRaxJuwJRC ABafPi7lpmnzPtXbWxsMbYU5IEhVTnlyC3SEM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=oKNFHHPFfD7wrwfuT7r81/lh6WrZWqpMnLmKMYRybYs=; b=KI2eVetJGAGiD/8/C8ABzhFxNarLDrkJguU7Fz3Z6zstYWX5pUeRqyL6Sp6OBQeMDl Muml/PUR9CBSkstdhypmWlEh5PlYUzOU8O4FtWSUTW6xkXKK9jk8QWynDYuv/CNa0RD2 QFIA4nKkeOdTABYAvooF4UodJ5pAKuGF+vn83t5CP/IhSb/59a4BORD2AY3bgTBKblsB tVP3G9Pk47+vHHrb5Z7bxjfr4O8XlO+G6T7WdSDHaAeENOYyMJwQrspV50tHrBBaWK1g ttlULi4yS9ovtvbEK1ADbTQ3adC5mP3Z5lEbQsFA6y8eesrj2mIWTGpzNVT88Q8t5Ai8 qNog== X-Gm-Message-State: AOAM532U/1F4uxRC7zF8X+znyiZ2In0Hq2R6Nx1EHko24+7lBJA9awVy iZTLdtOiXYxLJFpahZtiy7S01omn9NIRfg== X-Google-Smtp-Source: ABdhPJy8RaOWbqgqW6hnrCpgFpuDXtw7isoVhnW9tiFzY+P12qonz1+4+Eh2Z72lVbkEkhbnitjW3Q== X-Received: by 2002:a19:2256:: with SMTP id i83mr492082lfi.602.1610393155621; Mon, 11 Jan 2021 11:25:55 -0800 (PST) Received: from mail-lj1-f172.google.com (mail-lj1-f172.google.com. [209.85.208.172]) by smtp.gmail.com with ESMTPSA id u6sm85660lfk.127.2021.01.11.11.25.54 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 11 Jan 2021 11:25:54 -0800 (PST) Received: by mail-lj1-f172.google.com with SMTP id b10so150672ljp.6 for ; Mon, 11 Jan 2021 11:25:54 -0800 (PST) X-Received: by 2002:a2e:9b13:: with SMTP id u19mr420017lji.48.1610393153712; Mon, 11 Jan 2021 11:25:53 -0800 (PST) MIME-Version: 1.0 References: <20210108171517.5290-1-will@kernel.org> <20210111142402.6euyktmcnpemanf7@box> In-Reply-To: <20210111142402.6euyktmcnpemanf7@box> From: Linus Torvalds Date: Mon, 11 Jan 2021 11:25:37 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v2 0/3] Create 'old' ptes for faultaround mappings on arm64 with hardware access flag To: "Kirill A. Shutemov" X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210111_142558_787513_2A72994D X-CRM114-Status: GOOD ( 15.09 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Android Kernel Team , Jan Kara , Minchan Kim , Catalin Marinas , Hugh Dickins , Linux Kernel Mailing List , Linux-MM , Vinayak Menon , "Kirill A . Shutemov" , Andrew Morton , Will Deacon , Linux ARM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org 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). Linus _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel