Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp1781066ybl; Thu, 19 Dec 2019 02:57:15 -0800 (PST) X-Google-Smtp-Source: APXvYqwt16CHvr7nrOV/l4BGwJpv5SrosWYriub+QOXrGRWJbg4sHW/wtIuRvGnHTN2TuaOwZzi+ X-Received: by 2002:a9d:3b5:: with SMTP id f50mr7892634otf.354.1576753035356; Thu, 19 Dec 2019 02:57:15 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1576753035; cv=none; d=google.com; s=arc-20160816; b=Exj0/ETZD14F5B0LJOBDsSBqGv+JLCJGdBeRKfPt8bwqTvJKAiG5NYHDTGc4AJ5uIX 7qaMksdWJr5mrmy0zyTbNwAhGjxzn/2zHVmJM7mVq+7/6KCdBnCEe3fQiGPTgh0Y9yjg oKL0pu26XX+WpGm+ovEoYcxN9Rr2BrtuH89mWbun8/c96HSCJjEEKN1IwdaegZdEFD1r 86Mfu0XD+0lyzQwxh4k4ANdderzlsidofSbU3YfutqHuQsf0uEirZNTcwVu0cXnZgSQl 20ZBZ1/jcQbPd7VblAusrf02AdV3w6069u56mYfdxujDzA1DwEK4bWyl5k5uRIbL4EYi tCsA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from; bh=k/ADC7/zyDs9kypvnbQTAQ43s3MccHy+67hQqHcJHGo=; b=wG1JamhuwM8+2M+URPCMCLMrulocJFx3W27RvoUQCjS2aTxyWRdfng9KVJfDTb53WQ hNjuvihoRKHiAUZOoBBzxnIKTU/V8dHQPUvsGQ7hVwx3PIB9jd5KOxkaytIQu/Q8SwOp IOCnnPCcjCLiFuJhT9+2sVY3rT3dbkRLdF52iQ2WbWEYWZR6mwvM55TuJqqzQuUZwdHi KZrKcHKbzDjtNKmCgceuAm2tZOUjyk+ZUP9P4pYaQizHAOMXv/3QOA7UE1s836/YdYfJ nPzjDqkkUxSkTS7p4WYIOVP6EYCUnXkYwYIA5T1McGEN1Ii7LJS8R86lwuKoFr7L4jhx zh7w== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id d17si2281527oib.174.2019.12.19.02.57.02; Thu, 19 Dec 2019 02:57:15 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726730AbfLSK4U (ORCPT + 99 others); Thu, 19 Dec 2019 05:56:20 -0500 Received: from mout-p-102.mailbox.org ([80.241.56.152]:12528 "EHLO mout-p-102.mailbox.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726633AbfLSK4U (ORCPT ); Thu, 19 Dec 2019 05:56:20 -0500 Received: from smtp1.mailbox.org (smtp1.mailbox.org [IPv6:2001:67c:2050:105:465:1:1:0]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by mout-p-102.mailbox.org (Postfix) with ESMTPS id 47dphf2kC2zKmj1; Thu, 19 Dec 2019 11:56:18 +0100 (CET) X-Virus-Scanned: amavisd-new at heinlein-support.de Received: from smtp1.mailbox.org ([80.241.60.240]) by spamfilter05.heinlein-hosting.de (spamfilter05.heinlein-hosting.de [80.241.56.123]) (amavisd-new, port 10030) with ESMTP id iQ2uzmv5ZKGl; Thu, 19 Dec 2019 11:56:14 +0100 (CET) From: Aleksa Sarai To: Alexander Viro , Jeff Layton , "J. Bruce Fields" , Shuah Khan Cc: Aleksa Sarai , Florian Weimer , David Laight , Christian Brauner , dev@opencontainers.org, containers@lists.linux-foundation.org, libc-alpha@sourceware.org, linux-api@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org Subject: [PATCH 0/2] openat2: minor uapi cleanups Date: Thu, 19 Dec 2019 21:55:28 +1100 Message-Id: <20191219105533.12508-1-cyphar@cyphar.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org While openat2(2) is still not yet in Linus's tree, we can take this opportunity to iron out some small warts that weren't noticed earlier: * A fix was suggested by Florian Weimer, to separate the openat2 definitions so glibc can use the header directly. I've put the maintainership under VFS but let me know if you'd prefer it belong ot the fcntl folks. * Having heterogenous field sizes in an extensible struct results in "padding hole" problems when adding new fields (in addition the correct error to use for non-zero padding isn't entirely clear ). The simplest solution is to just copy clone(3)'s model -- always use u64s. It will waste a little more space in the struct, but it removes a possible future headache. Aleksa Sarai (2): uapi: split openat2(2) definitions from fcntl.h openat2: drop open_how->__padding field MAINTAINERS | 1 + fs/open.c | 2 - include/uapi/linux/fcntl.h | 37 +---------------- include/uapi/linux/openat2.h | 40 +++++++++++++++++++ tools/testing/selftests/openat2/helpers.h | 3 +- .../testing/selftests/openat2/openat2_test.c | 24 ++++------- 6 files changed, 51 insertions(+), 56 deletions(-) create mode 100644 include/uapi/linux/openat2.h base-commit: 912dfe068c43fa13c587b8d30e73d335c5ba7d44 -- 2.24.0