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 5C616C433F5 for ; Wed, 16 Mar 2022 22:05:59 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C424B6B0071; Wed, 16 Mar 2022 18:05:58 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id BF2928D0002; Wed, 16 Mar 2022 18:05:58 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id ABA828D0001; Wed, 16 Mar 2022 18:05:58 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0080.hostedemail.com [216.40.44.80]) by kanga.kvack.org (Postfix) with ESMTP id 9CAA16B0071 for ; Wed, 16 Mar 2022 18:05:58 -0400 (EDT) Received: from smtpin26.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 5A7628249980 for ; Wed, 16 Mar 2022 22:05:58 +0000 (UTC) X-FDA: 79251632796.26.F212777 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by imf23.hostedemail.com (Postfix) with ESMTP id 95009140010 for ; Wed, 16 Mar 2022 22:05:57 +0000 (UTC) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id D9898B810F8; Wed, 16 Mar 2022 22:05:55 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 735F4C340EC; Wed, 16 Mar 2022 22:05:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1647468354; bh=LM+PeWJfSxbwSLSeTGQlI1OYnxRksYJXzPpCpetxttg=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=Pc6q4CdhqXO9hgGxXZTWm5lN5emNU/3GuyXneuhGDxioCR1M0iFaq04zZEym0HpAy YexVTYgnRfT0DF2e0tMLzUmuetNNwpY5kx7VVVnl54UfjrAozaKCXtj8EXxG4VqH2I 3bvB5hvWYhPaVSVN1fYuDgnWSt4c6Q9awIdnQpy8= Date: Wed, 16 Mar 2022 15:05:53 -0700 From: Andrew Morton To: Nadav Amit Cc: Peter Xu , Linux-MM , Mike Rapoport , Andrea Arcangeli , stable@vger.kernel.org Subject: Re: [PATCH] userfaultfd: mark uffd_wp regardless of VM_WRITE flag Message-Id: <20220316150553.c7b6f9e0eac620c9ee5963a5@linux-foundation.org> In-Reply-To: <3E9C755C-7335-4636-8280-D5CB9735A76A@gmail.com> References: <20220217211602.2769-1-namit@vmware.com> <68B04C0D-F8CE-4C95-9032-CF703436DC99@gmail.com> <3E9C755C-7335-4636-8280-D5CB9735A76A@gmail.com> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; x86_64-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspam-User: X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: 95009140010 X-Stat-Signature: 3qucryio4jfxdnkckiydgnte6aqtotgt Authentication-Results: imf23.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b=Pc6q4Cdh; spf=pass (imf23.hostedemail.com: domain of akpm@linux-foundation.org designates 145.40.68.75 as permitted sender) smtp.mailfrom=akpm@linux-foundation.org; dmarc=none X-HE-Tag: 1647468357-612747 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: As I understand it, this patch (below) is still good to merge upstream, although Peter hasn't acked it (please). And a whole bunch of followup patches are being thought about, but have yet to eventuate. Do we feel that this patch warrants the cc:stable? I'm suspecting "no", as it isn't clear that the use-case is really legitimate at this time? Thanks. From: Nadav Amit Subject: userfaultfd: mark uffd_wp regardless of VM_WRITE flag 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. Consider the following sequence of operations that are being performed on a certain page: mprotect(PROT_READ) UFFDIO_COPY(UFFDIO_COPY_MODE_WP) mprotect(PROT_READ|PROT_WRITE) At this point the user would expect to still get UFFD notification when the page is accessed for write, but the user would not get one, since the PTE was not marked as UFFD_WP during UFFDIO_COPY. Fix it by always marking PTEs as UFFD_WP regardless on the write-permission in the VMA flags. Link: https://lkml.kernel.org/r/20220217211602.2769-1-namit@vmware.com Fixes: 292924b26024 ("userfaultfd: wp: apply _PAGE_UFFD_WP bit") Signed-off-by: Nadav Amit Cc: Axel Rasmussen Cc: Mike Rapoport Cc: Andrea Arcangeli Cc: Peter Xu Cc: Signed-off-by: Andrew Morton --- mm/userfaultfd.c | 15 +++++++++------ 1 file changed, 9 insertions(+), 6 deletions(-) --- a/mm/userfaultfd.c~userfaultfd-mark-uffd_wp-regardless-of-vm_write-flag +++ a/mm/userfaultfd.c @@ -72,12 +72,15 @@ int mfill_atomic_install_pte(struct mm_s _dst_pte = pte_mkdirty(_dst_pte); if (page_in_cache && !vm_shared) writable = false; - if (writable) { - if (wp_copy) - _dst_pte = pte_mkuffd_wp(_dst_pte); - else - _dst_pte = pte_mkwrite(_dst_pte); - } + + /* + * Always mark a PTE as write-protected when needed, regardless of + * VM_WRITE, which the user might change. + */ + if (wp_copy) + _dst_pte = pte_mkuffd_wp(_dst_pte); + else if (writable) + _dst_pte = pte_mkwrite(_dst_pte); dst_pte = pte_offset_map_lock(dst_mm, dst_pmd, dst_addr, &ptl); _