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 24F0AC5B549 for ; Wed, 4 Jun 2025 15:09:43 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id BA2BA8D0023; Wed, 4 Jun 2025 11:09:42 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id B78E38D0007; Wed, 4 Jun 2025 11:09:42 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A8F4E8D0023; Wed, 4 Jun 2025 11:09:42 -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 8AD7E8D0007 for ; Wed, 4 Jun 2025 11:09:42 -0400 (EDT) Received: from smtpin22.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 1B5921D7277 for ; Wed, 4 Jun 2025 15:09:42 +0000 (UTC) X-FDA: 83518052604.22.3FD7265 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf13.hostedemail.com (Postfix) with ESMTP id E73D020007 for ; Wed, 4 Jun 2025 15:09:39 +0000 (UTC) Authentication-Results: imf13.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b="VKuUf/pf"; spf=pass (imf13.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=1749049780; 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=K0Z14f5Dv0sEBCQzCT+N5xWNS5ySL+Tzir6TJSSZ+3Q=; b=JJemNsJWTV/7JvF0RlgDcWXDMLcDF8kTmuS9r8Ic3eu5thHPpfUeOuzGpn7hdC8UNs8j3Q QwG6IcA9q70QCAFv0yyUPMAJyk45ndWmoGRleUzJy3MEXGOnzepbAKjp63wwaloyyXB/zH pjF53IKu6rLpYBNiCtL6SK9423qFegY= ARC-Authentication-Results: i=1; imf13.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b="VKuUf/pf"; spf=pass (imf13.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=1749049780; a=rsa-sha256; cv=none; b=D+By6bIj6pDWCG5uPX8N6DX4/vkbvdc+qfBu+WNbFfwHfku8N7ZNEESXKACvvXDpfItYZW X4S9a+OGf+Ir5lr1xG/R2UxRxxQl07klxRTk+QageSwJWxWXCpY5ODUeb9HAeJ6P7ya9nJ 8Hv7qI3zt6g8IwI5hN0XqbrA1bDSScc= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1749049779; 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=K0Z14f5Dv0sEBCQzCT+N5xWNS5ySL+Tzir6TJSSZ+3Q=; b=VKuUf/pfa26X80l9Rd/AcS4UsnbZzSqMto86xBWUQ7YCnPccn6YZZUiYaDedgChZeTlhgP 1Obu+0qOKq0rTnNu9KvyRQsirQa3pxSJpahIEXAdJ3Gf13h4IevBHyPVeg5z7tqHjusF04 6ZBpu1dWulmYlQ8PB2CUttWNzUDvwHc= Received: from mail-qv1-f72.google.com (mail-qv1-f72.google.com [209.85.219.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-410-5WdsyihsOdOMhyXlfU61YA-1; Wed, 04 Jun 2025 11:09:38 -0400 X-MC-Unique: 5WdsyihsOdOMhyXlfU61YA-1 X-Mimecast-MFC-AGG-ID: 5WdsyihsOdOMhyXlfU61YA_1749049777 Received: by mail-qv1-f72.google.com with SMTP id 6a1803df08f44-6fafca0971cso303776d6.0 for ; Wed, 04 Jun 2025 08:09:37 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1749049777; x=1749654577; 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=K0Z14f5Dv0sEBCQzCT+N5xWNS5ySL+Tzir6TJSSZ+3Q=; b=MHidZuPoneroWxNfHZJFFPAd6GuQHP99xFo6Ix4xGrAMpQZ16CzjbRFJF/T+gj2K8a 9fIQJIeL9DtHZE2goRbrgFF4QKutgKGUlNTesEuhLtWbExZ4bKXULBDCDVurCYmzRA6q CP7VWV8OlIavjVmL+xJTkj9e9vz70IhzVuJIlrB88vrMoab3R/2uchQlbmfdGLEBAZ9e fnH3n3HriTO0LwgyWIB40k8Me6lor/nTiLwHX3UkAEpQDzbkdR2caRYsil+PIuTYWEv5 6HGoTkZzN3SIDTFF3I7dNFD/IrTWDo40625Q4bip1jqLtBhdwQu8ptVDjdpGVF/P6cB9 9CIQ== X-Forwarded-Encrypted: i=1; AJvYcCVqJofkfEvlvn6QWGwjm5NVRMVMSMfwkQTeu+PdHYjeoWqcqYEwI/rGLltfJwrOXMVv8ZhSgHEPSg==@kvack.org X-Gm-Message-State: AOJu0YyX7qj9OZoFeY9bQDHDXL1XK/+MpxTF3DWSmyH7hnhP8mwyftJ1 CsUSJ9Za89Z5gYXH5+k4+bHQUulrNKFxaFEPeXbHvzRWihhZa2YLL/hn6mDPVHKzSdQIKPDioVH Y13YGU1ybe1yknyf2meiyJCTseSXYNLkEhS8L4J9pMls74faU89dW X-Gm-Gg: ASbGncsgbnl+hfnWZym6/hr4JyDOYbQN0d/1NX6dZNwSLGF55bB8TR4aEM7dqf1CZTL Nu6ceWim4J6bBpETvRTYjzR72sWjKN3ZeWzza1UqoAYQXW5l2PDzkUh6O7HQcEgSPjmcM02uLG6 +YS4LCJIc9Ha/GyKF0NCaupUyKZWAudIBuxpAzUSe6fe5H/wyvr1sYmmUh19/iDc0YqGJxldDwh 3zZ9vnbsW2juKKIOCY4I7S6PRRGTPi/tFc7x2Tig5uvINkfv4fXN4LJfOZKX29yDUugJw1EeA9l aCK/HSs2eydFAg== X-Received: by 2002:a05:6214:5086:b0:6fa:ce1e:3a4a with SMTP id 6a1803df08f44-6faf6f9312emr40237276d6.6.1749049776343; Wed, 04 Jun 2025 08:09:36 -0700 (PDT) X-Google-Smtp-Source: AGHT+IFSDUs50177E/rrZpx+xC+0iIv+BIQc1aieeX4oFfx7XS0nPA0qJB8ecAAJUv8L53J89ePgrw== X-Received: by 2002:a05:6214:5086:b0:6fa:ce1e:3a4a with SMTP id 6a1803df08f44-6faf6f9312emr40235876d6.6.1749049774940; Wed, 04 Jun 2025 08:09:34 -0700 (PDT) Received: from x1.local ([85.131.185.92]) by smtp.gmail.com with ESMTPSA id 6a1803df08f44-6fac6e00d42sm99700586d6.85.2025.06.04.08.09.33 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 04 Jun 2025 08:09:34 -0700 (PDT) Date: Wed, 4 Jun 2025 11:09:31 -0400 From: Peter Xu To: David Hildenbrand Cc: Tal Zussman , Andrew Morton , "Jason A. Donenfeld" , Alexander Viro , Christian Brauner , Jan Kara , Pavel Emelyanov , 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: <84cf5418-42e9-4ec5-bd87-17ba91995c47@redhat.com> X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: iApyzYxRYL895w-OBSFgfTrxdt-mIktKoVeb3C1OwUw_1749049777 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit X-Stat-Signature: oaqx3dnu7oawua5s1pux34bukoy1tckf X-Rspamd-Queue-Id: E73D020007 X-Rspam-User: X-Rspamd-Server: rspam02 X-HE-Tag: 1749049779-486656 X-HE-Meta: U2FsdGVkX19dkLXV2v+u078v2YaL7Roxpu95yxHsGbMIDcyYFIkdBgwGK+Q/93Afgqu0EmB3dY5+hdxy4o/01BXi2u2dz/5ALs64G/FCPMsvw71STLJTOgHbDupl6yDIhK2zOeo0quTRWuFTj33I3y//TX2afbK7Ts074wVgVicxefQvulHxEGjpRa2a8COQcT5pWqLh+PhA45HlfSQvE7kKvjVyf96CK0g94AHL1TnLDXWU1rdzWiql0wKps4qIKW8GRZFySpjfCwqSiOJt59wSgAhH1KJFJnTGAtRHmTYGQYScNjBrZpdJ+YzhQwZGa2Hew5FcmggSW2WQXs3aeQbDvJGRG/vUKW5RjEKVKMhXTvqhPRIEFB2RDJnfes8hDfxzDoWR7LJDiCKxT8EMIxvnLj4g/Er6i0oqnRqSGwMovAW8uvPmxJqd+NnALyY+uEAgvXNWdGNM8lPozQV6Y/Je9cvPz9QZk35ovClCz4pdgU7h6/S9ORqsGAxQFX5OPS/YGn8uzrj6Vto1QxSy3VDNDxs9XkN2N2Q+09fjiNJ7+r/7rXbhJkz9BbdraGelfoZcibKLC0b6RN5wABLwHT+RQ9pPqwPUa35qgYn6iQG7xKLKhtIIQIrlS2X9Q+ovkvb2BoNVXqlo9pR4sZki+4+qBrSm9w+Tn7MeeCf7dm3rKC3qHcykwwlkPwsBxngKuookx7f+cjicMKiLqIOUnpUua1pzTVCJAfxRlJo1hhpPU0i4GZPzImKD+dCoXrgncAgi1LRC04pVeeBjDluZOroS76Vs1MfB/P+b77S1E+l0TjEl8Ok07uii69Q9TGawDyERLwqH6UqtrA+8BwoSAdeOcKntZYXuGRyhQQMih4MrV0WegR6ehSbtz9qm/3rZOJtZ76p2s/K3oGD+gu9lqUgPRKWokz7BL4p5Ege3VGYZadtuxqbpH/iwT+YOIz1UiliiUpea2YgAANtlK9u iv0o9Sh4 JIEno 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 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. > > > > > Fixes: 86039bd3b4e6 ("userfaultfd: add new syscall to provide memory externalization") > > Signed-off-by: Tal Zussman > > --- > > fs/userfaultfd.c | 15 +++++++++++++-- > > 1 file changed, 13 insertions(+), 2 deletions(-) > > > > diff --git a/fs/userfaultfd.c b/fs/userfaultfd.c > > index 22f4bf956ba1..9289e30b24c4 100644 > > --- a/fs/userfaultfd.c > > +++ b/fs/userfaultfd.c > > @@ -1477,6 +1477,16 @@ static int userfaultfd_unregister(struct userfaultfd_ctx *ctx, > > if (!vma_can_userfault(cur, cur->vm_flags, wp_async)) > > goto out_unlock; > > + /* > > + * Check that this vma isn't already owned by a different > > + * userfaultfd. This provides for more strict behavior by > > + * preventing a VMA registered with a userfaultfd from being > > + * unregistered through a different userfaultfd. > > + */ > > + if (cur->vm_userfaultfd_ctx.ctx && > > + cur->vm_userfaultfd_ctx.ctx != ctx) > > + goto out_unlock; > > So we allow !cur->vm_userfaultfd_ctx.ctx to allow unregistering when there > was nothing registered. > > A bit weird to set "found = true" in that case. Maybe it's fine, just > raising it ... This part should be ok, as found is defined as: /* * Search for not compatible vmas. */ found = false; So it's still compatible VMA even if not registered. It's just that I'm not yet sure how this change benefits the kernel (besides the API can look slightly cleaner). There seems to still have a low risk of breaking userapps. It could be a matter of whether there can be any real security concerns. If not, maybe we don't need to risk such a change for almost nothing (I almost never think "API cleaness" a goal when it's put together with compatilibities). Thanks, -- Peter Xu