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 BE184C352A1 for ; Tue, 6 Dec 2022 21:27:37 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 49FC98E0003; Tue, 6 Dec 2022 16:27:37 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 44FB28E0001; Tue, 6 Dec 2022 16:27:37 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2F22B8E0003; Tue, 6 Dec 2022 16:27:37 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 1BFEF8E0001 for ; Tue, 6 Dec 2022 16:27:37 -0500 (EST) Received: from smtpin17.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id DB039403EB for ; Tue, 6 Dec 2022 21:27:36 +0000 (UTC) X-FDA: 80213168112.17.59BBD07 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf10.hostedemail.com (Postfix) with ESMTP id 8A889C0008 for ; Tue, 6 Dec 2022 21:27:36 +0000 (UTC) Authentication-Results: imf10.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=dBm4DUqc; spf=pass (imf10.hostedemail.com: domain of peterx@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=peterx@redhat.com; dmarc=pass (policy=none) header.from=redhat.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1670362056; h=from:from:sender: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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=PRGbK9k8R9uzFMCG9ps6sFZXam1J9ub+EnEOXkruzkY=; b=wENKBZc/zVgGQ4E+M0Zg5WRIc/KP0TSqK+9nocvleFJUC7/0jmmIWxwy+Ahdx9xeItFYVK 8funZ99xgVNkwNAJGp69slqYXKPinFs9GeMUsUBphBgoKo2ARs5XQNDKMENGOG8XCSZ4o4 RkhX8NWTx6QbMpd69NEOI5J1beVSkPg= ARC-Authentication-Results: i=1; imf10.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=dBm4DUqc; spf=pass (imf10.hostedemail.com: domain of peterx@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=peterx@redhat.com; dmarc=pass (policy=none) header.from=redhat.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1670362056; a=rsa-sha256; cv=none; b=FxR2jhEk7NzeUWG/HjUZjHYYPLqLfHPWGpRG8Gz/XSaN+hIjTNek/xthGLw1dvlXi7AAaq /6JnScYvHrklQiO1vAhTfW19DMtkKCgOZSAq59sXkGGf9vimoYrhJAs0MG9KsA3y0s21qo xI/+vCVEdQuiUmu+urYRKsQcZkkFnz8= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1670362056; 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=PRGbK9k8R9uzFMCG9ps6sFZXam1J9ub+EnEOXkruzkY=; b=dBm4DUqcec8iQeDw8nOsoZnfinJnIXxbTLjszgSDPG82dRF+ZUgCs/OPKS0eUZ7dSKgySa CpG2yUR8RMYI/yVIykcA1pEV68qKrxjd3FWmzufxnfXTe3QCyeerJCmH3aSquBtKo/0zsF ruPzINCC1xphxzF9nuPdRBjuAbtmeTM= Received: from mail-qt1-f197.google.com (mail-qt1-f197.google.com [209.85.160.197]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-490-pOgR6_J1P3yw1bP_s8EjSQ-1; Tue, 06 Dec 2022 16:27:34 -0500 X-MC-Unique: pOgR6_J1P3yw1bP_s8EjSQ-1 Received: by mail-qt1-f197.google.com with SMTP id hg24-20020a05622a611800b003a66175d924so35355571qtb.1 for ; Tue, 06 Dec 2022 13:27:34 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=PRGbK9k8R9uzFMCG9ps6sFZXam1J9ub+EnEOXkruzkY=; b=spnw0+lWj9vGdAz8wZ03Rz58nJG7WCzRuG9g2yLrOy1x3w9Qi5ffr6rncbIIomY/RM xHP/ciPYvbmAt5vhBCpMUD+Qr6JQdKkbaPRh1aTNl8oqxGrREDwTfXkbCr+sXxaJDJOW f1IwTtsjicIK0PkB/7B6davSzf2h2jQjnqG/1IggeFlTjO5IrJRWNUi39cBSFzDFGqQw 145V0mX2hs5GIJWCPHeO0d38fPFx/onfWCI7zbKF7MWwwAMBbpxhjUkV+Q7cdcRoSIDZ pUByaZZ9IispafZ+XaY2jvvTECff/AswZp97vyyKFuJtpPG+AwTWRYyXT/NkM3LQbfTW 6zpg== X-Gm-Message-State: ANoB5pnuSAqUoCZWf1aMP7EvXo3as5JXB8kih+zuk3y5/IHxLsrK2L42 v3djNHtaZfHAW7ioKvvv+zge+1mNPIsaSmADEqq4F/5oqfmfZc5jssHRv3ueug3G90IQtoML8R2 f9ltfqUQkoUc= X-Received: by 2002:ac8:5508:0:b0:39c:da20:688 with SMTP id j8-20020ac85508000000b0039cda200688mr612916qtq.43.1670362054290; Tue, 06 Dec 2022 13:27:34 -0800 (PST) X-Google-Smtp-Source: AA0mqf4kmVlOInGq/Pojb+UUeaVf8jYPRob7UOLmrRyKTTf+RHP6JcKzENk2Gdwl4icvTqnqDou07g== X-Received: by 2002:ac8:5508:0:b0:39c:da20:688 with SMTP id j8-20020ac85508000000b0039cda200688mr612909qtq.43.1670362054063; Tue, 06 Dec 2022 13:27:34 -0800 (PST) Received: from x1n (bras-base-aurron9127w-grc-46-70-31-27-79.dsl.bell.ca. [70.31.27.79]) by smtp.gmail.com with ESMTPSA id k17-20020ac84791000000b003a50c9993e1sm12431610qtq.16.2022.12.06.13.27.32 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 06 Dec 2022 13:27:33 -0800 (PST) Date: Tue, 6 Dec 2022 16:27:31 -0500 From: Peter Xu To: David Hildenbrand Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org, Ives van Hoorne , stable@vger.kernel.org, Andrew Morton , Hugh Dickins , Alistair Popple , Mike Rapoport , Nadav Amit , Andrea Arcangeli Subject: Re: [PATCH RFC] mm/userfaultfd: enable writenotify while userfaultfd-wp is enabled for a VMA Message-ID: References: <20221202122748.113774-1-david@redhat.com> <690afe0f-c9a0-9631-b365-d11d98fdf56f@redhat.com> <19800718-9cb6-9355-da1c-c7961b01e922@redhat.com> <92173bad-caa3-6b43-9d1e-9a471fdbc184@redhat.com> MIME-Version: 1.0 In-Reply-To: <92173bad-caa3-6b43-9d1e-9a471fdbc184@redhat.com> X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Disposition: inline X-Spamd-Result: default: False [2.72 / 9.00]; SORBS_IRL_BL(3.00)[209.85.160.197:received]; BAYES_HAM(-2.38)[89.10%]; SUSPICIOUS_RECIPS(1.50)[]; MID_RHS_NOT_FQDN(0.50)[]; MIME_GOOD(-0.10)[text/plain]; BAD_REP_POLICIES(0.10)[]; RCVD_NO_TLS_LAST(0.10)[]; DKIM_TRACE(0.00)[redhat.com:+]; RCPT_COUNT_SEVEN(0.00)[11]; FROM_EQ_ENVFROM(0.00)[]; DMARC_POLICY_ALLOW(0.00)[redhat.com,none]; MIME_TRACE(0.00)[0:+]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_THREE(0.00)[4]; PREVIOUSLY_DELIVERED(0.00)[linux-mm@kvack.org]; R_DKIM_ALLOW(0.00)[redhat.com:s=mimecast20190719]; ARC_NA(0.00)[]; ARC_SIGNED(0.00)[hostedemail.com:s=arc-20220608:i=1]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(0.00)[+ip4:170.10.133.0/24]; TO_DN_SOME(0.00)[]; TAGGED_RCPT(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[] X-Rspam-User: X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 8A889C0008 X-Stat-Signature: 73myiftuy58mh6aa3456rh6mznekpye6 X-HE-Tag: 1670362056-797944 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 Tue, Dec 06, 2022 at 05:28:07PM +0100, David Hildenbrand wrote: > > If no one is using mprotect() with uffd-wp like that, then the reproducer > > may not be valid - the reproducer is defining how it should work, but does > > that really stand? That's why I said it's ambiguous, because the > > definition in this case is unclear. > > There are interesting variations like: > > mmap(PROT_READ, MAP_POPULATE|MAP_SHARED) > uffd_wp() > mprotect(PROT_READ|PROT_WRITE) > > Where we start out with all-write permissions before we enable selective > write permissions. Could you elaborate what's the difference of above comparing to: mmap(PROT_READ|PROT_WRITE, MAP_POPULATE|MAP_SHARED) uffd_wp() ? [...] > Yes, you are correct. I added that to the patch description: > > " > Note that we don't optimize for the actual migration case: > (1) When migration succeeds the new PTE will not be writable because > the source PTE was not writable (protnone); in the future we > might just optimize that case similarly by reusing > can_change_pte_writable()/can_change_pmd_writable() when > removing migration PTEs. > (2) When migration fails, we'd have to recalculate the "writable" > flag because we temporarily dropped the PT lock; for now keep it > simple and set "writable=false". > " > > Case (1) would, with your current patch, always lose the write bit during > migration, even if vma->vm_page_prot included it. We most might want to > optimize that in the future. > > Case (2) is rather a corner case, and unless people complain about it being > a real performance issue, it felt cleaner (less code) to not optimize for > that now. As I didn't have a closer look on the savedwrite removal patchset so I may not speak anything sensible here.. What I hope is that we don't lose write bits easily, after all we tried to even safe the dirty and young bits to avoid the machine cycles in the MMUs. > > Again Peter, I am not against you, not at all. Sorry if I gave you the > impression. I highly appreciate your work and this discussion. No worry on that part. You're doing great in this email explaining things and write things up, especially I'm happy Hugh confirmed it so it's good to have those. Let's start with something like this when you NAK something next time. :) Thanks, -- Peter Xu