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 915FDC352A1 for ; Wed, 7 Dec 2022 13:34:07 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E75D38E0003; Wed, 7 Dec 2022 08:34:06 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id E25BA8E0001; Wed, 7 Dec 2022 08:34:06 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id CC6028E0003; Wed, 7 Dec 2022 08:34:06 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id B9BD28E0001 for ; Wed, 7 Dec 2022 08:34:06 -0500 (EST) Received: from smtpin26.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 8E198A0321 for ; Wed, 7 Dec 2022 13:34:06 +0000 (UTC) X-FDA: 80215603692.26.F506D8B Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by imf21.hostedemail.com (Postfix) with ESMTP id 45F871C000D for ; Wed, 7 Dec 2022 13:34:06 +0000 (UTC) Authentication-Results: imf21.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=FYwyZsfJ; dmarc=pass (policy=none) header.from=redhat.com; spf=pass (imf21.hostedemail.com: domain of david@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=david@redhat.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1670420046; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=PacGtqlFWYVFHK08vpyrRIk/v4jPepTFNKvA2M5ITow=; b=UHWCymYxiXBcQw7w6ODZ499EseNk1K8kiwzOOgaKdcwXBMiFHQITfoAnFr2rwkG39+svcr BvblJym1kRHbLi0rulrWrsE+zSd9yM+lFPGwFp7Jbr149k1n4S2VnYmiuTSX6KzeFFynKg ET9RFzvp1c4NcuFQojm/tEgphvRYieA= ARC-Authentication-Results: i=1; imf21.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=FYwyZsfJ; dmarc=pass (policy=none) header.from=redhat.com; spf=pass (imf21.hostedemail.com: domain of david@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=david@redhat.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1670420046; a=rsa-sha256; cv=none; b=bte4LpjGRgy7N9S5+Qpp/BjmTDQrDUhc4n3iZXXJmHhucBB6Nlmtpn1/J6MuR6KNmjiKgl Kra42SUgHsGo8fLVzDsbJVwdiVdRcLYLD4MroOsRMl18wSVi4RBI8l8raioFMyCf7K5PPg kbZhO+rxs7nYlqmVuiQYHghr7E2iw0s= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1670420045; 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=PacGtqlFWYVFHK08vpyrRIk/v4jPepTFNKvA2M5ITow=; b=FYwyZsfJMFw96sYFVIA47h6npAmjz71TwjLRBaHqUQZpAavU+1RVTxFwI36x710mHizqdE NsM1OdsaCD2SRrL2RBS6zBtyeo620IkIllwIAHUogSv+TOuQzhSAiLmqSmDX/HJzrAmbb6 zJpXeYQ0SDUxUgT1WJjO5cTW/vVY0dA= Received: from mail-wm1-f72.google.com (mail-wm1-f72.google.com [209.85.128.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-295-JVnIN6wAPySuUW8osCIjYQ-1; Wed, 07 Dec 2022 08:34:04 -0500 X-MC-Unique: JVnIN6wAPySuUW8osCIjYQ-1 Received: by mail-wm1-f72.google.com with SMTP id r67-20020a1c4446000000b003d09b0fbf54so810329wma.3 for ; Wed, 07 Dec 2022 05:34:04 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:subject:organization:from :content-language:references:cc:to:user-agent:mime-version:date :message-id:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=PacGtqlFWYVFHK08vpyrRIk/v4jPepTFNKvA2M5ITow=; b=qGO6OmsekiZN8TeTxjnQbj76KHg/iFU78ELRh9VsdXjXBS7Etf+hZH8mv3C4/e+t1k qzreN3dIOiw/5/ZwdwkLlqVl1uYo3x9EnPEh0brRrr4N/4GqMYAfxLyg+tt4CL5mxXLb ygHgHoFH7NcEiuz78T+HQfQ3k5QncpqI7gxcOIu+g4Ud6l+sAS4V+Su2prw+bPXHDNyC 5+PscFdtGJ7HgYsZves71a/hhEkotcmCvWtcCXjNBHJlwEajuJctqUMVlNJIgZyzzSpo zbFFokioAK8Cr/bQhcDuY5zMnMgtJPyzG+HiqAo/N/VvLt+p/6ABGrlRY42jBR2kRH0J hGFg== X-Gm-Message-State: ANoB5plf6hMG4jfihaKtcPsVotZI7S/t6cpWhPlQW9DkxjAeCmqZ/k7O Eq1hRherBhm6RHlKPhe0rM9Ov51XhjWV7Nm6GbMDHiFm4Bo8y8vskq1XWX0HM6mmG9OXY8xJrDo zokulwHQc0W8= X-Received: by 2002:a05:600c:1c1f:b0:3d1:e4eb:f10b with SMTP id j31-20020a05600c1c1f00b003d1e4ebf10bmr6109378wms.177.1670420043244; Wed, 07 Dec 2022 05:34:03 -0800 (PST) X-Google-Smtp-Source: AA0mqf4a2MUA3DcA1oUBjxiv78Kg8oZodekc9xEO92gstattJfwaiiWOBsV20RKSEATfQHIGCKb3zg== X-Received: by 2002:a05:600c:1c1f:b0:3d1:e4eb:f10b with SMTP id j31-20020a05600c1c1f00b003d1e4ebf10bmr6109360wms.177.1670420042894; Wed, 07 Dec 2022 05:34:02 -0800 (PST) Received: from ?IPV6:2003:cb:c702:2500:fe2d:7534:ffa4:c1e5? (p200300cbc7022500fe2d7534ffa4c1e5.dip0.t-ipconnect.de. [2003:cb:c702:2500:fe2d:7534:ffa4:c1e5]) by smtp.gmail.com with ESMTPSA id m14-20020a5d624e000000b00241dd5de644sm19196977wrv.97.2022.12.07.05.33.59 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 07 Dec 2022 05:34:00 -0800 (PST) Message-ID: <5a626d30-ccc9-6be3-29f7-78f83afbe5c4@redhat.com> Date: Wed, 7 Dec 2022 14:33:58 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.5.0 To: Peter Xu 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 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> From: David Hildenbrand Organization: Red Hat Subject: Re: [PATCH RFC] mm/userfaultfd: enable writenotify while userfaultfd-wp is enabled for a VMA In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spamd-Result: default: False [-5.40 / 9.00]; BAYES_HAM(-6.00)[100.00%]; SUSPICIOUS_RECIPS(1.50)[]; DMARC_POLICY_ALLOW(-0.50)[redhat.com,none]; R_DKIM_ALLOW(-0.20)[redhat.com:s=mimecast20190719]; R_SPF_ALLOW(-0.20)[+ip4:170.10.129.0/24]; RCVD_NO_TLS_LAST(0.10)[]; MIME_GOOD(-0.10)[text/plain]; TAGGED_RCPT(0.00)[]; RCPT_COUNT_SEVEN(0.00)[11]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; FROM_EQ_ENVFROM(0.00)[]; TO_DN_SOME(0.00)[]; DKIM_TRACE(0.00)[redhat.com:+]; RCVD_COUNT_THREE(0.00)[4]; PREVIOUSLY_DELIVERED(0.00)[linux-mm@kvack.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; ARC_SIGNED(0.00)[hostedemail.com:s=arc-20220608:i=1]; HAS_ORG_HEADER(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[] X-Rspamd-Queue-Id: 45F871C000D X-Rspamd-Server: rspam09 X-Rspam-User: X-Stat-Signature: eh7ybtgucphfcebyn96hm858cfqkigm6 X-HE-Tag: 1670420046-450053 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 06.12.22 22:27, Peter Xu wrote: > 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() > > ? That mapping would temporarily allow write access. I'd imagine that something like that might be useful when atomically replacing an existing mapping (MAP_FIXED), and the VMA might already be in use by other threads. or when you really want to catch any possible write access. For example, libvhost-user.c in QEMU uses for ordinary postcopy: /* * In postcopy we're using PROT_NONE here to catch anyone * accessing it before we userfault. */ mmap_addr = mmap(0, dev_region->size + dev_region->mmap_offset, PROT_NONE, MAP_SHARED | MAP_NORESERVE, vmsg->fds[0], 0); I'd imagine, when using uffd-wp (VM snapshotting with shmem?) one might use PROT_READ instead before the write-protection is properly set. Because read access would be fine in the meantime. But I'm just pulling use cases out of my magic hat ;) Nothing stops user space from doing things that are not clearly forbidden (well, even then users might complain, but that's a different story). [...] >> 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. Hopefully, someone will complain loudly if that corner case is relevant. > >> >> 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, David / dhildenb