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 31842C433EF for ; Mon, 28 Feb 2022 18:32:01 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 704FC8D0002; Mon, 28 Feb 2022 13:32:00 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 6B35D8D0001; Mon, 28 Feb 2022 13:32:00 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 57B9A8D0002; Mon, 28 Feb 2022 13:32:00 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0179.hostedemail.com [216.40.44.179]) by kanga.kvack.org (Postfix) with ESMTP id 4A4F48D0001 for ; Mon, 28 Feb 2022 13:32:00 -0500 (EST) Received: from smtpin30.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id EA2818249980 for ; Mon, 28 Feb 2022 18:31:59 +0000 (UTC) X-FDA: 79193032758.30.90873BD Received: from mail-oi1-f172.google.com (mail-oi1-f172.google.com [209.85.167.172]) by imf31.hostedemail.com (Postfix) with ESMTP id 7DA6320009 for ; Mon, 28 Feb 2022 18:31:59 +0000 (UTC) Received: by mail-oi1-f172.google.com with SMTP id j24so13972452oii.11 for ; Mon, 28 Feb 2022 10:31:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=dI59wPXipr10daedy0IHllFTQmAqt3lJLYrEcIBjKpo=; b=JT3wkYgUMQTt4ly66ev/doKnoEVdvzi8mZR2eCb0rXyoRB7Zi70E0L1BN7Vzi9nEQe xXfyNnLpz/JkVBRHN/1ccTCGQI32esDU0OQAjb+RxNIo3++MvG3icsvDONHhQxrGQPQ4 WUFYV2pRbTYA4nk0bw5vLl6n81lbyqYVaXaIn1vEoLd/+1BG0JB92zUTYG/Llvr9HiTr hRVIb0CQVW8kMZKfAEGmfPQukfSxHT77GVRpkSGPyOijpAcqAjP4ptWe8Sw5CSIT1JXL t9oZyFA89i7VnfwB/m+p9WisAnswQ67RX2jbJvESOMJEI16HlBuPQpqUWbOHB3HJNkYM t+gA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=dI59wPXipr10daedy0IHllFTQmAqt3lJLYrEcIBjKpo=; b=R7Tvy5CQwtsFkiepboxhObupgzTkOlZfj3l4lVEZh4+jue1LxJDCgt0AYH2yBH8Skm sOsxKiYe1sNktjSfbEw4divy2aOVuQsrZeMdbe1KWwp5C8B46oFVqrkVAI+8uX0KsL3D a7aJY3kpZzGfqW3Qdx1wMOokpseVL/KXlqDky45p61kX+EDVuwvzoIprJLHvh6k11vrT wIX7WMhjuD7/r7FxNFwmaoYwCypxnjBMn+X56+kvgIBfIvk7XZC07xS2pNNOlZ7j+XLq 03kQLrRP8dqhaMs4s8GJciQ7tviOBbmpt2byRosYdkEldzaywHU1cjKVnsA3DllskvZ8 LXZg== X-Gm-Message-State: AOAM533aP2gE2Xi0rDO716Fy9jf0yfA1CFgw6tWciw8hKMhhWG/ryw3v C7L1QmkWg+oiHJsB9pviYxs= X-Google-Smtp-Source: ABdhPJwuVDRaaC5EBG/aD/6CYtG2mWLNXB376mcWD0QG44tPY1d543wq5ab9R4JYzJXWwTgGiBfg8w== X-Received: by 2002:a05:6808:118d:b0:2cc:ef90:3812 with SMTP id j13-20020a056808118d00b002ccef903812mr11822029oil.48.1646073118607; Mon, 28 Feb 2022 10:31:58 -0800 (PST) Received: from smtpclient.apple (c-24-6-216-183.hsd1.ca.comcast.net. [24.6.216.183]) by smtp.gmail.com with ESMTPSA id s3-20020a056808208300b002d38ef031d6sm6583639oiw.36.2022.02.28.10.31.56 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 28 Feb 2022 10:31:57 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 15.0 \(3693.60.0.1.1\)) Subject: Re: [PATCH] userfaultfd: mark uffd_wp regardless of VM_WRITE flag From: Nadav Amit In-Reply-To: Date: Mon, 28 Feb 2022 10:31:56 -0800 Cc: Andrew Morton , Linux-MM , Mike Rapoport , Andrea Arcangeli , stable@vger.kernel.org Content-Transfer-Encoding: quoted-printable Message-Id: <54D15136-CC60-421F-AB58-4C44D338787E@gmail.com> References: <20220217211602.2769-1-namit@vmware.com> <68B04C0D-F8CE-4C95-9032-CF703436DC99@gmail.com> To: Peter Xu X-Mailer: Apple Mail (2.3693.60.0.1.1) X-Rspamd-Queue-Id: 7DA6320009 X-Stat-Signature: azq9g74czkbucpkyuagioj7xo7zof491 X-Rspam-User: Authentication-Results: imf31.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=JT3wkYgU; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf31.hostedemail.com: domain of nadav.amit@gmail.com designates 209.85.167.172 as permitted sender) smtp.mailfrom=nadav.amit@gmail.com X-Rspamd-Server: rspam03 X-HE-Tag: 1646073119-807895 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 Feb 20, 2022, at 10:23 PM, Peter Xu wrote: >=20 > On Thu, Feb 17, 2022 at 08:00:12PM -0800, Nadav Amit wrote: >>=20 >>> On Feb 17, 2022, at 6:23 PM, Nadav Amit = wrote: >>>=20 >>>> PS: I always think here the VM_SOFTDIRTY check is wrong, IMHO it = should be: >>>>=20 >>>> if (dirty_accountable && pte_dirty(ptent) && >>>> (pte_soft_dirty(ptent) || >>>> (vma->vm_flags & VM_SOFTDIRTY))) { >>>> ptent =3D pte_mkwrite(ptent); >>>> } >>=20 >> 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. >>=20 >> 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. >=20 > Right. >=20 >>=20 >> So basically the condition should have been based on >> !dirty_accountable, i.e. the inverted value of dirty_accountable. >>=20 >> 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. >=20 > 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. >=20 > 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. >=20 > 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(): >=20 > /* If it was private or non-writable, the write bit is already = clear */ > if ((vm_flags & (VM_WRITE|VM_SHARED)) !=3D = ((VM_WRITE|VM_SHARED))) > return 0; >=20 > IOW private mappings are not optimized in current tree yet. >=20 > 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: >=20 > = https://github.com/aagit/aa/commit/fadb5e04d94472614c76819acd979b2f60e4eff= 6 >=20 > Hope it clarifies things a bit. Thanks, Thanks for the clarification. That=E2=80=99s what I suspected - I did = not encounter it since I only used private anonymous mappings. I will try to create a test-case and send an additional fix for this issue. Regards, Nadav=