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 B4F5DC71157 for ; Tue, 17 Jun 2025 20:50:38 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 535166B0088; Tue, 17 Jun 2025 16:50:38 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 50C4F6B0089; Tue, 17 Jun 2025 16:50:38 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 421E36B008A; Tue, 17 Jun 2025 16:50:38 -0400 (EDT) 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 31C636B0088 for ; Tue, 17 Jun 2025 16:50:38 -0400 (EDT) Received: from smtpin15.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id CA541140CEA for ; Tue, 17 Jun 2025 20:50:37 +0000 (UTC) X-FDA: 83566086114.15.6E10E85 Received: from mx0b-00364e01.pphosted.com (mx0b-00364e01.pphosted.com [148.163.139.74]) by imf16.hostedemail.com (Postfix) with ESMTP id 821AC18000C for ; Tue, 17 Jun 2025 20:50:35 +0000 (UTC) Authentication-Results: imf16.hostedemail.com; dkim=pass header.d=columbia.edu header.s=pps01 header.b=r2Drjo8u; dmarc=pass (policy=none) header.from=columbia.edu; spf=pass (imf16.hostedemail.com: domain of tz2294@columbia.edu designates 148.163.139.74 as permitted sender) smtp.mailfrom=tz2294@columbia.edu ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1750193435; a=rsa-sha256; cv=none; b=F1frbnC+znVjLGmXbxm4vlN+6LiL4NZxS3swCqqA0kVF/EPNHsfWnNka3p6nSYAkjHo9Dy jVDN2mCl9h6NlzweWX7Y7+TagCOsdiVnOSBv65Mb5HrH7lF0T+pS1mUyrkeQ4CnfZdDesj CR5EPkq9jegVgrz26mWC1Z7RL9Yycfg= ARC-Authentication-Results: i=1; imf16.hostedemail.com; dkim=pass header.d=columbia.edu header.s=pps01 header.b=r2Drjo8u; dmarc=pass (policy=none) header.from=columbia.edu; spf=pass (imf16.hostedemail.com: domain of tz2294@columbia.edu designates 148.163.139.74 as permitted sender) smtp.mailfrom=tz2294@columbia.edu ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1750193435; 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=kHRW9Nu+63/GeEfAZ+I+V+utb3fXU8IH15wFHQNM6f0=; b=RYHOlTiGCVJItA3wJaVGg9MpY/S0FOQF81C73grzIUsPu9TdEC7vpQaeJUXwOKCB3uQjJW 7DLyIZuqLuh1gSBYPyfIiJzazisF6/Nk727Di6VTwdeeSKZhld3J2Lr/hgQNJw8vqXkt9q 85AL3pHEJR8Q7wZyDG1wgZtG877pM4I= Received: from pps.filterd (m0167075.ppops.net [127.0.0.1]) by mx0b-00364e01.pphosted.com (8.18.1.2/8.18.1.2) with ESMTP id 55HKFaLd026619 for ; Tue, 17 Jun 2025 16:50:34 -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=kHRW9Nu+63/GeEfAZ+I+V+utb3fXU8IH15wFHQNM6f0=; b=r2Drjo8uUKd73xclv/tSGiKeaCM7vYKjKI+7iApuS8jqigfIFZCpuinH4uB3tdRDHC57 GjjLWhbucWERq+YBbNnimo9857Um/sB/5XhvIaFznS8ZrvzqJIozCTt6rz3oGlG6f/TV cJBiEMZB2+OkPrf8SQPuCVSIy4QbFD9W/9BM40mMbRvqpB74vbwIbTX59LkvlQ0qlNaW K+auqpCP9ZLLa0eE4Amfxn2SI6gROwf16PYnPGO/YEYp6MM4y85qZVoh6saIjPKnNFTp wKf0PlnR0LBLq0EsKMhNsFAcPXHlBPa+qFgQJUdwbeCPwI8YFGK+zBh9cN3Mt8UTvE1A yQ== Received: from mail-yw1-f200.google.com (mail-yw1-f200.google.com [209.85.128.200]) by mx0b-00364e01.pphosted.com (PPS) with ESMTPS id 479p7p6215-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT) for ; Tue, 17 Jun 2025 16:50:34 -0400 Received: by mail-yw1-f200.google.com with SMTP id 00721157ae682-711136ed77fso76142797b3.0 for ; Tue, 17 Jun 2025 13:50:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1750193434; x=1750798234; 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=kHRW9Nu+63/GeEfAZ+I+V+utb3fXU8IH15wFHQNM6f0=; b=Rpu6fnLi6433vwfzoZzdKFGnuNt1KZso56nWMf4QqIdwRPY5ciIsBihMDI1LFP2Fsy PumQyMHA2Q+mv4xOaBj9PK1Hz2w7RJgDdp/0Wr4Oqn06mSCw3z1XY2x8MKhLUyCvgArf uoNoehxL3GpWiKQWc6KPlJJV0OIlxaC4AHu6LSB4F+LEYkxVOrdEQxAyaQkQISCCOt3l A1KFxfrTpBCqybplINEBFg/5Eb+ae1DcUWHDRNIG7JczK2hD0JC4hISm3/yvMPqA7fro GjIPEQjItv++6sc8aTjpoMt/pd4ZgDglxtZWUP9bq6HuDSutgqYrMvYD256vexPxDEGz +HLQ== X-Forwarded-Encrypted: i=1; AJvYcCVax1kVCSDMp7tzYxKaJDXbFgRgYPJ1EyHdeRKhnskUIWJdKsnbdAYaoHPi4vPef6o4uftLdt3z6A==@kvack.org X-Gm-Message-State: AOJu0YyKymA8Ky5hgptcHHw81quaLD/WM+l5iImYWK541pBSNuW3H5OW njozBlIrGrACH/dOKQQJNiRu7i322WFT9aOcknIFU8cYhLffZFQ5f/HwYxY1+bqyUqI3ie9sQtw /9YzYGbv35hYitND2VK5+0rlQcLbto9SOa29EcslNm//3FRoCN1aggUXAyMy1v3q1JM/5rP5+rV wEU42AEXUoIb97d3zgdsKryms= X-Gm-Gg: ASbGncsl7bU9q97dtyA5HM5fITVU7ycmCrU1O6Qs12RdiVt0uUYZux80Uve14dL3L3U dxnxD1dh9FnehA9G5xQv+XpcsXhxVhCC5m/RgFoExOuUT0BWZt2WirxqB/p+nu1a5bb2a0sc+wK E0Kazt X-Received: by 2002:a05:690c:7085:b0:711:33d3:92ed with SMTP id 00721157ae682-7117547e398mr196388557b3.38.1750193433843; Tue, 17 Jun 2025 13:50:33 -0700 (PDT) X-Google-Smtp-Source: AGHT+IHFkuwT+fLR4WKKPymtx1/7iwNyL7yTTLzuBi63mVvFMY8cCKDK7Li4VnZQgIqQeFSw0PwBNF7+bj2If0h+Nvk= X-Received: by 2002:a05:690c:7085:b0:711:33d3:92ed with SMTP id 00721157ae682-7117547e398mr196387977b3.38.1750193433443; Tue, 17 Jun 2025 13:50:33 -0700 (PDT) MIME-Version: 1.0 References: <20250607-uffd-fixes-v2-0-339dafe9a2fe@columbia.edu> <20250607-uffd-fixes-v2-3-339dafe9a2fe@columbia.edu> In-Reply-To: From: Tal Zussman Date: Tue, 17 Jun 2025 16:50:22 -0400 X-Gm-Features: AX0GCFuppgQNaMC-wQr2Mt5OwUGedRzgBMvE-W4xD5WFZ25ag1VCaucfpSNRTtk Message-ID: Subject: Re: [PATCH v2 3/4] 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-Spam-Details-Enc: AW1haW4tMjUwNjE3MDE2NiBTYWx0ZWRfX/imOx3AsuVjo /HZ6jz/3O69VKB+mb/XdSDK0hSgXB2YUbYNlYwhBHYy1G7G+TGUAEpoGuUzWB7CA42q2vfNZq5/ ytPHJTBmTeQyqaoXAO6neKrDsub1XU2sDsM8Tcw28mwQ1gz7VI9J3p5vRfKRrz42LR8aUit8TgX IDOvjfV3MjvfI1u08eorOKHByLVPh47L5y2KgwXsHIUQQ4cwuB0vIlAQDoy/rfzzUJnk0lyUdnQ DPdZ1zQRJ2YDVkFAKlcXLCMoxY7zrZMoW6pkgq9ckohjAbLOD2jJz10BilrNn37Tfe+lT9IQcJ7 9HoJodZsVGWE+eTS1KCC/+ybsu1desG6OmdLFrd2wCv06F90OJBcfbKL5CquIeqnZgMTO/khsKc APYlGzn4 X-Proofpoint-GUID: ZPs48Fju3y2SuY73OEn3PMr8WgXAdj7S X-Proofpoint-ORIG-GUID: ZPs48Fju3y2SuY73OEn3PMr8WgXAdj7S 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-17_09,2025-06-13_01,2025-03-28_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 bulkscore=10 priorityscore=1501 malwarescore=0 suspectscore=0 lowpriorityscore=10 clxscore=1015 mlxlogscore=999 mlxscore=0 adultscore=0 spamscore=0 phishscore=0 impostorscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2505160000 definitions=main-2506170166 X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: 821AC18000C X-Stat-Signature: ent5inoibs3hyanimbt5oa4yf8qe87ih X-Rspam-User: X-HE-Tag: 1750193435-487194 X-HE-Meta: U2FsdGVkX1/oSFKgAVd5FQTwFhXkPKVbbS9bWjov7kyveGaMdIkgHeHC1za6wS66d4fcSYMYp56k4qpg/5wf9JaOgStLWmpBaQM67P121Q9VIEQ9PxNK05Zxk29oMeevHOiLwA5raCD2/o0Tzp49J9CFQQBfkVR7+d34byAiPY22B7Nzzuafs3SDK+o7OjPYZzGy2BlgdmTS/WiVyMeurErAz3DEL2xoBkDiMa82UTLkIrL/fQtTilvlSwuLrBldJjiCWP6NRMONEAMeCGisN7uMSh3lFehsz0EoH4yIczKQROJPTuRxeuhMZfnrA4znhHo6G568KqoKVFedf7tyHzS2rvXnUF2zSDadrp/B9uKp/1ynp4xWCrwElQ8IPRNGaOHozbhjAeYYc/E5gvyGTSHZ8xSx3+sDykYH6dIGU2i7ewEmN2pQxjZzDI8PLRcuK2yjGcBuqbtw+vLKP0OFMxEAYCduFNHxDmidsz34KV+Fe/vYTXE9UBIeAJu306F/VZu5LKByhdaDq/nXTLKYNjXNXTZY4X8gCo/VBwxYqCgHfoA/VYruraniEtGaJ3t6PsC8LoHv0cmPz27gycAXf/kizECUEeT7GULj060PccM+yL0ULgetdEZJ6sS+QATkOq49gGBBrl1Pedi867rKJK7zjmXc6pN2M/ZR7WmQbD97WU/SSbu9x9ywri7zCRubKX3/L6g6Dl2nLmacnfnIodIgax5dVuNu4v39J6wNJfcMoghtVIaMcPP9eFU9kAMbLjChM88SA9G9g4swuV3oo96TpILI3WTERAXIOjjsIUP0TSIX5e4VDyKShim2qTxLn2YQg8c03Iv/0GJYvqeIacpwJOu4aAh5enGU4cLeSHT3YgpIhyMHWVKuIQF5PxdEDqamtCi9J4Gmc/m6oIizuv1eLdprYao2J+jNkN57caI5OV8A1OrQNqA0Wsq56tiVrxL4CCwFFKoCRcp2/3m jOw8h1cY XJpjKswrCVn3NHWhRRcvu3XUEeo4M5avd/UOmlSCLRonG/pW4t4IuT+hQQklz5S7z0dc7mZO4TXbvDuXXXSVA8MmFCwd8WuRjUvzat620nJCAjjz4BffhAzcvpYikfEqY3twSMwyA8A4gBdoEXFGfzg4LIX2yGihcwZmozZ63z2AZXN2FQWxqmF9TAX4ueNyG99bVtWW4uLUf7LjZds1XwKIW+AsJdhf4WFvrFfAyXsd1RmVJE6Njp56tt6lFCGU2Bubq5MJNPblkEPcivBqvsRKV1KRzNY8E44IoDzArR5c/6iRah5+J3m6uzEefjHu7g6yJ 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 Tue, Jun 10, 2025 at 3:31=E2=80=AFAM David Hildenbrand wrote: > > On 07.06.25 08:40, Tal Zussman wrote: > > Currently, a VMA registered with a uffd can be unregistered through a > > different uffd associated with the same mm_struct. > > > > The existing behavior is slightly broken and may incorrectly reject > > unregistering some VMAs due to the following check: > > > > if (!vma_can_userfault(cur, cur->vm_flags, wp_async)) > > goto out_unlock; > > > > where wp_async is derived from ctx, not from cur. For example, a file-b= acked > > VMA registered with wp_async enabled and UFFD_WP mode cannot be unregis= tered > > through a uffd that does not have wp_async enabled. > > > > Rather than fix this and maintain this odd behavior, make unregistratio= n > > stricter by requiring VMAs to be unregistered through the same uffd the= y > > were registered with. Additionally, reorder the WARN() checks to avoid > > the aforementioned wp_async issue in the WARN()s. > > > > This change slightly modifies the ABI. It should not be backported to > > -stable. > > Probably add that the expectation is that nobody really depends on this > behavior, and that no such cases are known. > > > > > While at it, correct the comment for the no userfaultfd case. This seem= s to > > be a copy-paste artifact from the analogous userfaultfd_register() chec= k. > > > > Fixes: 86039bd3b4e6 ("userfaultfd: add new syscall to provide memory ex= ternalization") > > Fixes should come before anything else in a series (Andrew even prefers > a separate series for fixes vs. follow-up cleanups). > > > Signed-off-by: Tal Zussman > > --- > > fs/userfaultfd.c | 17 +++++++++++++---- > > 1 file changed, 13 insertions(+), 4 deletions(-) > > > > diff --git a/fs/userfaultfd.c b/fs/userfaultfd.c > > index 80c95c712266..10e8037f5216 100644 > > --- a/fs/userfaultfd.c > > +++ b/fs/userfaultfd.c > > @@ -1466,6 +1466,16 @@ static int userfaultfd_unregister(struct userfau= ltfd_ctx *ctx, > > VM_WARN_ON_ONCE(!!cur->vm_userfaultfd_ctx.ctx ^ > > !!(cur->vm_flags & __VM_UFFD_FLAGS)); > > > > + /* > > + * 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. > > + */ > > Probably we can shorted to: > > /* > * Prevent unregistering through another userfaultfd than used for > * registering. > */ > > ? > > > + if (cur->vm_userfaultfd_ctx.ctx && > > + cur->vm_userfaultfd_ctx.ctx !=3D ctx) > > + goto out_unlock; > > + > > /* > > * Check not compatible vmas, not strictly required > > * here as not compatible vmas cannot have an > > @@ -1489,15 +1499,14 @@ static int userfaultfd_unregister(struct userfa= ultfd_ctx *ctx, > > for_each_vma_range(vmi, vma, end) { > > cond_resched(); > > > > - VM_WARN_ON_ONCE(!vma_can_userfault(vma, vma->vm_flags, wp_async)); > > - > > /* > > - * 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. > > */ > > Maybe > > /* VMA not registered with userfaultfd. */ > > The "skip" below is rather clear. :) > > > if (!vma->vm_userfaultfd_ctx.ctx) > > goto skip; > > > > + VM_WARN_ON_ONCE(vma->vm_userfaultfd_ctx.ctx !=3D ctx); > > + VM_WARN_ON_ONCE(!vma_can_userfault(vma, vma->vm_flags, wp_async)); > > WARN_ON(!(vma->vm_flags & VM_MAYWRITE)); > > > > if (vma->vm_start > start) > > > > Acked-by: David Hildenbrand Thanks! Will update with the suggested comment + commit message changes and= move this patch before the VM_WARN changes. > -- > Cheers, > > David / dhildenb >