Received: by 2002:a05:6358:1087:b0:cb:c9d3:cd90 with SMTP id j7csp8898306rwi; Tue, 25 Oct 2022 12:16:12 -0700 (PDT) X-Google-Smtp-Source: AMsMyM7pDsrm1lOR5nzbbzzSO2IYhWRXx/XiAeLBjc6sjnOa26miWHpQVdDicS8pDA7BTEXtJWFr X-Received: by 2002:a17:903:283:b0:186:897e:71ea with SMTP id j3-20020a170903028300b00186897e71eamr18903703plr.123.1666725372610; Tue, 25 Oct 2022 12:16:12 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1666725372; cv=none; d=google.com; s=arc-20160816; b=M1zR9zSSm7/TwqomQs4bS9ZgIJDIrerR0eQ9rxVe7/VJ7PgoI6Ppynxco/kufoWIT6 TYv7l2A4WeezqOfb8pIBtaVwsKnWy7VGqeXN1RAcMnjJl09ySqhjERRNGY1ZuMHhkV3E LpWHl+ET+zhoNmAXOUAd7vN8cT8dF5va4VlFPDPC1TBrGEG5Sl9vmgXqcHEheICGb07Q J9/02IhNGXryzWxnVOyEsQVScl8zq17rPIqd+UX+91dkH7CNWLuiCITQYAzZQd0b1Bsz +MpYnbrCYxzSezPQi+6D7+3Jvx3xKrkBpwmVCjDYQHNzyvuEE7TJB5BklAQB2m9OGZTF jrtQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=zecUBmaI9PgC41i43sLomBgRMf4lJ2WJueLyjCsQE94=; b=ENLbNAQnw/OorA6AGmz6nNCButZ6AhSva8OJgZKqIrOZn84af2cOBkgheFb53xA3zb G/kLUaLiJD8cBCeoyLZ1ARFKvqwgggWQAYN3mSpcjUzxF6CBM7+TChZZDHxLX36/pUgF 2r9wTzJhCzZWvxQwGITNp+ouIvlRtg6LTrukbvE2Lf4ZY9laSaCn20gyvADlDRisMW+Q x0Fh1RwToguX3kzy8mwpMQXjZdtWoYKZEnviegaIWT19Atgzdta9QfgrhrD5OFEsPwMU HRKycZ6emZQgrN8NRI+F+a6bIyIHTXFux0+V11De1+kt5iStFJbWZVuK1nU0RECP3khD i6Tw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=GrpYgqsX; 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 Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id s5-20020a056a0008c500b00557c8a20395si4472284pfu.120.2022.10.25.12.16.01; Tue, 25 Oct 2022 12:16:12 -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=GrpYgqsX; 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 S232473AbiJYSoi (ORCPT + 99 others); Tue, 25 Oct 2022 14:44:38 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42118 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232107AbiJYSof (ORCPT ); Tue, 25 Oct 2022 14:44:35 -0400 Received: from mail-ed1-x531.google.com (mail-ed1-x531.google.com [IPv6:2a00:1450:4864:20::531]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 5149CDED4 for ; Tue, 25 Oct 2022 11:44:33 -0700 (PDT) Received: by mail-ed1-x531.google.com with SMTP id r14so37715236edc.7 for ; Tue, 25 Oct 2022 11:44:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=zecUBmaI9PgC41i43sLomBgRMf4lJ2WJueLyjCsQE94=; b=GrpYgqsXMIgui8uqNCF3FndCtXTpG2IOEK9KoQql6JDLzVaWmiibzo5T2OSVNUVIqr utrd6ZBEOlZkcyKpthDlnr9lzYi0dDCa+rrBe+FV/dKxwJr6CBNOosM5bFY44SDtG4xr //cgXIz8QHaymHQowERHA/QPrePkGfO/PzvjQ1qNAoZmAUQkqLK0IzuuaOG1WHEUR/+v QMerdEXMGlvln/2gQz733PfcsLVG6LzlMrauRfVmITC7xpEnKv2IMHcHVAbemNgrqKfC 0vqJZ97L9FIcoygG7zGR2eZ2z0ybM8DXHBjPFP+DgJNCoEICeSh+HUeDlmn7gC2sQnQq 5o7w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=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=zecUBmaI9PgC41i43sLomBgRMf4lJ2WJueLyjCsQE94=; b=o/K+XqxmhSS6PvOg5Xq9aMP3i5OqL2X3IuW7RwwUb6K++YfrOBnghuVUUfcaqpmQM9 WRdD7xkgrENNme4Hl2uhGo5mxMqn5OsklB23wHOG/z2NDuMs6E4M4CJTgSFsTvayveTv DLpwp+vqEzHLUA9i4uWkT9IfrsKazUF/uHNYZlSuNWtR0rGRg7DvsCurAZymflvgY0xn WqJqPwBo6O0orCYMoumff2/iVgOO8T+vOUQ4PqpMd0bsOCzgrYiPKfVsKqmSty6ETYoE SCVYH4GJwaLnQ4biu7Y77ZQ8/iQlzm/FztdwoT229EFpIHVR2p0JLsU9ZPM4xR5jozj9 Whlw== X-Gm-Message-State: ACrzQf0zcfdFVNiYRHJ5B3ARHBCema0J+n3ivkyQsRS3yvY3RGaMKwBU RppQ17YKuX0J67WF6Bzvvqtp8FLEvFypscovmACzULpSvyEs8g== X-Received: by 2002:aa7:df94:0:b0:461:aff8:d3e1 with SMTP id b20-20020aa7df94000000b00461aff8d3e1mr13166171edy.10.1666723471729; Tue, 25 Oct 2022 11:44:31 -0700 (PDT) MIME-Version: 1.0 References: <20221025182149.3076870-1-axelrasmussen@google.com> In-Reply-To: <20221025182149.3076870-1-axelrasmussen@google.com> From: Lokesh Gidra Date: Tue, 25 Oct 2022 11:44:20 -0700 Message-ID: Subject: Re: [PATCH] userfaultfd: wake on unregister for minor faults as well as missing To: Axel Rasmussen Cc: Alexander Viro , Andrew Morton , Peter Xu , Mike Kravetz , 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=-17.6 required=5.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF, ENV_AND_HDR_SPF_MATCH,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS, USER_IN_DEF_DKIM_WL,USER_IN_DEF_SPF_WL autolearn=unavailable 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: X-Mailing-List: linux-kernel@vger.kernel.org Thanks for fixing this issue. On Tue, Oct 25, 2022 at 11:21 AM 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. 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 > Signed-off-by: Axel Rasmussen > --- > 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 >