Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp1806396ybl; Thu, 19 Dec 2019 03:21:38 -0800 (PST) X-Google-Smtp-Source: APXvYqxXX/FnzoxyjHSFDir0NYPv9CZqSUpqOoVDqGt4dIRt0U+/tdvXqxfCaF+A63MOID+Q1hjF X-Received: by 2002:a9d:4f18:: with SMTP id d24mr2741189otl.179.1576754498718; Thu, 19 Dec 2019 03:21:38 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1576754498; cv=none; d=google.com; s=arc-20160816; b=xwDf4YOoZ4xqB+QrfuxI0XUgbOdJ9Xzjnl3BP7i/fYRcYlTGi4vj7C2UXRW5nCspjv LI2ZbQc4wkgmAV88ID0gHLhinL3Y0l7AoZmW8IcQ9PybfNiHGLAXYPj5G42d38gEtqYX MCDxnHb0dz0cnfh+nGcoTM4wRAHwSJlQicK7WI+PHdaIs0W3/S7VfwU8r4Q2pbhGhwvO s4cGcLkDE7FTwzyLK9hY0uCc2+MgZX+HQoziI5uc/daXpube/pLSGgcGI6jhyrLrR/Ow FfN5bCGaSzpWbVc+qE0C+XFj8kIxobQASpRjbOKkd0AmPcWerJpxm0hwyY5hz1h27Q1c EtYw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=9BkVdQCTc0jvIj80oSHuwBshOqq5YofspkI4BBMWQU8=; b=aD+Y/GRERjq/kIzwlKzky157m4ttaEPt5LsllqcHqXSJvPNMR7NLAcEUxRjmQOXzrj ha9wSQ09+WD8dbs5FCgLUQHSLIbcX917Wla66dipyZTWJ2jLeuC4AO33w6McSs3mBI/I 7PGr4yWBgFaCQg6UERjZzC5KY/IvtSpzmkb7YxvYk9xXt+CgkaGikGXSiOeGlhwofBVi Lr9MJhNaS2Q27oBBwxFvf3dhEdG8Og2ukuzrmYmKADtqlSM5rYyDfwFskpLUxvU13j3h bSrBD5wzrKzJ1n1tUSMN0xAlTJngZMSkaGbW8/CUDfYWFM3nC9XT+EBeYcFU41bCc2Y8 JTYg== 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 r14si2754446oic.12.2019.12.19.03.21.26; Thu, 19 Dec 2019 03:21:38 -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 S1726879AbfLSLUC (ORCPT + 99 others); Thu, 19 Dec 2019 06:20:02 -0500 Received: from youngberry.canonical.com ([91.189.89.112]:38646 "EHLO youngberry.canonical.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726719AbfLSLUB (ORCPT ); Thu, 19 Dec 2019 06:20:01 -0500 Received: from [79.140.121.60] (helo=wittgenstein) by youngberry.canonical.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.86_2) (envelope-from ) id 1ihtqR-0003c3-2B; Thu, 19 Dec 2019 11:19:51 +0000 Date: Thu, 19 Dec 2019 12:19:50 +0100 From: Christian Brauner To: Aleksa Sarai Cc: Alexander Viro , Jeff Layton , "J. Bruce Fields" , Shuah Khan , Florian Weimer , David Laight , 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: Re: [PATCH 0/2] openat2: minor uapi cleanups Message-ID: <20191219111949.auriw6biphxxvdng@wittgenstein> References: <20191219105533.12508-1-cyphar@cyphar.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20191219105533.12508-1-cyphar@cyphar.com> User-Agent: NeoMutt/20180716 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Dec 19, 2019 at 09:55:28PM +1100, Aleksa Sarai wrote: > 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. Am I imagining things or did I get the same patch series twice? Christian