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 DF069C433F5 for ; Fri, 18 Feb 2022 03:56:43 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 3A6CA6B0074; Thu, 17 Feb 2022 22:56:43 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 355766B0075; Thu, 17 Feb 2022 22:56:43 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1F5B86B0078; Thu, 17 Feb 2022 22:56:43 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0146.hostedemail.com [216.40.44.146]) by kanga.kvack.org (Postfix) with ESMTP id 0FCDF6B0074 for ; Thu, 17 Feb 2022 22:56:43 -0500 (EST) Received: from smtpin29.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id AD92488B2 for ; Fri, 18 Feb 2022 03:56:42 +0000 (UTC) X-FDA: 79154539044.29.2F4B871 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by imf01.hostedemail.com (Postfix) with ESMTP id 24AB840002 for ; Fri, 18 Feb 2022 03:56:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1645156601; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=bXeZkhLx3l6f5AkCBl9a2bLqsXjuwnfzkgL9f0Sf9iI=; b=IMaKH8g9F5gB7EnMQ1a29FC4hRoFEI84Xyv9Donuh6OgXL7qN66D7+xOGt9rQTvZXThByQ +6HXPTXBBw78T+FkobYX/kKamVE0fOY/ghJmvTfuahc4t3C8F9Cg/WIfMV1v6tmGANIQrf MFTPMud6JAeFGMnVE0vaUTP5MEd1+AQ= 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-255-rZjM__LSO8aj-r867-rb_w-1; Thu, 17 Feb 2022 22:56:39 -0500 X-MC-Unique: rZjM__LSO8aj-r867-rb_w-1 Received: by mail-pg1-f199.google.com with SMTP id o30-20020a634e5e000000b00373598b71d4so4025000pgl.21 for ; Thu, 17 Feb 2022 19:56:39 -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:content-transfer-encoding :in-reply-to; bh=bXeZkhLx3l6f5AkCBl9a2bLqsXjuwnfzkgL9f0Sf9iI=; b=trNos49mPk1wJx6OopmoKeTx31E1bRaimkntqbLhpHtRgPhTn2EhuXmJGVJNNgYiZM FeatcYpFgl2b01XB6U5zAnACOOSAnLSK7DPZq46S8C5//Bg4EYozCq7YbDrsZTru84xu j1XrW32UTjKa5joQFKAhTKmjD80Xr9hsJLCRbqtOCSMmfDC1Xm4cz+tFAzVBUDBHSM8z XiKHkWg4JG9vFlwymP5nlDcgB0QbmS6Hh85mEeQBycp80cCN5w28TR9mC+fyMMxzuKti /NuvFP7brW2lUUzhVSGLDwF3KR6790zVzaSu1yD+pxG16OOTq66L8i7EB7aqwLP6kweG acqg== X-Gm-Message-State: AOAM531FOlU0nviW+WXQbc7Gxu0mgddQQVDA+sW/d/hazuj+0NHSWFtE ZkSo4AJwwENEfNJCHdbH5KMhtTHDXuW+oS9QxsLI5FnTXI7soxSDdrjPAgk9BMfiwwDISQvcfwu 0RBB7uXRWeWg= X-Received: by 2002:a63:6a06:0:b0:344:252c:4063 with SMTP id f6-20020a636a06000000b00344252c4063mr4818954pgc.83.1645156598755; Thu, 17 Feb 2022 19:56:38 -0800 (PST) X-Google-Smtp-Source: ABdhPJzugqfiBRiPKlKlsLbvgn+eazeI05CjmJmzf+hsBWZYU8W5VTuGX10AqKj8BfzZlpa/XnVgYQ== X-Received: by 2002:a63:6a06:0:b0:344:252c:4063 with SMTP id f6-20020a636a06000000b00344252c4063mr4818938pgc.83.1645156598462; Thu, 17 Feb 2022 19:56:38 -0800 (PST) Received: from xz-m1.local ([94.177.118.104]) by smtp.gmail.com with ESMTPSA id mv17sm2739150pjb.14.2022.02.17.19.56.35 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 17 Feb 2022 19:56:37 -0800 (PST) Date: Fri, 18 Feb 2022 11:56:33 +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> MIME-Version: 1.0 In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Disposition: inline X-Rspamd-Queue-Id: 24AB840002 X-Stat-Signature: oycujkudywt5sw5mztdfs4bnzpyh8u61 X-Rspam-User: Authentication-Results: imf01.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=IMaKH8g9; spf=none (imf01.hostedemail.com: domain of peterx@redhat.com has no SPF policy when checking 170.10.129.124) smtp.mailfrom=peterx@redhat.com; dmarc=pass (policy=none) header.from=redhat.com X-Rspamd-Server: rspam05 X-HE-Tag: 1645156601-897246 Content-Transfer-Encoding: quoted-printable 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 06:23:14PM -0800, Nadav Amit wrote: >=20 >=20 > > 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 fla= g > >> set. This seems incorrect or at least would be unexpected by the use= rs. > >>=20 > >> Consider the following sequence of operations that are being perform= ed > >> 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); > > } >=20 > 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. Perhaps we can simply make this "if" to be "else" so as to connect with t= he previous "if"? After all the three (wp, wp_resolv, dirty_acct) are never used with more than one flag set. >=20 > I=E2=80=99ll post another patch for this one. >=20 > >=20 > > PS: I always think here the VM_SOFTDIRTY check is wrong, IMHO it shou= ld 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. >=20 > 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. I'll see whether I should prepare a patch and a test, maybe after yours. >=20 > > Could I ask why you need mprotect() with uffd? >=20 > 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. >=20 > 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 see. I didn't expect mprotect() can work well with uffd, but it seems fine at least in this case. Have you thought about other use of mprotect() other than RO? Say, I onl= y know a valid use case of PROT_NONE for region reservation purpose, which normally will be followed up by a munmap() and remap on the same address. That sounds okay. But not sure whether this patch will cover all the possible mprotect() uses in the tracee. >=20 > 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. Sure, I'm always happy to learn it. Thanks, >=20 > [1] https://lore.kernel.org/linux-mm/YWZCClDorCCM7KMG@t490s/t/ --=20 Peter Xu