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 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 20D57C433E0 for ; Fri, 8 Jan 2021 19:34:30 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id AAC8223A75 for ; Fri, 8 Jan 2021 19:34:29 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org AAC8223A75 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 0F0A98D01A2; Fri, 8 Jan 2021 14:34:29 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 079388D0156; Fri, 8 Jan 2021 14:34:29 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E828A8D01A2; Fri, 8 Jan 2021 14:34:28 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0140.hostedemail.com [216.40.44.140]) by kanga.kvack.org (Postfix) with ESMTP id CBBAF8D0156 for ; Fri, 8 Jan 2021 14:34:28 -0500 (EST) Received: from smtpin27.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 8CDA75003 for ; Fri, 8 Jan 2021 19:34:28 +0000 (UTC) X-FDA: 77683609416.27.cap51_5c15ec5274f5 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin27.hostedemail.com (Postfix) with ESMTP id 69F163D663 for ; Fri, 8 Jan 2021 19:34:28 +0000 (UTC) X-HE-Tag: cap51_5c15ec5274f5 X-Filterd-Recvd-Size: 5243 Received: from mail-lf1-f51.google.com (mail-lf1-f51.google.com [209.85.167.51]) by imf42.hostedemail.com (Postfix) with ESMTP for ; Fri, 8 Jan 2021 19:34:27 +0000 (UTC) Received: by mail-lf1-f51.google.com with SMTP id s26so25554840lfc.8 for ; Fri, 08 Jan 2021 11:34:27 -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=t+MJWRxDTU36V8xE19m5WjjSjbefnbmENuppDaMSAKg=; b=WhBZKnikJ7D+9OF0OeU9baHQ4dnixiMFFXPibHM5X49KiX9Ewm7jxNN5GWUiTkR5xU /Ai8HlPNgCtZp7Y6PHdYR0cKx3eNJ6hyPyLd/NXT/eNP/2htauiFUzovR6ePM0cZ32sN zrEq5XGLLpxSteRwMBBZP5CMTtHvGKLevDWuo= 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=t+MJWRxDTU36V8xE19m5WjjSjbefnbmENuppDaMSAKg=; b=coZe8vwLTPgPc/CO0FvBrnJzFFe6MRaB+ODR5WvoX2pI9LYVFNg2/w2m1/dpXCdtgs dFT4beTT83axhCuCCber1hxLw27gnIaIwJqKYtdWr/bX0XkEDvfRJFbik3+9Qy8S7zvE YYVqhMUTeoQNFt38bWjqG1eNM3a329JTOT+PPbGToaHRRBoBl4EziYepkaN164gOYVmC ELjoMyNVegbm0+6ffPhjx4OSY4QtqZmO4pFzCSfFlp2uCgFz6RL+9+ZM46FYg6vplY/d CsXaot3gJXFyuI1tdOKcCXFidX7e/0Okmviw4Sew4dkTFFDuT2/zOcS3DvOLwCbqVDLG PqNQ== X-Gm-Message-State: AOAM533VzWKJstAiLGrHbTXTaDpYXjRs1bPJ71pcdYHy/eMhgSOr/Vk4 MXKLyxNH1nUcWECgIBOE3uR73J5W6KPyig== X-Google-Smtp-Source: ABdhPJzQFziyEOxR4M4WEIP+O4qnt4Ae36WVhsPv06w2uvaCbznCkxetg7oILk4zOMGS805bD5DvhQ== X-Received: by 2002:a19:230d:: with SMTP id j13mr2384907lfj.378.1610134466188; Fri, 08 Jan 2021 11:34:26 -0800 (PST) Received: from mail-lf1-f50.google.com (mail-lf1-f50.google.com. [209.85.167.50]) by smtp.gmail.com with ESMTPSA id 11sm2277557ljw.27.2021.01.08.11.34.25 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 08 Jan 2021 11:34:25 -0800 (PST) Received: by mail-lf1-f50.google.com with SMTP id x20so25493926lfe.12 for ; Fri, 08 Jan 2021 11:34:25 -0800 (PST) X-Received: by 2002:a2e:9ad7:: with SMTP id p23mr2022603ljj.465.1610134464854; Fri, 08 Jan 2021 11:34:24 -0800 (PST) MIME-Version: 1.0 References: <20210108171517.5290-1-will@kernel.org> In-Reply-To: <20210108171517.5290-1-will@kernel.org> From: Linus Torvalds Date: Fri, 8 Jan 2021 11:34:08 -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: Will Deacon Cc: 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 Fri, Jan 8, 2021 at 9:15 AM Will Deacon wrote: > > The big difference in this version is that I have reworked it based on > Kirill's patch which he posted as a follow-up to the original. However, > I can't tell where we've landed on that -- Linus seemed to like it, but > Hugh was less enthusiastic. Yeah, I like it, but I have to admit that it had a disturbingly high number of small details wrong for several versions. I hope you picked up the final version of the code. At the same time, I do think that the "disturbingly high number of issues" was primarily exactly _because_ the old code was so incomprehensible, and I think the end result is much cleaner, so I still like it. >I think that my subsequent patches are an > awful lot cleaner after the rework Yeah, I think that's a side effect of "now the code really makes a lot more sense". Your subsequent patches 2-3 certainly are much simpler now, although I'd be inclined to add an argument to "do_set_pte()" that has the "write" and "pretault" bits in it, instead of having to modify the 'vmf' structure. I still dislike how we basically randomly modify the information in that 'vmf' thing. That said, now it's just a small detail - not really objectionable, just a "this could be cleaner, I think". I think it was Kirill who pointed out that we sadly cannot make 'vmf' read-only anyway, because it does also contain those pre-allocation details etc (vmf->pte etc) that are very much about what the current "state" of the fault is. So while I would hope it could be more read-only than it is, my wish that it could _actually_ be 'const' is clearly just an irrelevant dream. Linus