Message ID | 20221025182149.3076870-1-axelrasmussen@google.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a5d:6687:0:0:0:0:0 with SMTP id l7csp1157436wru; Tue, 25 Oct 2022 11:36:37 -0700 (PDT) X-Google-Smtp-Source: AMsMyM7q0tlvvJVG/NRNGVXDqy3WOeyaujlLr9q9xMe+HHGWVCsLmk8ntM80T5co6ongQehG4NRB X-Received: by 2002:a17:907:7252:b0:791:9fd8:222e with SMTP id ds18-20020a170907725200b007919fd8222emr33545948ejc.729.1666722997764; Tue, 25 Oct 2022 11:36:37 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1666722997; cv=none; d=google.com; s=arc-20160816; b=mU2a9O/hLpE01XlcmOVTJBG7O23ktyHtT0+Et9s9z8Bgig6O+dw/Y/gCQFiF72Ka61 a5w0U+G28XEqbAg+GB2h2guSHT8vcHLV2K3qYjA8X87cPAO9DaDriv3uHKlvQwklFtLn rO3I/6u7SnoUICq1PmkzsNZDWLTNIraUwQc8plVYRdBC3FOoTlkZOOXThBCv73YmgDAm J1wv8bu8jKr+Hb4UKP35dHc/PsMwHMwcZq0KCunYpKulhikbKbRKlwQy73sAjAgLMDhB tSwvCk5/Gatd1EMI1FaSZKTL6ulBu93rP/hQp8CiH9YSz0Nbw5486aEmmnyau8tBYA96 ot3g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:from:subject:message-id:mime-version:date :dkim-signature; bh=PjNoCfBC/CKwMAwiLtsnaqEW9HWbqcvaYiZFCHqhX1A=; b=V/oJDCxeMYn+iZZ4Vzjqmw3zlE0ShFt27jPCTKlyHoV8EqxZA4jprirH2khFvfGh1/ TDeUs25UtvxmDNGDQNQyNnBubLKIzquvD2Pw4kSEi44dXLz0F9SyYyN1+G7Kdd42CGme Gjpx1mVUbPODu48kaBWFiqM75s5mDdlsOevG0qUaipj9l1/A9Ud5GFoHcCRpGjVbRdox ubcxdBGdlF9TTc/iANKgnbLnUUfKp95C+nRuttyo5OCgbd/G+2wUPftfICaiQeFPOYsg HZALyIxfmRQJsSNn2MM6/63m1fvLhBdFTOMUQ4ncw1ZCh8q4H4xNULn4yWM9f4Ji13Yx 8buw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=cUt63EGP; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id sh7-20020a1709076e8700b007a3fbdb825asi1353723ejc.707.2022.10.25.11.36.06; Tue, 25 Oct 2022 11:36:37 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=cUt63EGP; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232529AbiJYSV6 (ORCPT <rfc822;pwkd43@gmail.com> + 99 others); Tue, 25 Oct 2022 14:21:58 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:50890 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232227AbiJYSV4 (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Tue, 25 Oct 2022 14:21:56 -0400 Received: from mail-yw1-x114a.google.com (mail-yw1-x114a.google.com [IPv6:2607:f8b0:4864:20::114a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 1C7F5DD89D for <linux-kernel@vger.kernel.org>; Tue, 25 Oct 2022 11:21:56 -0700 (PDT) Received: by mail-yw1-x114a.google.com with SMTP id 00721157ae682-360a7ff46c3so124889277b3.12 for <linux-kernel@vger.kernel.org>; Tue, 25 Oct 2022 11:21:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=cc:to:from:subject:message-id:mime-version:date:from:to:cc:subject :date:message-id:reply-to; bh=PjNoCfBC/CKwMAwiLtsnaqEW9HWbqcvaYiZFCHqhX1A=; b=cUt63EGPJ5XLXHEiRR83p6e5nk3wF+EccI3J2Nj4Hz7sd+o45EdjHmClaVdJS7D6Qt SRVj8/gV7ow6GDJ8o9U0wqDQuR4bhJD648XzGLZIF6bPN1Sdx3E6Rg7CDPlZWdwOkQgp AldXSSSnsZD7zLMgOdb0Vfa/h8JHe098M+X4gSZKtZWQWp5p15UcDWhAiMMLrjUjhkcY KC0eBsTNKsCRaOvTdGIHQ6ESz+Ix1YWpg7YnPKEM4Ti4Gz2qXJY47W47EziC/8C/dDfo 8xbZi5AbaDJ/hjFTwNPbJswDGS8yutCtZxwos1qagpx/I6fIYQdakdLMhuiTDm8H//iZ 9INg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:from:subject:message-id:mime-version:date:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=PjNoCfBC/CKwMAwiLtsnaqEW9HWbqcvaYiZFCHqhX1A=; b=MZ1EczwRbEvklu/vGvd5kF3H8qeGl/Ud9T+4TZ0SXwp+EyucTM2bKPng1d2tcSQpg6 ZhNvKz+zKTgHNfsffUJZJ5ZtxF/Ob/6MveoHGErMuy/i4mRE7buSTG5gtmodXFDugpPg Y2UUgOs+V+k0i/L68Kr4PWW+AuAE7G9/UK26Jw25bMA/batsR1IhdvlBv7CZqAFbvi9e CXFLJFaTltbmUQ9qmzPcZacfst5KHrbYNAlrxzsh4dEZ+1Vw6A8lPBw96t6jNJTC4m7J 3p3hr+1rCDJy8ONI54DHmoTfRhXmS4ruFtwyUlrBSEyiyPkGkn+0BBdoTHMwcf2faOZL RlHQ== X-Gm-Message-State: ACrzQf32zVUZLwulFsItbE5jwasJhJX4RGj5odRl8tO2M+BJ+ZUwfy7q PT2tlUbGMHYRANM29i1hnpKm9x/dEsuC2714s9yd X-Received: from ajr0.svl.corp.google.com ([2620:15c:2d4:203:9558:df20:7923:f362]) (user=axelrasmussen job=sendgmr) by 2002:a0d:cc51:0:b0:36c:98b0:dc38 with SMTP id o78-20020a0dcc51000000b0036c98b0dc38mr12308042ywd.275.1666722115408; Tue, 25 Oct 2022 11:21:55 -0700 (PDT) Date: Tue, 25 Oct 2022 11:21:49 -0700 Mime-Version: 1.0 X-Mailer: git-send-email 2.38.0.135.g90850a2211-goog Message-ID: <20221025182149.3076870-1-axelrasmussen@google.com> Subject: [PATCH] userfaultfd: wake on unregister for minor faults as well as missing From: Axel Rasmussen <axelrasmussen@google.com> To: Alexander Viro <viro@zeniv.linux.org.uk>, Andrew Morton <akpm@linux-foundation.org>, Peter Xu <peterx@redhat.com>, Mike Kravetz <mike.kravetz@oracle.com> Cc: Axel Rasmussen <axelrasmussen@google.com>, Lokesh Gidra <lokeshgidra@google.com>, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, stable@vger.kernel.org Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-9.6 required=5.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, SPF_HELO_NONE,SPF_PASS,USER_IN_DEF_DKIM_WL autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1747685733921570751?= X-GMAIL-MSGID: =?utf-8?q?1747685733921570751?= |
Series |
userfaultfd: wake on unregister for minor faults as well as missing
|
|
Commit Message
Axel Rasmussen
Oct. 25, 2022, 6:21 p.m. UTC
This was an overlooked edge case when minor faults were added. In
general, minor faults have the same rough edge here as missing faults:
if we unregister while there are waiting threads, they will just remain
waiting forever, as there is no way for userspace to wake them after
unregistration. To work around this, userspace needs to carefully wake
everything before unregistering.
So, wake for minor faults just like we already do for missing faults as
part of the unregistration process.
Cc: stable@vger.kernel.org
Fixes: 7677f7fd8be7 ("userfaultfd: add minor fault registration mode")
Reported-by: Lokesh Gidra <lokeshgidra@google.com>
Signed-off-by: Axel Rasmussen <axelrasmussen@google.com>
---
fs/userfaultfd.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Comments
On Tue, Oct 25, 2022 at 11:21:49AM -0700, Axel Rasmussen wrote: > This was an overlooked edge case when minor faults were added. In > general, minor faults have the same rough edge here as missing faults: > if we unregister while there are waiting threads, they will just remain > waiting forever, as there is no way for userspace to wake them after > unregistration. To work around this, userspace needs to carefully wake > everything before unregistering. > > So, wake for minor faults just like we already do for missing faults as > part of the unregistration process. > > Cc: stable@vger.kernel.org > Fixes: 7677f7fd8be7 ("userfaultfd: add minor fault registration mode") > Reported-by: Lokesh Gidra <lokeshgidra@google.com> > Signed-off-by: Axel Rasmussen <axelrasmussen@google.com> > --- > fs/userfaultfd.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/fs/userfaultfd.c b/fs/userfaultfd.c > index 07c81ab3fd4d..7daee4b9481c 100644 > --- a/fs/userfaultfd.c > +++ b/fs/userfaultfd.c > @@ -1606,7 +1606,7 @@ static int userfaultfd_unregister(struct userfaultfd_ctx *ctx, > start = vma->vm_start; > vma_end = min(end, vma->vm_end); > > - if (userfaultfd_missing(vma)) { > + if (userfaultfd_missing(vma) || userfaultfd_minor(vma)) { > /* > * Wake any concurrent pending userfault while > * we unregister, so they will not hang > -- > 2.38.0.135.g90850a2211-goog Thanks, Axel. Is wr-protect mode also prone to this? Would a test case help too?
On Tue, Oct 25, 2022 at 11:34 AM Peter Xu <peterx@redhat.com> wrote: > > On Tue, Oct 25, 2022 at 11:21:49AM -0700, Axel Rasmussen wrote: > > This was an overlooked edge case when minor faults were added. In > > general, minor faults have the same rough edge here as missing faults: > > if we unregister while there are waiting threads, they will just remain > > waiting forever, as there is no way for userspace to wake them after > > unregistration. To work around this, userspace needs to carefully wake > > everything before unregistering. > > > > So, wake for minor faults just like we already do for missing faults as > > part of the unregistration process. > > > > Cc: stable@vger.kernel.org > > Fixes: 7677f7fd8be7 ("userfaultfd: add minor fault registration mode") > > Reported-by: Lokesh Gidra <lokeshgidra@google.com> > > Signed-off-by: Axel Rasmussen <axelrasmussen@google.com> > > --- > > fs/userfaultfd.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/fs/userfaultfd.c b/fs/userfaultfd.c > > index 07c81ab3fd4d..7daee4b9481c 100644 > > --- a/fs/userfaultfd.c > > +++ b/fs/userfaultfd.c > > @@ -1606,7 +1606,7 @@ static int userfaultfd_unregister(struct userfaultfd_ctx *ctx, > > start = vma->vm_start; > > vma_end = min(end, vma->vm_end); > > > > - if (userfaultfd_missing(vma)) { > > + if (userfaultfd_missing(vma) || userfaultfd_minor(vma)) { > > /* > > * Wake any concurrent pending userfault while > > * we unregister, so they will not hang > > -- > > 2.38.0.135.g90850a2211-goog > > Thanks, Axel. Is wr-protect mode also prone to this? Would a test case > help too? I'm not quite as familiar with uffd-wp, but I think so? At minimum, it seems like waking can't *hurt*, and it would simplify the check slightly -- if (userfaultfd_armed(vma)) {} It would also mean if we add yet another registration mode in the future, we wouldn't forget to update this. I'll send a v2 to address both points. > > -- > Peter Xu >
Thanks for fixing this issue. On Tue, Oct 25, 2022 at 11:21 AM Axel Rasmussen <axelrasmussen@google.com> wrote: > > This was an overlooked edge case when minor faults were added. In > general, minor faults have the same rough edge here as missing faults: > if we unregister while there are waiting threads, they will just remain > waiting forever, as there is no way for userspace to wake them after > unregistration. To work around this, userspace needs to carefully wake > everything before unregistering. Actually, WAKE ioctl doesn't check if the provided range is registered with userfaultfd or not. So, it's possible to wake the waiting threads after unregisteration. But, in this context, missing faults are the same as minor faults (and wp too?). Therefore, waking the waiting threads as part of unregistration is expected. > > So, wake for minor faults just like we already do for missing faults as > part of the unregistration process. > > Cc: stable@vger.kernel.org > Fixes: 7677f7fd8be7 ("userfaultfd: add minor fault registration mode") > Reported-by: Lokesh Gidra <lokeshgidra@google.com> > Signed-off-by: Axel Rasmussen <axelrasmussen@google.com> > --- > fs/userfaultfd.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/fs/userfaultfd.c b/fs/userfaultfd.c > index 07c81ab3fd4d..7daee4b9481c 100644 > --- a/fs/userfaultfd.c > +++ b/fs/userfaultfd.c > @@ -1606,7 +1606,7 @@ static int userfaultfd_unregister(struct userfaultfd_ctx *ctx, > start = vma->vm_start; > vma_end = min(end, vma->vm_end); > > - if (userfaultfd_missing(vma)) { > + if (userfaultfd_missing(vma) || userfaultfd_minor(vma)) { > /* > * Wake any concurrent pending userfault while > * we unregister, so they will not hang > -- > 2.38.0.135.g90850a2211-goog >
diff --git a/fs/userfaultfd.c b/fs/userfaultfd.c index 07c81ab3fd4d..7daee4b9481c 100644 --- a/fs/userfaultfd.c +++ b/fs/userfaultfd.c @@ -1606,7 +1606,7 @@ static int userfaultfd_unregister(struct userfaultfd_ctx *ctx, start = vma->vm_start; vma_end = min(end, vma->vm_end); - if (userfaultfd_missing(vma)) { + if (userfaultfd_missing(vma) || userfaultfd_minor(vma)) { /* * Wake any concurrent pending userfault while * we unregister, so they will not hang