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 33E47C5AE59 for ; Thu, 5 Jun 2025 21:06:55 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id BDDBF6B00E0; Thu, 5 Jun 2025 17:06:54 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id B8CEE6B00E1; Thu, 5 Jun 2025 17:06:54 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A7CA06B00E2; Thu, 5 Jun 2025 17:06:54 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 87A036B00E0 for ; Thu, 5 Jun 2025 17:06:54 -0400 (EDT) Received: from smtpin13.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 332A6120AE7 for ; Thu, 5 Jun 2025 21:06:54 +0000 (UTC) X-FDA: 83522581548.13.821AD12 Received: from mx0a-00364e01.pphosted.com (mx0a-00364e01.pphosted.com [148.163.135.74]) by imf11.hostedemail.com (Postfix) with ESMTP id B8BB64000C for ; Thu, 5 Jun 2025 21:06:51 +0000 (UTC) Authentication-Results: imf11.hostedemail.com; dkim=pass header.d=columbia.edu header.s=pps01 header.b=Yey3F62d; spf=pass (imf11.hostedemail.com: domain of tz2294@columbia.edu designates 148.163.135.74 as permitted sender) smtp.mailfrom=tz2294@columbia.edu; dmarc=pass (policy=none) header.from=columbia.edu ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1749157612; 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=+4t+B2pD6+kpWYFt+7p6MEr09BsrqvjyD3ljU+axPAs=; b=pXD+ASFtKl3uEYJ0CHwcnfycLLViSNFeb1K8byzifqUd/OYndQI/V3jdAsufxA2u37xRTF 9cq+Pmm8I6Xn4gnRN2thCVHevYRFvESKR/+eZjolhc7GAPRjaLi3bp5uTXoVv0Bqybtq+P wIb/D9WbNZiYY6pO0WalCj24Ns3a/LA= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1749157612; a=rsa-sha256; cv=none; b=i95HBmfw/wvXxD3ogwz+ALUYO14WpCetIQ1buGLeN+spB6mhTdyUx10ZcAJfe/A3c7jlqH gGsnxcSKfvNCAXQU/wIspX6uw1XXg5PoFkAWgm1iY/VTq6A6Q9G8aWdw/SMMKgwtTzdcZ3 pLWC0+NmiKSYXYFnWxUjKN8RPRDk9bo= ARC-Authentication-Results: i=1; imf11.hostedemail.com; dkim=pass header.d=columbia.edu header.s=pps01 header.b=Yey3F62d; spf=pass (imf11.hostedemail.com: domain of tz2294@columbia.edu designates 148.163.135.74 as permitted sender) smtp.mailfrom=tz2294@columbia.edu; dmarc=pass (policy=none) header.from=columbia.edu Received: from pps.filterd (m0167069.ppops.net [127.0.0.1]) by mx0a-00364e01.pphosted.com (8.18.1.2/8.18.1.2) with ESMTP id 555L4jNZ006363 for ; Thu, 5 Jun 2025 17:06:50 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=columbia.edu; h=cc : content-transfer-encoding : content-type : date : from : in-reply-to : message-id : mime-version : references : subject : to; s=pps01; bh=+4t+B2pD6+kpWYFt+7p6MEr09BsrqvjyD3ljU+axPAs=; b=Yey3F62d/5thvpoAv6BWRhQU/VKUic/00d6QzVimrbhapPndDLIpzXHGS8nHmUtl0jXA YhNEAKuRQ8Y6IaQPHTykjONtEc+sV/yqaO3WtY8xMnzTBHuTarUIln5qzsZDEZDPzAVz I/hAJ6yAhWHvpgWGcx/70hpqxvpkyoSOPHr5hXmtTvlVgedIiaXJ+nU/p0RmCibi6+s2 WFoAOgKW7I4DoOCaU328I+w9pDL2imFr0ekT5FgBlD4KHTHXsSUTMLFTYr7SjRvdYOdD dYpPEPv0goao46pP1kQhEohXeJl9plropxI8ZaiMsmYny6I3vmM06aSb1zuowzib7Sy8 Zw== Received: from mail-yw1-f200.google.com (mail-yw1-f200.google.com [209.85.128.200]) by mx0a-00364e01.pphosted.com (PPS) with ESMTPS id 471ethcxbr-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT) for ; Thu, 05 Jun 2025 17:06:50 -0400 Received: by mail-yw1-f200.google.com with SMTP id 00721157ae682-70f841fb19dso17683367b3.1 for ; Thu, 05 Jun 2025 14:06:50 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1749157609; x=1749762409; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=+4t+B2pD6+kpWYFt+7p6MEr09BsrqvjyD3ljU+axPAs=; b=Hi5CasGqZ8QjpDtuoFvNQiU9VVhuvUBdOOESglaANDCMWzyIbb52hmCdz5+PeFVdq2 3a8u5vKCBE8fORqNQJ/FcoQOivdqtDJr1tikP+LydGiewaBSJsZjFQjPVqpddweGk20Y f4TsWG5GW2/k+KjCNfQznH4B6spMI6S08n5OF8b1v+3dl8f7ZvjMdtBBNjFCPj8AvOTP xPVKLL/co8FPAth2QqkLLC2ydzweTcQzJPRH6V8lgEQCNEyN/7EXw3ZrLFnzGetRtu7O AnvxLPxV6XHHSsdTmy0PYLT23+LuWW+ao1oKfYaEd80QU7HLV46Ws91ChkqdFaFRSgVv 1+uA== X-Forwarded-Encrypted: i=1; AJvYcCXZvSF3onelDA1OUodrHY1xmFBTrYJ2Tzp0+GsxzTjiuRxUg1ZbI7PamLBrx977Dll6HKq0+j/kCA==@kvack.org X-Gm-Message-State: AOJu0YyQven5ThCciKuy7smjF5juSGrfc9x1tg8Taj8hG8USr/AO6X+g Lu47kXEH0pWUI06dOKawh78ijL33sNKYX3oo2AUOrZddLcQhBtkQxqOal4axTs7VcOutoLJ/HVR tqJQA5qgaaK1SiPt5gRPZAGW54WNdFmwJ9R7VBfzjZg0XKpZq0T60B3c34SAEuSqkWew6Zezeh2 1yIp0DQnpE8mqq29MDclO0sGE= X-Gm-Gg: ASbGncvGB3+gKyRFEEcW22l1RXxaGXtO6lXLRWwJR26UFDvnqS/BaVXPnIfQOAAtQlV Hp3+MvICLYPqEMoV+eG+nFfKZLVZsREvZVC0eP+JT8gO0WXZbXpIhCLgxG4+cRtlOnl/FCnevMn FPjJi5 X-Received: by 2002:a05:690c:3685:b0:6f9:7a3c:1fe with SMTP id 00721157ae682-710f776cc31mr13836907b3.23.1749157608936; Thu, 05 Jun 2025 14:06:48 -0700 (PDT) X-Google-Smtp-Source: AGHT+IHFpswqCHFSqwALooH+sBikcUL5B8njFjFNXDocdSyUUxkugwfcle1F23KSlnDph3jsu+K0GvNMwj824P5EaQo= X-Received: by 2002:a05:690c:3685:b0:6f9:7a3c:1fe with SMTP id 00721157ae682-710f776cc31mr13836337b3.23.1749157608327; Thu, 05 Jun 2025 14:06:48 -0700 (PDT) MIME-Version: 1.0 References: <20250603-uffd-fixes-v1-0-9c638c73f047@columbia.edu> <20250603-uffd-fixes-v1-2-9c638c73f047@columbia.edu> <84cf5418-42e9-4ec5-bd87-17ba91995c47@redhat.com> In-Reply-To: <84cf5418-42e9-4ec5-bd87-17ba91995c47@redhat.com> From: Tal Zussman Date: Thu, 5 Jun 2025 17:06:37 -0400 X-Gm-Features: AX0GCFstPrjtQYpw6EfTjM-xcC75nUUqJYkys8M1u1GJ2SLteZ0JyCXfVm1EAzM Message-ID: Subject: Re: [PATCH 2/3] userfaultfd: prevent unregistering VMAs through a different userfaultfd To: David Hildenbrand Cc: Andrew Morton , Peter Xu , "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 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Proofpoint-GUID: p4Uyr3oAHTwVmuujOfx4exZF0g4mxZxq X-Proofpoint-Spam-Details-Enc: AW1haW4tMjUwNjA1MDE5MSBTYWx0ZWRfXx6ZeUZCFTvQG OI5OxazrBYLgpGH5fzCcJtquLQJx3uEOAXozteLUG0ks79RXWOYl+eyKmzD2aLX90h9ba5jp2xM qLkxDIjLqELa1BWKlbiZV5oXELVfjBgItOcndEst/8pyasZBnng0KCuDaHgpdNXMTx98FYZxrTo TJNf7ImPV2sSLLpTDZF48pZ/ET8ZRaXOoPecaSEMDPm6453BSau9JZAxelvh2i4+l/A5tH4YIF7 FXgwuoEtYLSAbwaPExcFD85+VwgnaHFzASpkTGSB6fVXYC+As+ac7ebEELNG+Bjme7+tBMMOEd3 bU47b3TfEy0qQvJAeVTWxH9OLge8FvPgsI+WJnwq1smXhwXgN0qIXjuSp7Cqlx2PFOPnosAW4WZ Z7T9nip2 X-Proofpoint-ORIG-GUID: p4Uyr3oAHTwVmuujOfx4exZF0g4mxZxq X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1099,Hydra:6.0.736,FMLib:17.12.80.40 definitions=2025-06-05_06,2025-06-05_01,2025-03-28_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 malwarescore=0 impostorscore=0 suspectscore=0 lowpriorityscore=10 phishscore=0 bulkscore=10 adultscore=0 priorityscore=1501 clxscore=1015 mlxscore=0 mlxlogscore=825 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2505160000 definitions=main-2506050191 X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: B8BB64000C X-Stat-Signature: b6ixsy939geqoezxrn8k5iutnugurdpc X-Rspam-User: X-HE-Tag: 1749157611-83405 X-HE-Meta: U2FsdGVkX18fdC27C4dUEAwAgdPPM9n/mb+VfalsmzbEzuLi8IJ0Q3Il7vXhUuvDk3V43fTcS0NBehq+wF/I91BneeorCYKLxYlhPGv3BpWbqqAhOUHlBeLvjmPQPNAG0rVieeQ4tlXZbU7/ydWzc75DJFN3WxA7XMp/fHOpH90nYufiRsBRTxAH/6NbSU1YkwqWj1v1pIv4FlaHXcvOJd8Az1tmG5kFPntoca4XEASfD1XUw41CvDLjehZJmIdk9DQbAMh+jHdGUBMjhvZXlNkRSPJtMd1kKWffUyjVJbjxvTY3Ki/S85pom+3LiJMqgNVmipqJyp4NoQQwSej2Si2EsC4P47iney1zaCrI31b84hWQGvODGzDp5+JpgeP2MjGiD6b6aOKrW5MXMYIeymTsFKUEcZuFqtP5BednKq3CuFKC06jAhmpwnD6HBk4kr43/lDaxCOE+JdZ51bq61qZOrK8xaqpKqipa1k+B+ziU6pDMnEVoOuLLiNBvXCNE/XzNZ044tkyX19LJnurd+k9H29JzkhJv7sspvFxoHPdAsnZ+QHswASPPrg4Rhxx9rMdfW8DZND93ABySsEOxZNwBQ0frmBlSDgmKYoWplcS/yKQ4C6gD9Kq0aVbm9ijrkn1p0lYV+GsWNW6wNzKKTgBmDXh4qZqee2QE00yWIOxacBpDOflPVKkw9MO7ffwm1zArKlGci+QiFBRKuCQRNfy/wkm3ulBX4MT/COObiCJa1SMjQGkbTmueZNhic9tFLOXVCLWMm2Y50AFLQ0I2qJieE2xdKBvitAaGGnN3vCYaZWXIvhQPJtsct9uiLhMgfdNWoq+0OhlK1c+kESklPTOm/ystyVAUMBOA/OQqqoo+xmpeCYdwUbmUnFuvK10dF8AHPmkquwpIddg1y2Oh8VOunATdUlCy 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 4, 2025 at 9:23=E2=80=AFAM 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 unregistere= d > > through the same uffd they were registered with. > > > > While at it, correct the comment for the no userfaultfd case. This seem= s > > 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. > > > > > Fixes: 86039bd3b4e6 ("userfaultfd: add new syscall to provide memory ex= ternalization") > > 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 userfau= ltfd_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 !=3D 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 =3D true" in that case. Maybe it's fine, just > raising it ... > > > + > > found =3D true; > > } for_each_vma_range(vmi, cur, end); > > BUG_ON(!found); > > @@ -1491,10 +1501,11 @@ static int userfaultfd_unregister(struct userfa= ultfd_ctx *ctx, > > cond_resched(); > > > > BUG_ON(!vma_can_userfault(vma, vma->vm_flags, wp_async)); > > + BUG_ON(vma->vm_userfaultfd_ctx.ctx && > > + vma->vm_userfaultfd_ctx.ctx !=3D ctx); > > > > No new BUG_ON please. VM_WARN_ON_ONCE() if we really care. After all, we > checked this above ... Yeah, I mainly added this to maintain symmetry with userfaultfd_register(). I don't think it's really necessary to add this, so I'll remove it for v2. I'm happy to send another patch (preceding this one) converting all of the pre-existing userfaultfd BUG_ON()s to VM_WARN_ON_ONCE(). Although I do see that all uses of VM_WARN_ON_ONCE() are in arch/ or mm/ code, while this fil= e is under fs/. Is that fine? Alternatively, I can remove them, but I defer t= o you. > > /* > > - * Nothing to do: this vma is already registered into this > > - * userfaultfd and with the right tracking mode too. > > + * Nothing to do: this vma is not registered with userfaultfd. > > */ > > if (!vma->vm_userfaultfd_ctx.ctx) > > goto skip; > > > > > -- > Cheers, > > David / dhildenb >