From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 105953 invoked by alias); 10 Oct 2019 14:49:30 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 105945 invoked by uid 89); 10 Oct 2019 14:49:30 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-5.9 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS autolearn=ham version=3.3.1 spammy=H*f:sk:87v9syy, H*f:sk:87bluq1, H*f:sk:5cab2cb, H*f:sk:87zhiay X-HELO: mx1.redhat.com From: Florian Weimer To: Christian Brauner Cc: Adhemerval Zanella , libc-alpha@sourceware.org Subject: Re: [PATCH] [GLIBC RFC] clone3: add CLONE3_RESET_SIGHAND References: <20191008134417.16113-1-christian.brauner@ubuntu.com> <5cab2cbb-e72b-4eb0-5271-1a90c4e8de95@linaro.org> <20191009104830.w2fkr4m3lrkfowxq@wittgenstein> <87bluq18po.fsf@oldenburg2.str.redhat.com> <20191009111200.rfqlk5lgityhi6rl@wittgenstein> <87zhiayvxc.fsf@oldenburg2.str.redhat.com> <20191009115846.xs4uou6c2x67pqz7@wittgenstein> <87v9syyvpd.fsf@oldenburg2.str.redhat.com> <20191009133340.enhosv6yyfd2gpsq@wittgenstein> <20191010105116.74ciqdrecmrw65l6@wittgenstein> Date: Thu, 10 Oct 2019 14:49:00 -0000 In-Reply-To: <20191010105116.74ciqdrecmrw65l6@wittgenstein> (Christian Brauner's message of "Thu, 10 Oct 2019 12:51:18 +0200") Message-ID: <878spsodu1.fsf@oldenburg2.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-SW-Source: 2019-10/txt/msg00300.txt.bz2 * Christian Brauner: > Ok, I need to be annoying once more. (As if there wasn't enough of that > already...) > So kernel-side a good friend of mine - Aleksa - and I are on the way to > push through _some_ standards... That very much includes how we check > for new extensions in syscalls. So we just discussed my earlier proposal > (Sorry for the lag the distance Australia to Germany makes things a bit > difficult.). One problem we'll have with adding a new member is that we > arguably need one for each additional flag member we add. That means > we'd need: > > struct clone_args /* initial struct */ { > __aligned_u64 flags; > __aligned_u64 supported_flags; > } > > and later > > struct clone_args /* extended struct: new flags argument added */ { > __aligned_u64 flags; > __aligned_u64 supported_flags; > __aligned_u64 flags2; > __aligned_u64 supported_flags2; > } > > which is not ideal. So we were thinking about a different protocol for > syscalls which embedd flags arguments in structs. Is that really a bad problem? > We'd introduce a new flag > > #define SYSCALL_CHECK_FLAGS ((1 << 63)ULL) > > that can be used by e.g. clone3() and openat2(). Then you can call the > syscall with: > > struct clone_args args = { > .flags |= SYSCALL_CHECK_FLAGS, > }; > pid = clone3(&args, sizeof(args)); > > /* > * The kernel now sets all flags it supports in _all_ flags arguments > * present in the struct. > */ > > SYSCALL_CHECK_FLAGS is only valid in the initial flags argument not in > any added flags arguments. > If SYSCALL_CHECK_FLAGS is not supported then you'll get EINVAL and the > SYSCALL_CHECK_FLAGS flag is still present in the flags argument of the > struct. If it is supported it'll be masked out and all supported flag > bits will be set by the kernel in _all_ flag arguments that are present > in the structure. > Florian, thoughts? Will SYSCALL_CHECK_FLAGS be for probing only and not perform any action at all? I mean, it behaves like this on older kernels due to the EINVAL error. I'm not yet decided if we'll need a separate system call wrapper for cloning on the same stack, for safe(r) use with vfork. If we do, we'll have to teach the wrapper about SYSCALL_CHECK_FLAGS, too, I think. If a call with SYSCALL_CHECK_FLAGS and all supported flags performs the requested clone action, that would be easier for us. But I don't know if that makes a convenient interface for programmers. Thanks, Florian