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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id B887BC433F5 for ; Mon, 21 Feb 2022 06:24:01 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 1211D6B0072; Mon, 21 Feb 2022 01:24:01 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 0D0776B0073; Mon, 21 Feb 2022 01:24:01 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id EDA928D0001; Mon, 21 Feb 2022 01:24:00 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0066.hostedemail.com [216.40.44.66]) by kanga.kvack.org (Postfix) with ESMTP id DC3726B0072 for ; Mon, 21 Feb 2022 01:24:00 -0500 (EST) Received: from smtpin17.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 91A8A180B3E0C for ; Mon, 21 Feb 2022 06:24:00 +0000 (UTC) X-FDA: 79165796640.17.3D2CC33 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf15.hostedemail.com (Postfix) with ESMTP id 91FD8A0005 for ; Mon, 21 Feb 2022 06:24:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1645424639; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=puuW8hJ7l4e8iRoz8oAaTvCPF1M0N8o/5tS0H7Vhi4I=; b=RjUDV5JBiTdIbTsbmQ+OftoXxUmb4eTALmt3AM1lyfhtGVRN8olNvzBH53x1UkALbb5g9a 4YeY+GxVS7LORnhylYMPGwv+9qKoo7//0ZXPHuQOK/QDtORSoRD+ml5Sr0J3DIsoxFxYzv bZZc0tnGuw0wbz5DRozpGDhXPz3HjWA= Received: from mail-pg1-f199.google.com (mail-pg1-f199.google.com [209.85.215.199]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-610-x5ygOI00PASBaVsrOMpb-w-1; Mon, 21 Feb 2022 01:23:56 -0500 X-MC-Unique: x5ygOI00PASBaVsrOMpb-w-1 Received: by mail-pg1-f199.google.com with SMTP id k6-20020a63d846000000b00365088c8f6aso8930456pgj.6 for ; Sun, 20 Feb 2022 22:23:55 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=puuW8hJ7l4e8iRoz8oAaTvCPF1M0N8o/5tS0H7Vhi4I=; b=D2eBShyvDMmWRfQQR/MznxoRAKva84t94494FTXbR9qw5q5b9ngcRUcGAoAHi4ovS/ 8JhPLB6pTIgL+F9RLeE1aEZETUL6PeGeMMkcJUNz3wIVcWlW/B1S7KdaJhguJt2PdlEb rOMnM+lbIGuJ1vVbZxz5EmNisvsSqjZ5GCyZFBxtfuErv+By+U5Tda6wtqBDs0ivh7Wr +MCExyRP98sbTSmEKXxh9B3GwqroweMxemaVF41WDcSLO1LY7suriqTmYwvtkhYyn/8t meeLPt6aKdiP39MghzPH6QyPdGFUbOYhpVPfHrah7F+auswKr/4ZkOdaAKBFLlvdGj9K C3kw== X-Gm-Message-State: AOAM531vCKDgrz7JbBZ3YlCWvBEpJnxxvso9L3u4BFOf2Ed/KB/5+VDM rEVBXOF77YrECmWp3LggQFqWIW6sdWCYiQZP9lCSGUPZ62pCj7HCnBj2KjeqL4cFOn73wdh69iV zCkJXF07BUKs= X-Received: by 2002:a17:902:dacd:b0:14f:4e5d:fe0d with SMTP id q13-20020a170902dacd00b0014f4e5dfe0dmr17507758plx.128.1645424634566; Sun, 20 Feb 2022 22:23:54 -0800 (PST) X-Google-Smtp-Source: ABdhPJxELl+aXRX4yzOOiRXovJ46Ax7mtRuEZrDkfrPBs5X56Bykl1cYVANw8DRO28eHUExeVt/FvQ== X-Received: by 2002:a17:902:dacd:b0:14f:4e5d:fe0d with SMTP id q13-20020a170902dacd00b0014f4e5dfe0dmr17507745plx.128.1645424634270; Sun, 20 Feb 2022 22:23:54 -0800 (PST) Received: from xz-m1.local ([94.177.118.63]) by smtp.gmail.com with ESMTPSA id c3sm11202930pfd.129.2022.02.20.22.23.50 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 20 Feb 2022 22:23:53 -0800 (PST) Date: Mon, 21 Feb 2022 14:23:47 +0800 From: Peter Xu To: Nadav Amit Cc: Andrew Morton , Linux-MM , Mike Rapoport , Andrea Arcangeli , stable@vger.kernel.org Subject: Re: [PATCH] userfaultfd: mark uffd_wp regardless of VM_WRITE flag Message-ID: References: <20220217211602.2769-1-namit@vmware.com> <68B04C0D-F8CE-4C95-9032-CF703436DC99@gmail.com> MIME-Version: 1.0 In-Reply-To: <68B04C0D-F8CE-4C95-9032-CF703436DC99@gmail.com> X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Disposition: inline X-Rspamd-Queue-Id: 91FD8A0005 X-Stat-Signature: smfgb6fd9goxt65b786s34gw4gtpwqik Authentication-Results: imf15.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=RjUDV5JB; dmarc=pass (policy=none) header.from=redhat.com; spf=none (imf15.hostedemail.com: domain of peterx@redhat.com has no SPF policy when checking 170.10.133.124) smtp.mailfrom=peterx@redhat.com X-Rspam-User: X-Rspamd-Server: rspam11 X-HE-Tag: 1645424640-990046 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 Thu, Feb 17, 2022 at 08:00:12PM -0800, Nadav Amit wrote: > > > On Feb 17, 2022, at 6:23 PM, Nadav Amit wrote: > > > >> PS: I always think here the VM_SOFTDIRTY check is wrong, IMHO it should be: > >> > >> if (dirty_accountable && pte_dirty(ptent) && > >> (pte_soft_dirty(ptent) || > >> (vma->vm_flags & VM_SOFTDIRTY))) { > >> ptent = pte_mkwrite(ptent); > >> } > > I know it is off-topic (not directly related to my patch), but > I tried to understand the logic - both of the existing code and of > your suggested change - and I failed. > > IIUC dirty_accountable (whose value is taken from > vma_wants_writenotify()) means that the writes *should* be tracked, > and therefore the page should remain read-only. Right. > > So basically the condition should have been based on > !dirty_accountable, i.e. the inverted value of dirty_accountable. > > The problem is that dirty_accountable also reflects VM_SOFTDIRTY > considerations, so looking on the PTE does not tell you whether > the PTE should remain write-protected even if it is dirty. My understanding is that the dirty bits (especially if both set) means we've tracked dirty on this pte already so we don't need to, hence we can set the dirty bit here. E.g., continuous mprotect(RO), mprotect(RW) upon a full dirty pte. When something wants to enable tracking again, it needs to clear the dirty bit, either the real one or soft-dirty one. So it's a pure performance enhancement to conditionally set write bit here, when we're sure we won't need any further tracking on this pte. One thing to mention is that this path only applies to VM_SHARED|VM_WRITE, because that's what checked the first in vma_wants_writenotify(): /* If it was private or non-writable, the write bit is already clear */ if ((vm_flags & (VM_WRITE|VM_SHARED)) != ((VM_WRITE|VM_SHARED))) return 0; IOW private mappings are not optimized in current tree yet. Peter Collingbourne proposed a patch some time ago to optimize it but it didn't get merged somehow. Meanwhile even with his latest version it should still miss the thp case, so if to reference the private optimization Andrea's tree would be the best: https://github.com/aagit/aa/commit/fadb5e04d94472614c76819acd979b2f60e4eff6 Hope it clarifies things a bit. Thanks, -- Peter Xu