[v3,1/3] ioctl_userfaultfd.2: clarify the state of the uffdio_api structure on error
Message ID | 20231017230110.3170850-2-axelrasmussen@google.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:612c:2908:b0:403:3b70:6f57 with SMTP id ib8csp4445706vqb; Tue, 17 Oct 2023 16:01:39 -0700 (PDT) X-Google-Smtp-Source: AGHT+IF5EyyOJgn7QAfC2MjBXR0DUAEympxsaE4QsKlUiDLzZGWNDqeMxJzQngkGtvhlpTspS0ZN X-Received: by 2002:a5e:9404:0:b0:792:8011:22f with SMTP id q4-20020a5e9404000000b007928011022fmr3824555ioj.0.1697583699401; Tue, 17 Oct 2023 16:01:39 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1697583699; cv=none; d=google.com; s=arc-20160816; b=QS4pvFBHf79Z55KjSsvLKZbA3nb5eNVuiAhhTiDZui4ReMYpHNQqHvhswPf2sXfr7N Xq+ZsjnQAcrIN9+ipHKwM5D559dHf7vC21FSlGbZpdjP6Sv7biz+sfpre9dEcefjITNz GCmxDXcVY3KPgsHGLxTNK9rJJRDk2OWBKOxc/Rieyna4WJxtzs6SbpIaEkW3IdgOplE7 isJvam+nQ86C+FkHMQHTOL67dKmQXEdCHNhKPiEKPKPwWXgXvEYwQc99h/UKnvVHpwqI j9gNY46D3pyEgiaS40IoShdg7xFvoo+nAdjmRCZB6ZJ09VlnqsKM3ZZPGRsritJcGDek I2qA== 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=JOKJf+aFkcLqb+vIwiVLl6niteK0lFsixSF6GjMiBCE=; fh=/dNG7O5S6JIX0CZzJKQSLFTf7rgQ1Azl+D/Qxa/4VAY=; b=cJ0fw18Hr0aHrGSabDOZva8vW6t6y84t4CU51FJpHQxROctBFdf5C6czq6ZthG3/aQ 6QiPT/Vav1NS7MLnAdm2KoIFkXFT3ZwDgvI8JhULLKXET0zax2eSn9WyMG4S0hlmNbCN x1CAc9pDe7jOqECMU2WopMsO5KQr0cI/MREn86/kXUB49MXLE7d5Nt93uXNvsUgP0LFi iVQdHHzqfAgCYW6wF6kNZxqom119EXR1KdPMiwkjD29y0J45wkm6xvArsiCW0NEXamp9 UaHXM6cdzG7tBrBaNcm3qLJqkuJ6805PCpMcNZDmsydyFFxxcf0mDIl/YtZL2OqHQfie 7omQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20230601 header.b=XbDnJKqY; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:5 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 groat.vger.email (groat.vger.email. [2620:137:e000::3:5]) by mx.google.com with ESMTPS id j11-20020a056a00234b00b0068fb6fc3ff1si2687139pfj.209.2023.10.17.16.01.39 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 17 Oct 2023 16:01:39 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:5 as permitted sender) client-ip=2620:137:e000::3:5; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20230601 header.b=XbDnJKqY; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:5 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 groat.vger.email (Postfix) with ESMTP id 4272380BD5CC; Tue, 17 Oct 2023 16:01:37 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at groat.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1344144AbjJQXBX (ORCPT <rfc822;winker.wchi@gmail.com> + 22 others); Tue, 17 Oct 2023 19:01:23 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49612 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230056AbjJQXBU (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Tue, 17 Oct 2023 19:01:20 -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 E1D3EA4 for <linux-kernel@vger.kernel.org>; Tue, 17 Oct 2023 16:01:18 -0700 (PDT) Received: by mail-yw1-x114a.google.com with SMTP id 00721157ae682-5a7aa161b2fso95697437b3.2 for <linux-kernel@vger.kernel.org>; Tue, 17 Oct 2023 16:01:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1697583678; x=1698188478; 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=JOKJf+aFkcLqb+vIwiVLl6niteK0lFsixSF6GjMiBCE=; b=XbDnJKqYZ7SVFDowWbx/bTwJP8RuE/wzj3iAFiVeoBVOsh0JnRFzaSQfNOZ8jXtDlW 7r5Lrz/e/5SOIsQltFMS8Cf1LnxGI/yKUnO5WVSmmKKbogzTzDW3M4mfNustcE9WieUz Zs1+ApNFlYtQIQaF/nRIcuFHI6EE8zhhcBqYfskyuDllm/A4ShrcW72xxfBxj6KloEON Kw7L08SWmzOXt66Mq2uE8eWP0+hB958idEciAfX9AnnJIAQFAqrwKjbSv1wivrQn+fnf FDKD0HKty0u82itufiL19h6I/6sOdu75whJS17ENM8HpUUXlZoFfR6zzN7FYCiY0m2Fn MsFA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1697583678; x=1698188478; 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=JOKJf+aFkcLqb+vIwiVLl6niteK0lFsixSF6GjMiBCE=; b=rgmPe/enQvZOZQSV6Ghkbqr2dbsLLuPtsJz+UaQKgA1SIcolx299NOdxE1svGFDipR 8hXdyxI7G9g5AXTJxIhTYNemP3rMprIzok5DYHpsnzsoGMxyt8UjpMhsr7sjckFzuth7 YKPAzlvF0cic6DNVWExHXkkD9pqK4KmgB2wsuHzi23jv0XtfnQBQFPiXnvy0MPXY8ETN HDAodkhbKzxFmyyOMj0RUowJXlgAi+yQWzao8wg71BgJka5tzWkGLuQ3cc5lWUgii5w5 UcA9z8LBQiRvNJLB9q3hWKyQIYxKTMM7pVBDnv6uKOTwdCWbty7ZjNISI+UGy4/CXF5d X9jQ== X-Gm-Message-State: AOJu0YyvOWqc4MCUfZ3vkAeenjfJ3f45If1K8Ph759E2iaLB5KfGx+ms B93k0RU2+55Zfunmj+HpiIbQUqS4pZ3sLAzazQ3A X-Received: from axel.svl.corp.google.com ([2620:15c:2a3:200:cd04:35d6:a586:5c86]) (user=axelrasmussen job=sendgmr) by 2002:a0d:d848:0:b0:59b:ec33:ec6d with SMTP id a69-20020a0dd848000000b0059bec33ec6dmr90025ywe.5.1697583678192; Tue, 17 Oct 2023 16:01:18 -0700 (PDT) Date: Tue, 17 Oct 2023 16:01:08 -0700 In-Reply-To: <20231017230110.3170850-1-axelrasmussen@google.com> Mime-Version: 1.0 References: <20231017230110.3170850-1-axelrasmussen@google.com> X-Mailer: git-send-email 2.42.0.655.g421f12c284-goog Message-ID: <20231017230110.3170850-2-axelrasmussen@google.com> Subject: [PATCH v3 1/3] ioctl_userfaultfd.2: clarify the state of the uffdio_api structure on error From: Axel Rasmussen <axelrasmussen@google.com> To: Alejandro Colomar <alx@kernel.org>, Mike Rapoport <rppt@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 groat.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 (groat.vger.email [0.0.0.0]); Tue, 17 Oct 2023 16:01:37 -0700 (PDT) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1780045524937206004 X-GMAIL-MSGID: 1780045524937206004 |
Series |
userfaultfd man page updates
|
|
Commit Message
Axel Rasmussen
Oct. 17, 2023, 11:01 p.m. UTC
The old FIXME noted that the zeroing was done to differentiate the two EINVAL cases. It's possible something like this was true historically, but in current Linux we zero it in *both* EINVAL cases, so this is at least no longer true. After reading the code, I can't determine any clear reason why we zero it in some cases but not in others. So, some simple advice we can give userspace is: if an error occurs, treat the contents of the structure as unspecified. Just re-initialize it before retrying UFFDIO_API again. Reviewed-by: Mike Rapoport (IBM) <rppt@kernel.org> Signed-off-by: Axel Rasmussen <axelrasmussen@google.com> --- man2/ioctl_userfaultfd.2 | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-)
Comments
On Tue, Oct 17, 2023 at 04:01:08PM -0700, Axel Rasmussen wrote: > The old FIXME noted that the zeroing was done to differentiate the two > EINVAL cases. It's possible something like this was true historically, > but in current Linux we zero it in *both* EINVAL cases, so this is at > least no longer true. > > After reading the code, I can't determine any clear reason why we zero > it in some cases but not in others. So, some simple advice we can give > userspace is: if an error occurs, treat the contents of the structure as > unspecified. Just re-initialize it before retrying UFFDIO_API again. > > Reviewed-by: Mike Rapoport (IBM) <rppt@kernel.org> > Signed-off-by: Axel Rasmussen <axelrasmussen@google.com> Hi Axel, Patch applied. Thanks, and thank you too Mike for the review. Cheers, Alex > --- > man2/ioctl_userfaultfd.2 | 16 ++++++++-------- > 1 file changed, 8 insertions(+), 8 deletions(-) > > diff --git a/man2/ioctl_userfaultfd.2 b/man2/ioctl_userfaultfd.2 > index e68085262..82aee667c 100644 > --- a/man2/ioctl_userfaultfd.2 > +++ b/man2/ioctl_userfaultfd.2 > @@ -272,6 +272,14 @@ operation returns 0 on success. > On error, \-1 is returned and > .I errno > is set to indicate the error. > +If an error occurs, > +the kernel may zero the provided > +.I uffdio_api > +structure. > +The caller should treat its contents as unspecified, > +and reinitialize it before re-attempting another > +.B UFFDIO_API > +call. > Possible errors include: > .TP > .B EFAULT > @@ -305,14 +313,6 @@ feature was enabled, > but the calling process doesn't have the > .B CAP_SYS_PTRACE > capability. > -.\" 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. > -.\" > -.\" Mike Rapoport: > -.\" In my understanding the uffdio_api > -.\" structure is zeroed to allow the caller > -.\" to distinguish the reasons for -EINVAL. > -.\" > .SS UFFDIO_REGISTER > (Since Linux 4.3.) > Register a memory address range with the userfaultfd object. > -- > 2.42.0.655.g421f12c284-goog >
diff --git a/man2/ioctl_userfaultfd.2 b/man2/ioctl_userfaultfd.2 index e68085262..82aee667c 100644 --- a/man2/ioctl_userfaultfd.2 +++ b/man2/ioctl_userfaultfd.2 @@ -272,6 +272,14 @@ operation returns 0 on success. On error, \-1 is returned and .I errno is set to indicate the error. +If an error occurs, +the kernel may zero the provided +.I uffdio_api +structure. +The caller should treat its contents as unspecified, +and reinitialize it before re-attempting another +.B UFFDIO_API +call. Possible errors include: .TP .B EFAULT @@ -305,14 +313,6 @@ feature was enabled, but the calling process doesn't have the .B CAP_SYS_PTRACE capability. -.\" 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. -.\" -.\" Mike Rapoport: -.\" In my understanding the uffdio_api -.\" structure is zeroed to allow the caller -.\" to distinguish the reasons for -EINVAL. -.\" .SS UFFDIO_REGISTER (Since Linux 4.3.) Register a memory address range with the userfaultfd object.