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 C36A5C61CE8 for ; Fri, 6 Jun 2025 13:24:59 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 03F9D6B007B; Fri, 6 Jun 2025 09:24:59 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 017206B0088; Fri, 6 Jun 2025 09:24:58 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E6FA76B0089; Fri, 6 Jun 2025 09:24:58 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id CC40E6B007B for ; Fri, 6 Jun 2025 09:24:58 -0400 (EDT) Received: from smtpin05.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 7417BBF759 for ; Fri, 6 Jun 2025 13:24:58 +0000 (UTC) X-FDA: 83525046276.05.B5E97DE Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf29.hostedemail.com (Postfix) with ESMTP id 13C2F12000D for ; Fri, 6 Jun 2025 13:24:55 +0000 (UTC) Authentication-Results: imf29.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=bMeXzgKt; spf=pass (imf29.hostedemail.com: domain of peterx@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=peterx@redhat.com; dmarc=pass (policy=quarantine) header.from=redhat.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1749216296; 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=Ky+WeROHZ4Ae+uVfELGBGltSg87Rkj3Uw9xYsa9j3qg=; b=3B2pMlfYVyBGziT47QWdcS9UySMTHtLWp12vsaqeoybHAjkxv+fqejkHsHZOsmSmeuIav8 fkUlKL9SGfV9EqVH2TcU7FuK77+h0OpyaNYUEoCrLznU314MzEa6oTjN3mItrIbg21D9Jn T4EwDwG4AgubTcdYA8U8gJCSixlhqtg= ARC-Authentication-Results: i=1; imf29.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=bMeXzgKt; spf=pass (imf29.hostedemail.com: domain of peterx@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=peterx@redhat.com; dmarc=pass (policy=quarantine) header.from=redhat.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1749216296; a=rsa-sha256; cv=none; b=Q5B4r+Qpwpffz46Abq/LEm4gzy7Qw7aMolAqdl6KLFkB5TTHoDuFtCBImXoVErISqv/Tbw yBvCkBeeZmC5NxWr9B/M+ojJZJ+x1P9hKmDfyzVL3HWSUr1NVcaGi5u2XV7yhjJwcsh0/g kjlmh3dPNBau4Jr6dv2JVPqOUXcnOpA= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1749216295; 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=Ky+WeROHZ4Ae+uVfELGBGltSg87Rkj3Uw9xYsa9j3qg=; b=bMeXzgKtFZH5L+oZf1hFR+XQI6E8Tbd/sEYeWgE75j5Rs4jXghP8SAo4wlrfFI16vuJtk+ LVSjAOXGf2EaHjNJuxT8dlTk3E6Oj6qFWAg0XUnZztTdhFpWZxmFZp1brkqiUSsPTAIbav PSrrx4kbcrTWiMhLzJVQChORU/XrmWQ= Received: from mail-qk1-f199.google.com (mail-qk1-f199.google.com [209.85.222.199]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-110-0DEEa_b7Pz-aBXTD0-eL4Q-1; Fri, 06 Jun 2025 09:24:54 -0400 X-MC-Unique: 0DEEa_b7Pz-aBXTD0-eL4Q-1 X-Mimecast-MFC-AGG-ID: 0DEEa_b7Pz-aBXTD0-eL4Q_1749216294 Received: by mail-qk1-f199.google.com with SMTP id af79cd13be357-7c5d608e703so404787485a.3 for ; Fri, 06 Jun 2025 06:24:54 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1749216294; x=1749821094; h=in-reply-to:content-transfer-encoding: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=Ky+WeROHZ4Ae+uVfELGBGltSg87Rkj3Uw9xYsa9j3qg=; b=r+YvTSa6s06fOiR/OjVGBlTYymLkXnTt1QqREup7Wotht0MBed7db/+cUt5hx0tCYa IAY+TlaZje4ox31jaZ1jWM8EPDWewxlmvOX7pW4iu150KyT2Fj24rKnkuoBbE1CyEPCW AXk/22rtvFGeuGuHO4UIWDVzvGsgg/GlIg1slzKIH8LG2flGtfvj8aoR/ZQwJFAxDOw5 0/IrzPM7k19KpGFuEQ2PHZXN/eaJ2+Q9YX+coXLDx0jLdDqH2qdcdwl+HqAdcd+jFDyu xGRqTnU3q6ztgUiwXEn/MD+hWJDzq/NvgnF58aWt3CosfXH/V6Mf1ssMEkumR4YKsjNU nSZQ== X-Forwarded-Encrypted: i=1; AJvYcCV8wZmswhjVgwdkob7MRwycNz1nOI17GI8OarzpsuJ4arWDM/u+yQRZImRE9if6EuHO6KJoqcKu/A==@kvack.org X-Gm-Message-State: AOJu0YxP1aIcJmNWO+pxRjrGE4xaeFzkAIH7bidG+EQce3ccyfNz2tO3 /9iFQ+gEFpPfvYUqxibydnanEgk1bAOq6eU1CJthy38lghwPUfq6Ai5X76gS4FNE2yZTe2TKCgl tSbg1ewXH7IxmA8OHSsDDbMB0ClPKuIxNn+MEs7Uyy0QG9u9jI/bb X-Gm-Gg: ASbGncsi3UgNFSDSJ6ymyW26+1nWC9MtbIs9kCoqvRCvBWNy1BpEn1hZ2DNTGB5KEgh oiGuBrut2cThdUElxvMEuxLPWgRulWu7lXP+rlosZnrdHBLhxHuwn1+ChXVrqTuKzWRTa6sjD0Q 9BE6+uumsX5rENaP97hnwCjMtAUMBNEgW60pN9Ey00Ol2qQ+qSFlbVE5GeJe0rGLEO6FHHnFoCu ax6wQuikAZ26iAvPDkw+tTspytE8ZRc+l1XrZH9pkwrdwVKUaeW4mvsqBeklux/lLqD3dYHKfy1 CR8= X-Received: by 2002:a05:620a:2608:b0:7d0:9688:b650 with SMTP id af79cd13be357-7d22990277cmr623270385a.54.1749216293748; Fri, 06 Jun 2025 06:24:53 -0700 (PDT) X-Google-Smtp-Source: AGHT+IHyw7rhIbtMEbMw7aXS5kBcEv8c0niayT/VMXPsAHzS6JTC/rav5RqlYy0t+iQ6S4rhlqvdfA== X-Received: by 2002:a05:620a:2608:b0:7d0:9688:b650 with SMTP id af79cd13be357-7d22990277cmr623265985a.54.1749216293377; Fri, 06 Jun 2025 06:24:53 -0700 (PDT) Received: from x1.local ([85.131.185.92]) by smtp.gmail.com with ESMTPSA id af79cd13be357-7d25a5948f8sm129289485a.49.2025.06.06.06.24.52 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 06 Jun 2025 06:24:52 -0700 (PDT) Date: Fri, 6 Jun 2025 09:24:50 -0400 From: Peter Xu To: Tal Zussman Cc: David Hildenbrand , Andrew Morton , "Jason A. Donenfeld" , Alexander Viro , Christian Brauner , Jan Kara , Andrea Arcangeli , linux-mm@kvack.org, linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org Subject: Re: [PATCH 2/3] userfaultfd: prevent unregistering VMAs through a different userfaultfd Message-ID: References: <20250603-uffd-fixes-v1-0-9c638c73f047@columbia.edu> <20250603-uffd-fixes-v1-2-9c638c73f047@columbia.edu> <84cf5418-42e9-4ec5-bd87-17ba91995c47@redhat.com> MIME-Version: 1.0 In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: k-Dw6latOLVp7uCY8hTmqzJcJhnH9E-51RY08MzJvhk_1749216294 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 13C2F12000D X-Stat-Signature: mm4uq75eb58ndi8f5jg4zf7q5gw79eid X-Rspam-User: X-Rspamd-Server: rspam07 X-HE-Tag: 1749216295-799535 X-HE-Meta: U2FsdGVkX1/7IhkTr2zCGeOIYopr2xxPcy1HNx8rQM6KlXmhf9rNUB+ECzhR19bGhaMJkAR8hMpNLTaTO/L/SWNrlFjEQPopWiVniPL11/ptind6lb9VXnAKMGOqH9fX5i/9gvtmqiVwuK8uYwgcw9js1pJrCrH5A+lk2/zhkIlsBHblmMEzvVIPonelbSLM1Wcggk7Rk+KdBI2+Vcqvpj6VOKDiENLY9wfMFxadCfT45+Va8I+flx2BDdKC9xWoRKIjtLXfBmI7FStWD8atcgU+H8zci4iwVJDoBMtqHyNSkZCnLX9ljlESUiROS+L4xxxaFU2oZVUlSouQTq2kNxaU5riBWbvX0gVodvcamxiOuEX/CyBkzXuNGm4oUBOFOwKP0Ip3WW0+K0r9CUjO2zwcolTG/ZYkl28G9cObNX73NDLrNmJgJHLCaMLpRlijPdn8hGHw6E1PSq228a8/uWq6+XoRhWJcsatW76CEPA7nsvmUAFLnJl1oKCdLEXuA3nkNo61R29gHJ28cRTtIDhs2zGksBdlHvSDKIVATP7Yed9AAy62NP2gnIqel02on5eGckHPE5prJLSUm6RkvHZCe5QMe6weCuFzsmxuYQ9k8DHAgN602GLuphtcIWDVHxQwEmrtfFxP4yh4w03WoebsBw+FRPf/QLg67Q1/7D6ITXOMDVWbKdFEJvXyBD0NnBjTIT8RdYBuArVN5/y6+hMcFXH9JMhCtKOaOerP+Jn6g9CvVb3Rf/FGNTRAzWvQ1AhSHLHxaf/52ybfhZ+S+dBL0ROlitjca+gqJ1sVaMwmI3kfb4mOIRAXDFt+jxDDYgt418DeJcdfhVUZ6kiV0STEH0Iz4rEDTmT7jIe1kd6nc5GqGrFdt4RH5zEBO1ZTsSeATtc8BFbTxf7FxAWb4i0Rld1+KLbVK7AFBgxQT2DZXhohCR/XNPEQ2wspAPLiH91kNlGp12ZIUs4PLTS/ +9xhFq0N 93wEwpAunlhA3OfuyLwCm1Zd86zu0P/asi1kBvSphuP+iXLMnnqHVogeig64ywXHEWVbgt/1ML6DZtc1nzvwDYffX64OWjdFfQislkcGijZZJI2sislm81FB3ouNFUsHAYpKpu/QzFsvyzeGiT2nqtu5JgBF5+XuZ4xXW3Y2qoi0kv0jdJLgX0t5PhdrgmCasTv6D/kkz9TbZf/wuH8uyzBIsE8SmGXLFA/FD77SEflm+MKhI51Dpg80aUEh/qKNjW80enklSPwYVGJKX84yOQ8NOoLygmEv+IJGmbacoJ0K59Y1lbQg1mp3xsMpKGlrL0qzjMGQn5j+LVb1JRENO/mH9xq54/0gi5uPgJnM71WNrt8ZIjewLcYQFajmJ2XW0f82bIMH0lxFxkb0= 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: List-Subscribe: List-Unsubscribe: On Thu, Jun 05, 2025 at 05:11:53PM -0400, Tal Zussman wrote: > On Wed, Jun 4, 2025 at 11:10 AM Peter Xu wrote: > > > > On Wed, Jun 04, 2025 at 03:23:38PM +0200, David Hildenbrand wrote: > > > On 04.06.25 00:14, Tal Zussman wrote: > > > > Currently, a VMA registered with a uffd can be unregistered through a > > > > different uffd asssociated with the same mm_struct. > > > > > > > > Change this behavior to be stricter by requiring VMAs to be unregistered > > > > through the same uffd they were registered with. > > > > > > > > While at it, correct the comment for the no userfaultfd case. This seems > > > > to be a copy-paste artifact from the analagous userfaultfd_register() > > > > check. > > > > > > I consider it a BUG that should be fixed. Hoping Peter can share his > > > opinion. > > > > Agree it smells like unintentional, it's just that the man page indeed > > didn't mention what would happen if the userfaultfd isn't the one got > > registered but only requesting them to be "compatible". > > > > DESCRIPTION > > Unregister a memory address range from userfaultfd. The pages in > > the range must be “compatible” (see UFFDIO_REGISTER(2const)). > > > > So it sounds still possible if we have existing userapp creating multiple > > userfaultfds (for example, for scalability reasons on using multiple > > queues) to manage its own mm address space, one uffd in charge of a portion > > of VMAs, then it can randomly take one userfaultfd to do unregistrations. > > Such might break. > > As I mentioned in my response to James, it seems like the existing behavior > is broken as well, due to the following in in userfaultfd_unregister(): > > if (!vma_can_userfault(cur, cur->vm_flags, wp_async)) > goto out_unlock; > > where wp_async is derived from ctx, not cur. > > Pasting here: > > This also seems to indicate that the current behavior is broken and may reject > unregistering some VMAs incorrectly. For example, a file-backed VMA registered > with `wp_async` and UFFD_WP cannot be unregistered through a VMA that does not > have `wp_async` set. This is true. Meanwhile it seems untrivial to fix the flag alone with the prior per-vma loop to check compatibility. We could drop the prior check but then it slightly breaks the abi in another way.. Then let's go with the change to see our luck. Could you mention more things when repost in the commit log? (1) wp_async bug, (2) explicitly mention that this is a slight ABI change, and (3) not needed to backport to stable. Thanks, -- Peter Xu