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 78FCBC5AE59 for ; Thu, 5 Jun 2025 20:56:17 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 0C8896B00AB; Thu, 5 Jun 2025 16:56:17 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 07A406B00AD; Thu, 5 Jun 2025 16:56:17 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E82B56B00C7; Thu, 5 Jun 2025 16:56:16 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id C4E416B00AB for ; Thu, 5 Jun 2025 16:56:16 -0400 (EDT) Received: from smtpin17.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 42B8D14169D for ; Thu, 5 Jun 2025 20:56:16 +0000 (UTC) X-FDA: 83522554752.17.D540A0F Received: from mx0a-00364e01.pphosted.com (mx0a-00364e01.pphosted.com [148.163.135.74]) by imf09.hostedemail.com (Postfix) with ESMTP id CDA1D14000B for ; Thu, 5 Jun 2025 20:56:13 +0000 (UTC) Authentication-Results: imf09.hostedemail.com; dkim=pass header.d=columbia.edu header.s=pps01 header.b=OmVD0gad; spf=pass (imf09.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=1749156974; 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=xm4+j5Ivo2wgP6zUM7+5vhC6Rb1oLpKBdxSCgVg/kKE=; b=MIwnJoZtRLfo57Obs4zw0bHWdT5/OwbQn8Wk79bSd5Gv9ZLpB23JfLJOHvOWc6x32T4CSH w4hbf/GE3S6IGh343qWnVfurQR+63sGtwkg/67On5aWHUMH5c0YLavJaCO5hb98vx5VcvX f0XKdwHBEhAGmEFeFzTZ0lx+guy6GVA= ARC-Authentication-Results: i=1; imf09.hostedemail.com; dkim=pass header.d=columbia.edu header.s=pps01 header.b=OmVD0gad; spf=pass (imf09.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-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1749156974; a=rsa-sha256; cv=none; b=vgg0Kq3sP9Vq/9wiXPBQh18qO3SAR6Efz3dlP9hEEJKJ1EisSINK6vwhYgc5uDYullpo/S dvyc4uGltu2sPofrlJttZESyqwsRKhgU168Balx861PWE10yiQEAaAeUc236DaJALMQM/O LPAHHHlMzE/LjIOjXYJ71qVgE2iqvsI= 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 555KjLfP020743 for ; Thu, 5 Jun 2025 16:56:12 -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=xm4+j5Ivo2wgP6zUM7+5vhC6Rb1oLpKBdxSCgVg/kKE=; b=OmVD0gadQQRw+VbVLnP6EB6eeYJlPT7XFCU5P1NJAsou1AWNcJWefDOQqQ9j+/j7VLGx UIheI0KY0kCbU4GwaXXJVpSiyl2g0qpOVMc7gFiW36l/GMj0AlegPdhqkTu2l1qNvZzQ JWbSOs4yo1wfr/IV09hJjdxuW8DSJc8cyhE25kCsemiEGpcFwCdVxu+0HXKBvpc/7pK7 xiO2XqZF5WZ2hwhEaJYxnZqu/ay3xYFNwVZnZAenlL6tMrV4CVe7zRundMdWoXFMCGfO gJZqpRi1huHObQfRqARRQYhknGFvjFq+Od4I6Axey9rYfTU1ciwN//B1NnCskO7AtZop +A== Received: from mail-yw1-f197.google.com (mail-yw1-f197.google.com [209.85.128.197]) by mx0a-00364e01.pphosted.com (PPS) with ESMTPS id 471ethcu7k-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT) for ; Thu, 05 Jun 2025 16:56:12 -0400 Received: by mail-yw1-f197.google.com with SMTP id 00721157ae682-70e86a2a1b8so20854087b3.1 for ; Thu, 05 Jun 2025 13:56:12 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1749156971; x=1749761771; 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=xm4+j5Ivo2wgP6zUM7+5vhC6Rb1oLpKBdxSCgVg/kKE=; b=STLSoQi576pYN98ukQjru5oUIGcW1BNoRK1lEmV+9KvW6tPTvJlosWYWWR221S/IGR 9/B3MEXQaIer9EtHAdOajJskglz1UF/GHtRFaW4vBXpIMHIr1YltAu0CX701P7rVNsBM Blx/J1KsplkgLc4/LQ6Elo8FxCJEdOGNm4fdZ6XJpEysLLkI+ve8zz7ezVA0PG+jcHeJ 0mLgH+SdEPubjomd7eWp0B/MBSSbvrQ7iKpUs+gTjpQF+lnsCG2eXZiLfaCFJL8+HILv dtrqPHqxaJue+M49ts8ihdPAOsSp6Xw7wZ1JXkRQkg2DVEVxzCM5YmrUZ9JoXUsqLD5d dRQQ== X-Forwarded-Encrypted: i=1; AJvYcCWziKUqnC10uZkVvBOti8FYIr+ixpXWJ8yMDNNi7qYd8nib61i5ag89wtaDHKemMuddycBbEsd45Q==@kvack.org X-Gm-Message-State: AOJu0YxtGu7R9/JLRT2MOcth84lfYPRNMi8AC1mtBdTbYgnGMlyTbT86 eW2Dob1tZvLV3jJsYS82eg1Ojk3E4W+xg7bpIHykj8T750IbtC60b4gZUoG8ZTjcurmCY5kCbCu MC9SkYca+P5TKxSPrkrJnAOC/GmX41hqciZw1EWRuc5yZk/l7gXOtrlDnfaY4GsVTwVYtjgrl5X OtPp8vrb/al4JchsY09GtYeZQ= X-Gm-Gg: ASbGnct8GfLT4KHkjNIDcgRwVSbRIqbb1YzXdSgwH5DR0zOqE/8no/Vvfa9W4RQEFcM svsDeyjfSVvsnEiNAZdsaPuRcHHfSQe4BQ6kfUO13avXV1bM56SM3t9UuhYPzYRGN8OIswA== X-Received: by 2002:a05:690c:6711:b0:710:ee42:5c37 with SMTP id 00721157ae682-710f76a075amr14815087b3.17.1749156971113; Thu, 05 Jun 2025 13:56:11 -0700 (PDT) X-Google-Smtp-Source: AGHT+IGeRm2n9CQ9cmSHniujfrPxJWEMnLDbBKF4rJQ6yoAy8eJprBTSY131Rr0KabDbauqak23pCjd3D9jhbArEmGk= X-Received: by 2002:a05:690c:6711:b0:710:ee42:5c37 with SMTP id 00721157ae682-710f76a075amr14814857b3.17.1749156970703; Thu, 05 Jun 2025 13:56:10 -0700 (PDT) MIME-Version: 1.0 References: <20250603-uffd-fixes-v1-0-9c638c73f047@columbia.edu> <20250603-uffd-fixes-v1-2-9c638c73f047@columbia.edu> In-Reply-To: From: Tal Zussman Date: Thu, 5 Jun 2025 16:56:00 -0400 X-Gm-Features: AX0GCFt9W11qCzc-mT2qybe1SfA1xJ_Jio9aAw4Ju_-YhONUSDy6b-R_EmrG9-I Message-ID: Subject: Re: [PATCH 2/3] userfaultfd: prevent unregistering VMAs through a different userfaultfd To: James Houghton Cc: Andrew Morton , Peter Xu , "Jason A. Donenfeld" , David Hildenbrand , Alexander Viro , Christian Brauner , Jan Kara , Pavel Emelyanov , 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: UdG3jTkscZcrXapFoGaNB8zdUxdtM7_U X-Proofpoint-Spam-Details-Enc: AW1haW4tMjUwNjA1MDE4OSBTYWx0ZWRfXxcNbNM2ps2w+ xfMRFcnBXWKyD+UCdxKdgx+NVnnUZJ4pF8NrjZy5yG+O8U6ni9hgH06ifDTJLpcJv21XyMNpjz/ xi/qCpZHrld1MQax6A7eGVEx0opQfsmGG9qHLiTBhoLy09ORLG6uxTVf99adZRt173JHiFCRKd5 V+sl/rULHRPUJwdh59EBL0zZ14DNl6iRLhINgaJKpHN+MKuvezaHwRzllKcTFyX9prk9JPqX3dE sO/0JXmzXfdI08BJWQnxOvXywoogx2WqcxQC+OSSim1W2knNOgK64EQvUVOMnY8pirfDn6n59oT KMqepiCtkfCK/5qIIwsHlO3Ht7wtUp0Upd8574E8FflaisfuaZgt1OPUUzBKCIaARo0lusBRaH0 hOkFiNRB X-Proofpoint-ORIG-GUID: UdG3jTkscZcrXapFoGaNB8zdUxdtM7_U 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=764 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2505160000 definitions=main-2506050189 X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: CDA1D14000B X-Stat-Signature: 8ws8zkw3owqfrrp9zw175p6wyfaas3m5 X-Rspam-User: X-HE-Tag: 1749156973-169246 X-HE-Meta: U2FsdGVkX190zPgNFHbKTMwDX7rpiM9gmqGK7bMARdicUR60Djg2N+kece13tMwxXVwu/1mEfpemwlujJPIeqbiMLJFSSpwrKVAKnGLz/jNUK8wrgNRTPnYOBUS9I1xyAx2VgaKobyDMwofd9u2cIpVhBh4JtICI89v2qT4YfxVSRcO8efrpCZtFYCW62M0g94xDXP8bsbVz27I4wJCvqB3siEMSTqVVJXuzs6AdlVXMKGwb3EN5EafXQri/H60soi2uQ1IHGeyaZyBDO9eNryo4gNyW9ISRZJ4CQpPEGW/FPU4gdlWjMtYxegTR5LzVUNIHRLRWEhCt/pLImC9LEr/4uhnOo45qGcTcfuBZ8w36Fu/K72m9Ol09NjyyRSKiaq6a86SOWas3TW4r9rUXbuIsLqX/ktpUs2ldBghDkQlQcQ55RBcZbYQ9+tRjtnt3rUl5jG4sk/zCf+wr8pySfIZ3lHD344cANU0Jw75JezJwkIVx3pqswUr6Il/K4/w8POcTHL1WfRkfafTxCHwfXwzdWgSjepKzmZKOL0AhounS6wp2HCVCxUl9p2T+bBhXAf3n0Xo9MK7B/XT6Y8rWz103UEXuu+clXPwtfvaEmRy9a/0j4SG0cqOeu2Lte1tieKi4gkwbX4BdPeWcbivbHXBkwmAJmkSVE92vs8f2sfhYUkyaRuRvCiXsJ9eBuCR/E4LIyMCs/NB33fXyp3Fuh3i7+OuTK4w1T59puIeXPvQfcRuta17LNKazlNc9VIjzUYrDx2tMWv3mBWJx9khG3OPCEFZHlZ3W3DDhdE8UtLEm+1sOoH5oO4iSrywarUU3MoHAMjLZT8Y5v1iPz7/xlMT8ouQp0uf0NBrO3z1XfuI9KrcSEmXI7UedEFkzbKlmZfMH/HjN2+lPOerhMYUrRUVsB/1C7wxFPhY8F248vJdofZ9KfkQNfsotEA6uzg5EpVv25gtQp2gNJrQMWOs Vx5mg2XQ A8/92bB260tyUjQapwDr0tgx8uR+NLXmnuB0Ojb6Tv5UTYAMCcZMw9GoCZg9w7xqDf8WPr6rzldU2anBHj7ady1QZ9GQGls9mfqWvV3u9MQSbvgLplJ2tEIXKM9ZG3wG2R0GGFrfZNjWgl1fSBktjRTUytyr48MkT3IMmZ8wvRQ63QRxUJlvxpUkAxoJtcjj+5I5Jchpy4mjoVg3+Rc8bcZmt0e89hDV9jLRFoCBaebo9u3b82PXB9oA1A41ZiXDd/vY0BkV8nW8JjdmPuDMI9vfXvzMbN1UopXF1T7rys9FnaCESJ245qTb3Zlu8F9FXPIQKC4MzHg2quk6Hn4Pz2ClmL9Jhs+TpYGafpvlCH4rvopo= 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 3, 2025 at 8:52=E2=80=AFPM James Houghton wrote: > > On Tue, Jun 3, 2025 at 3:15=E2=80=AFPM 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. > > > > Fixes: 86039bd3b4e6 ("userfaultfd: add new syscall to provide memory ex= ternalization") > > Signed-off-by: Tal Zussman > > Thanks, Tal! I like this patch, but I can't really meaningfully > comment on if it's worth it to change the UAPI. > > > --- > > 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 differe= nt > > + * 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; > > + > > Very minor nitpick: I think this check should go above the > !vma_can_userfault() check above, as `wp_async` was derived from > `ctx`, not `cur->vm_userfaultfd_ctx.ctx`. Thanks, this is a good point! I'll change it for v2. This also seems to indicate that the current behavior is broken and may rej= ect unregistering some VMAs incorrectly. For example, a file-backed VMA registe= red with `wp_async` and UFFD_WP cannot be unregistered through a VMA that does = not have `wp_async` set. > > found =3D true; > > } for_each_vma_range(vmi, cur, end); > > I don't really like this for_each_vma_range() for loop, but I guess it > is meaningful to the user: invalid unregistration attempts will fail > quickly instead of potentially making some progress. So unfortunately, > without a good reason, I suppose we can't get rid of it. :( > > > 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); > > IMO, this new BUG_ON should either be > (1) moved and should not be a BUG_ON. See the WARN_ON_ONCE() below, > OR > (2) removed. > > Perhaps the older BUG_ON() should be removed/changed too. I added this mainly to maintain symmetry with the userfaulfd_register() implementation. I'm happy to leave it out, so I'll either convert it, and the other one, to a VM_WARN_ON_ONCE(), as per David, or remove it. > > > > /* > > - * Nothing to do: this vma is already registered into t= his > > - * userfaultfd and with the right tracking mode too. > > + * Nothing to do: this vma is not registered with userf= aultfd. > > */ > > if (!vma->vm_userfaultfd_ctx.ctx) > > goto skip; > > if (WARN_ON_ONCE(vmx->vm_userfaultfd_ctx.ctx !=3D ctx)) { > ret =3D -EINVAL; > break; > } > > where the WARN_ON_ONCE() indicates that the VMA should have been > filtered out earlier. The WARN_ON_ONCE() isn't even really necessary. > > > > > > -- > > 2.39.5 > > > >