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 4CD84C433EF for ; Fri, 18 Feb 2022 02:23:19 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C4BB66B0074; Thu, 17 Feb 2022 21:23:18 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id BD3276B0075; Thu, 17 Feb 2022 21:23:18 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A749F6B0078; Thu, 17 Feb 2022 21:23:18 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0003.hostedemail.com [216.40.44.3]) by kanga.kvack.org (Postfix) with ESMTP id 911236B0074 for ; Thu, 17 Feb 2022 21:23:18 -0500 (EST) Received: from smtpin07.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 4EE0F181AC9C6 for ; Fri, 18 Feb 2022 02:23:18 +0000 (UTC) X-FDA: 79154303676.07.FAC1B0E Received: from mail-pl1-f178.google.com (mail-pl1-f178.google.com [209.85.214.178]) by imf08.hostedemail.com (Postfix) with ESMTP id D0F55160004 for ; Fri, 18 Feb 2022 02:23:17 +0000 (UTC) Received: by mail-pl1-f178.google.com with SMTP id x4so6043845plb.4 for ; Thu, 17 Feb 2022 18:23:17 -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=qlFCJvtsoFhAC6B656rI4CAiTCAEIaN9fza+d6cKKMA=; b=CyYDFXBqfqTrwf+t/blLpQF1qdF8hDUp8Zldfrdo1atusmBe5YIAUmmYLMAw7hODXO fD4hM5rgp+mABfwbmFYG+9yq9NfSK8Et6/+Zh8ox3kHodMfZ4n2e1i2D2y22Hy+0JP1f xSJAApVmCgJdBctnUf2I+n61wZI0Luh7zUDIS8EuwNm8wn7C9lByy4nFeVTReXZOLus6 tSa6eEjFdgaz0FiHnSQZsNVnEngv7O/TEqxyJ2ma6ZY7PYhiOxgehLajk2Z55ST8CJj/ GRGe8S4/4zuf78TToby71Y50Xq3za+ntB+2UQ4rr5z80C/9VeHXZjSN+D0RtRv280jkW mjoQ== 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=qlFCJvtsoFhAC6B656rI4CAiTCAEIaN9fza+d6cKKMA=; b=sSIiz2t2a8QJsGZZr+FgY9P7mItonaZRwDT7wUvnWz8h45e+TOuhCyRrEQYYWhg+wG NV3ZQez5YWS9PSzOyBXTJTCKvjctwODvfw67VrHmOYWF1E3Wu83VINBPVWNLVn8NueNX fn31FgQfsjyvTld8X6ikRDczc1ohSsttZQJ4Z7j/TKaied3Naw5tYg/ozB9B82vTJGlW V/niOO9ZJucLPBZsvvzkO4JLjvrKOWSIKp4qwfrrXkQ6M3BKi6nWmQUVfoN7ThEPhMMt KVreOmKlFXJRNt+2ceucbxuQKZ1SLT57nWchzs9pXRRBg60kKbiVJRtB+67yufuUz08c wRNg== X-Gm-Message-State: AOAM532kUGFbGsExsyH9+CrQvVVXcSyyNREXf5B5miHbT0T3gNNDVw9u DFJB6ILZh4XNkBA0QAhs3YM= X-Google-Smtp-Source: ABdhPJx3x17nbBroJaprM83J1GVuaHoaC4PRj6D2q5DpC1wjv+ba8i0tP7pt0A8XfOXrrZELqFw7Nw== X-Received: by 2002:a17:902:b105:b0:149:7c20:c15b with SMTP id q5-20020a170902b10500b001497c20c15bmr5326157plr.173.1645150996581; Thu, 17 Feb 2022 18:23:16 -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 a38sm860329pfx.121.2022.02.17.18.23.15 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 17 Feb 2022 18:23:16 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 15.0 \(3693.40.0.1.81\)) Subject: Re: [PATCH] userfaultfd: mark uffd_wp regardless of VM_WRITE flag From: Nadav Amit In-Reply-To: Date: Thu, 17 Feb 2022 18:23:14 -0800 Cc: Andrew Morton , Linux-MM , Mike Rapoport , Andrea Arcangeli , stable@vger.kernel.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <20220217211602.2769-1-namit@vmware.com> To: Peter Xu X-Mailer: Apple Mail (2.3693.40.0.1.81) X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: D0F55160004 X-Rspam-User: Authentication-Results: imf08.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=CyYDFXBq; spf=pass (imf08.hostedemail.com: domain of nadav.amit@gmail.com designates 209.85.214.178 as permitted sender) smtp.mailfrom=nadav.amit@gmail.com; dmarc=pass (policy=none) header.from=gmail.com X-Stat-Signature: qkwe8afzaaxjq6rjj45p7quw55wyjgup X-HE-Tag: 1645150997-714073 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 17, 2022, at 5:58 PM, Peter Xu wrote: >=20 > Hello, Nadav, >=20 > On Thu, Feb 17, 2022 at 09:16:02PM +0000, Nadav Amit wrote: >> From: Nadav Amit >>=20 >> When a PTE is set by UFFD operations such as UFFDIO_COPY, the PTE is >> currently only marked as write-protected if the VMA has VM_WRITE flag >> set. This seems incorrect or at least would be unexpected by the = users. >>=20 >> Consider the following sequence of operations that are being = performed >> on a certain page: >>=20 >> mprotect(PROT_READ) >> UFFDIO_COPY(UFFDIO_COPY_MODE_WP) >> mprotect(PROT_READ|PROT_WRITE) >=20 > No objection to the patch, however I'm wondering why this is a valid = use > case because mprotect seems to be conflict with uffd, because AFAICT > mprotect(PROT_READ|PROT_WRITE) can already grant write bit. >=20 > In change_pte_range(): >=20 > if (dirty_accountable && pte_dirty(ptent) && > (pte_soft_dirty(ptent) || > !(vma->vm_flags & VM_SOFTDIRTY))) { > ptent =3D pte_mkwrite(ptent); > } I think you are right, and an additional patch is needed to prevent mprotect() from making an entry writable if the PTE has _PAGE_UFFD_WP set and uffd_wp_resolve was not provided. I missed that. I=E2=80=99ll post another patch for this one. >=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 > Because when VM_SOFTDIRTY is cleared it means soft dirty enabled. I = wanted > to post a patch but I never yet. Seems that you are right. Yet, having this wrong code around for some time raises the concern whether something will break. By the soft-dirty I saw so far, it seems that it is not commonly used. > Could I ask why you need mprotect() with uffd? Sure. I think I mentioned it before, that I want to use userfaultfd for other processes [1], by having one monitor UFFD for multiple processes that handles their swap/prefetch activities based on custom policies. I try to set the least amount of constraints on what these processes might do, and mprotect() is something they are allowed to do. I would hopefully send the patches that are required for all of that and open source my code soon. In the meanwhile I try to upstream the least controversial parts. [1] https://lore.kernel.org/linux-mm/YWZCClDorCCM7KMG@t490s/t/