Message ID | 20230919190206.388896-8-axelrasmussen@google.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:612c:172:b0:3f2:4152:657d with SMTP id h50csp3851934vqi; Tue, 19 Sep 2023 20:41:51 -0700 (PDT) X-Google-Smtp-Source: AGHT+IGkE36/3DJVaVTF5l7CeUtOawiNcv/V4yVoNIqvUARLlv6WF1GpO3zqU1ecYCiWFzu62RbT X-Received: by 2002:a17:902:c106:b0:1bf:712:e4bd with SMTP id 6-20020a170902c10600b001bf0712e4bdmr1011318pli.65.1695181311118; Tue, 19 Sep 2023 20:41:51 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1695181311; cv=none; d=google.com; s=arc-20160816; b=01XJpKyY8YuWc7rMREqVElWs84QLDyAIiihudnl8CZtgfMBtGuT8HgBT78Rabm2/xW lM2Tprr3hGmd4kpN+BxfTT7uuVwz49ffC51Vuc0YRJgYAowo0BR4hgQWQlNCbuY3RABX MogQb7o30GTSEQkqKzs8vSctjflm1nKkDNq4vPVqoMQRl4023OlT06+fAi1iJsiEoGib NIX59dyhQ6Jt9+j8qPFgKZybX/uIRTGjHfbuAg8hXD1wyBLvVcE68vcGeIn6AG+g8x51 DwW5Rp8m10x8PWWmx24mVzT0w7UsDjb4eSRLCZl560McP7oVrrfohxLbizYDXRAxj1Dr RWsA== 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:references :mime-version:in-reply-to:date:dkim-signature; bh=dATpzHjDHVSfxWhEgldjVmKuWzgWmKZlkhKuoIGibHA=; fh=SqwPTGdhTS3wVH9FltNQ4n/lDM1p3ApEDnroT8zra0U=; b=oAEZuTVNMoLoiIpMLkdTScT1I/8NkD2FJxkED/yT7xecqmYr8zqFuRSXFdxFbOYk/B JI4L7vYL6WQa59oW+cgWXF/oDmXYQhtnEpo2Eq73NFQRA7WNi5iIKIWb+CPQWUg2XGyx GOa4/qI+F7FTRLsIz5+ckqS58Wx44gIWdt5fjyXo5SQsivi7vJtaRyt+LujF72oIoh7W eoWN3Tj9Nej/6Ac8nVe4CW6xbyfn66VtrOJutUp2q9mzUe9FoJ9ChFb+eeUBu3MIdASo +aVyaWNDxPAkrbQbWpfKuWx9C830o1L4AzX0lppvxWQrY0j933ZuzPY7/jY0pkDkFomR eHeQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20230601 header.b=v2yJA9+x; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:6 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 pete.vger.email (pete.vger.email. [2620:137:e000::3:6]) by mx.google.com with ESMTPS id u11-20020a170902e80b00b001bdc9c55295si11647581plg.593.2023.09.19.20.41.50 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 19 Sep 2023 20:41:51 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:6 as permitted sender) client-ip=2620:137:e000::3:6; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20230601 header.b=v2yJA9+x; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:6 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 (depot.vger.email [IPv6:2620:137:e000::3:0]) by pete.vger.email (Postfix) with ESMTP id 2B3A282A9BB5; Tue, 19 Sep 2023 12:03:06 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at pete.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233134AbjISTCz (ORCPT <rfc822;toshivichauhan@gmail.com> + 26 others); Tue, 19 Sep 2023 15:02:55 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56438 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232838AbjISTCh (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Tue, 19 Sep 2023 15:02:37 -0400 Received: from mail-yb1-xb49.google.com (mail-yb1-xb49.google.com [IPv6:2607:f8b0:4864:20::b49]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 37A2EF3 for <linux-kernel@vger.kernel.org>; Tue, 19 Sep 2023 12:02:29 -0700 (PDT) Received: by mail-yb1-xb49.google.com with SMTP id 3f1490d57ef6-cf4cb742715so6610296276.2 for <linux-kernel@vger.kernel.org>; Tue, 19 Sep 2023 12:02:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1695150148; x=1695754948; darn=vger.kernel.org; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:from:to:cc:subject:date:message-id:reply-to; bh=dATpzHjDHVSfxWhEgldjVmKuWzgWmKZlkhKuoIGibHA=; b=v2yJA9+xEArPA/74JMN0Hi694q+EDFyndB9ppvzcYvjeQ6RKM3MPV8k+s3kMjmOub6 8yQVjUtjnXSs4iiDS9jPgMtzYzoebk/scqukPobKHzl1J1/TAzCr70z/wmdE8Z8cNY8G 9LRGxHoUwdhVkJCEHtFfjcnDzLYg7MfFe9wiBDDOFrgafP30KwSNmyUbXxC2+7/cP1dg FVnin8rmElasfww5o03MI48xmZGPAo3TCOyUZnllrktI1WCO9YhVpfkeguMIpRx+PjHu r2g8s4stxr2TPEb28XzFYHoBfTx1Ikj20B80pj89tmzaLc2WhD1FH6apIb36AWYBe7+6 tTag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1695150148; x=1695754948; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=dATpzHjDHVSfxWhEgldjVmKuWzgWmKZlkhKuoIGibHA=; b=Ht6Ac8vixi0wBGSieOkhXZLutLj+Sb1l0ZWQhCirtvofzo9YLFZ/P+/pFUwCApCGEW Ydx/X+VwaSpi46d03h4G4zfmGfx5uS4U7z7P6FE8ZrT5kD7O4LAaSBKstwBZKZq/BEXh HJcbp/akFa69k0nj3EGB1dlULKWA86WCBe3CzNqTMjHhSQCwbVF4XrULPfvDUHWqfVqK m+tMVUjEBPqPYH0YdxhCqzVv68Gf4Ta1bZYzHJTcmOJCpJp1z7GXmlQzjQXG1ME3ya0V XLqp4eNy9+IsWWkDvzR6TFdvtbzsgEmvyQGmkV6ImStJUjLnbQo0nfdIOMB2nxbzuyyf epmA== X-Gm-Message-State: AOJu0Yxqp1B8eLoKxkmLxNHft3Q/xFv5I+qXicRb39KkFqxm25NQZDzf uKMWr9UVvCQ1SLGwMNB6VRBhMNQm/ZoUgGqxVFi3 X-Received: from axel.svl.corp.google.com ([2620:15c:2a3:200:8f5a:6a6a:cafc:a3ad]) (user=axelrasmussen job=sendgmr) by 2002:a05:6902:1802:b0:d77:8641:670c with SMTP id cf2-20020a056902180200b00d778641670cmr8426ybb.10.1695150147917; Tue, 19 Sep 2023 12:02:27 -0700 (PDT) Date: Tue, 19 Sep 2023 12:02:03 -0700 In-Reply-To: <20230919190206.388896-1-axelrasmussen@google.com> Mime-Version: 1.0 References: <20230919190206.388896-1-axelrasmussen@google.com> X-Mailer: git-send-email 2.42.0.459.ge4e396fd5e-goog Message-ID: <20230919190206.388896-8-axelrasmussen@google.com> Subject: [PATCH 07/10] ioctl_userfaultfd.2: correct and update UFFDIO_API ioctl error codes From: Axel Rasmussen <axelrasmussen@google.com> To: Alejandro Colomar <alx@kernel.org>, Peter Xu <peterx@redhat.com> Cc: linux-man@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Axel Rasmussen <axelrasmussen@google.com> Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-8.4 required=5.0 tests=DKIMWL_WL_MED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_IN_DEF_DKIM_WL autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on pete.vger.email Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (pete.vger.email [0.0.0.0]); Tue, 19 Sep 2023 12:03:06 -0700 (PDT) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1777526438445921285 X-GMAIL-MSGID: 1777526438445921285 |
Series |
userfaultfd man page updates
|
|
Commit Message
Axel Rasmussen
Sept. 19, 2023, 7:02 p.m. UTC
First, it is not correct that repeated UFFDIO_API calls result in
EINVAL. This is true *if both calls enable features*, but in the case
where we're doing a two-step feature detection handshake, the kernel
explicitly expects 2 calls (one with no features set). So, correct this
description.
Then, some new error cases have been added to the kernel recently, and
the man page wasn't updated to note these. So, add in descriptions of
these new error cases.
Signed-off-by: Axel Rasmussen <axelrasmussen@google.com>
---
man2/ioctl_userfaultfd.2 | 24 +++++++++++++++++++-----
1 file changed, 19 insertions(+), 5 deletions(-)
Comments
Hi Axel, On Tue, Sep 19, 2023 at 12:02:03PM -0700, Axel Rasmussen wrote: > First, it is not correct that repeated UFFDIO_API calls result in > EINVAL. This is true *if both calls enable features*, but in the case > where we're doing a two-step feature detection handshake, the kernel > explicitly expects 2 calls (one with no features set). So, correct this > description. > > Then, some new error cases have been added to the kernel recently, and > the man page wasn't updated to note these. So, add in descriptions of > these new error cases. > > Signed-off-by: Axel Rasmussen <axelrasmussen@google.com> > --- > man2/ioctl_userfaultfd.2 | 24 +++++++++++++++++++----- > 1 file changed, 19 insertions(+), 5 deletions(-) > > diff --git a/man2/ioctl_userfaultfd.2 b/man2/ioctl_userfaultfd.2 > index 53b1f473f..1aa9654be 100644 > --- a/man2/ioctl_userfaultfd.2 > +++ b/man2/ioctl_userfaultfd.2 > @@ -280,17 +280,31 @@ refers to an address that is outside the calling process's > accessible address space. > .TP > .B EINVAL > -The userfaultfd has already been enabled by a previous > -.B UFFDIO_API > -operation. > -.TP > -.B EINVAL > The API version requested in the > .I api > field is not supported by this kernel, or the > .I features > field passed to the kernel includes feature bits that are not supported > by the current kernel version. > +.TP > +.B EPERM This EPERM should probably be at the end. Unless you have a good reason to break alphabetic order. Thanks, Alex > +The > +.B UFFD_FEATURE_EVENT_FORK > +feature was enabled, > +but the calling process doesn't have the > +.B CAP_SYS_PTRACE > +capability. > +.TP > +.B EINVAL > +A previous > +.B UFFDIO_API > +call already enabled one or more features for this userfaultfd. > +Calling > +.B UFFDIO_API > +twice, > +the first time with no features set, > +is explicitly allowed > +as per the two-step feature detection handshake. > .\" FIXME In the above error case, the returned 'uffdio_api' structure is > .\" zeroed out. Why is this done? This should be explained in the manual page. > .\" > -- > 2.42.0.459.ge4e396fd5e-goog >
On Tue, Sep 26, 2023 at 01:52:34AM +0200, Alejandro Colomar wrote: > Hi Axel, > > On Tue, Sep 19, 2023 at 12:02:03PM -0700, Axel Rasmussen wrote: > > First, it is not correct that repeated UFFDIO_API calls result in > > EINVAL. This is true *if both calls enable features*, but in the case > > where we're doing a two-step feature detection handshake, the kernel > > explicitly expects 2 calls (one with no features set). So, correct this > > description. > > > > Then, some new error cases have been added to the kernel recently, and > > the man page wasn't updated to note these. So, add in descriptions of > > these new error cases. > > > > Signed-off-by: Axel Rasmussen <axelrasmussen@google.com> > > --- > > man2/ioctl_userfaultfd.2 | 24 +++++++++++++++++++----- > > 1 file changed, 19 insertions(+), 5 deletions(-) > > > > diff --git a/man2/ioctl_userfaultfd.2 b/man2/ioctl_userfaultfd.2 > > index 53b1f473f..1aa9654be 100644 > > --- a/man2/ioctl_userfaultfd.2 > > +++ b/man2/ioctl_userfaultfd.2 > > @@ -280,17 +280,31 @@ refers to an address that is outside the calling process's > > accessible address space. > > .TP > > .B EINVAL > > -The userfaultfd has already been enabled by a previous > > -.B UFFDIO_API > > -operation. > > -.TP > > -.B EINVAL > > The API version requested in the > > .I api > > field is not supported by this kernel, or the > > .I features > > field passed to the kernel includes feature bits that are not supported > > by the current kernel version. > > +.TP > > +.B EPERM > > This EPERM should probably be at the end. Unless you have a good reason > to break alphabetic order. I agree with Alex here, other than that feel free to add Reviewed-by: Mike Rapoport (IBM) <rppt@kernel.org> > Thanks, > Alex > > > +The > > +.B UFFD_FEATURE_EVENT_FORK > > +feature was enabled, > > +but the calling process doesn't have the > > +.B CAP_SYS_PTRACE > > +capability. > > +.TP > > +.B EINVAL > > +A previous > > +.B UFFDIO_API > > +call already enabled one or more features for this userfaultfd. > > +Calling > > +.B UFFDIO_API > > +twice, > > +the first time with no features set, > > +is explicitly allowed > > +as per the two-step feature detection handshake. > > .\" FIXME In the above error case, the returned 'uffdio_api' structure is > > .\" zeroed out. Why is this done? This should be explained in the manual page. > > .\" > > -- > > 2.42.0.459.ge4e396fd5e-goog > >
Hi Mike, On Mon, Oct 09, 2023 at 11:49:11AM +0300, Mike Rapoport wrote: > On Tue, Sep 26, 2023 at 01:52:34AM +0200, Alejandro Colomar wrote: > > Hi Axel, > > > > On Tue, Sep 19, 2023 at 12:02:03PM -0700, Axel Rasmussen wrote: > > > First, it is not correct that repeated UFFDIO_API calls result in > > > EINVAL. This is true *if both calls enable features*, but in the case > > > where we're doing a two-step feature detection handshake, the kernel > > > explicitly expects 2 calls (one with no features set). So, correct this > > > description. > > > > > > Then, some new error cases have been added to the kernel recently, and > > > the man page wasn't updated to note these. So, add in descriptions of > > > these new error cases. > > > > > > Signed-off-by: Axel Rasmussen <axelrasmussen@google.com> > > > --- > > > man2/ioctl_userfaultfd.2 | 24 +++++++++++++++++++----- > > > 1 file changed, 19 insertions(+), 5 deletions(-) > > > > > > diff --git a/man2/ioctl_userfaultfd.2 b/man2/ioctl_userfaultfd.2 > > > index 53b1f473f..1aa9654be 100644 > > > --- a/man2/ioctl_userfaultfd.2 > > > +++ b/man2/ioctl_userfaultfd.2 > > > @@ -280,17 +280,31 @@ refers to an address that is outside the calling process's > > > accessible address space. > > > .TP > > > .B EINVAL > > > -The userfaultfd has already been enabled by a previous > > > -.B UFFDIO_API > > > -operation. > > > -.TP > > > -.B EINVAL > > > The API version requested in the > > > .I api > > > field is not supported by this kernel, or the > > > .I features > > > field passed to the kernel includes feature bits that are not supported > > > by the current kernel version. > > > +.TP > > > +.B EPERM > > > > This EPERM should probably be at the end. Unless you have a good reason > > to break alphabetic order. > > I agree with Alex here, other than that feel free to add > > Reviewed-by: Mike Rapoport (IBM) <rppt@kernel.org> Thanks. Since v2 only reorders these, I've added your tag. Cheers, Alex > > > > Thanks, > > Alex > > > > > +The > > > +.B UFFD_FEATURE_EVENT_FORK > > > +feature was enabled, > > > +but the calling process doesn't have the > > > +.B CAP_SYS_PTRACE > > > +capability. > > > +.TP > > > +.B EINVAL > > > +A previous > > > +.B UFFDIO_API > > > +call already enabled one or more features for this userfaultfd. > > > +Calling > > > +.B UFFDIO_API > > > +twice, > > > +the first time with no features set, > > > +is explicitly allowed > > > +as per the two-step feature detection handshake. > > > .\" FIXME In the above error case, the returned 'uffdio_api' structure is > > > .\" zeroed out. Why is this done? This should be explained in the manual page. > > > .\" > > > -- > > > 2.42.0.459.ge4e396fd5e-goog > > > > > > > -- > Sincerely yours, > Mike.
diff --git a/man2/ioctl_userfaultfd.2 b/man2/ioctl_userfaultfd.2 index 53b1f473f..1aa9654be 100644 --- a/man2/ioctl_userfaultfd.2 +++ b/man2/ioctl_userfaultfd.2 @@ -280,17 +280,31 @@ refers to an address that is outside the calling process's accessible address space. .TP .B EINVAL -The userfaultfd has already been enabled by a previous -.B UFFDIO_API -operation. -.TP -.B EINVAL The API version requested in the .I api field is not supported by this kernel, or the .I features field passed to the kernel includes feature bits that are not supported by the current kernel version. +.TP +.B EPERM +The +.B UFFD_FEATURE_EVENT_FORK +feature was enabled, +but the calling process doesn't have the +.B CAP_SYS_PTRACE +capability. +.TP +.B EINVAL +A previous +.B UFFDIO_API +call already enabled one or more features for this userfaultfd. +Calling +.B UFFDIO_API +twice, +the first time with no features set, +is explicitly allowed +as per the two-step feature detection handshake. .\" FIXME In the above error case, the returned 'uffdio_api' structure is .\" zeroed out. Why is this done? This should be explained in the manual page. .\"