From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13111 invoked by alias); 9 Oct 2019 10:48:49 -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 13015 invoked by uid 89); 9 Oct 2019 10:48:41 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham version=3.3.1 spammy=Brauner, brauner, act X-HELO: youngberry.canonical.com Date: Wed, 09 Oct 2019 10:48:00 -0000 From: Christian Brauner To: Adhemerval Zanella Cc: Florian Weimer , libc-alpha@sourceware.org Subject: Re: [PATCH] [GLIBC RFC] clone3: add CLONE3_RESET_SIGHAND Message-ID: <20191009104830.w2fkr4m3lrkfowxq@wittgenstein> References: <20191008134417.16113-1-christian.brauner@ubuntu.com> <5cab2cbb-e72b-4eb0-5271-1a90c4e8de95@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <5cab2cbb-e72b-4eb0-5271-1a90c4e8de95@linaro.org> User-Agent: NeoMutt/20180716 X-SW-Source: 2019-10/txt/msg00242.txt.bz2 On Tue, Oct 08, 2019 at 11:20:08AM -0300, Adhemerval Zanella wrote: > > > On 08/10/2019 10:44, Christian Brauner wrote: > > Reset all signal handlers of the child not set to SIG_IGN to SIG_DFL. > > Mutually exclusive with CLONE_SIGHAND to not disturb other threads > > signal handler. > > > > Questions for glibc before going to send this for review on lkml: > > - Is it sufficient for glibc to get EINVAL when CLONE3_RESET_SIGNALS is > > passed to determine kernel support for it? > > It makes the clone/clone3 call on posix_spawn somewhat more complex, something > like: > > #ifdef __ASSUME_CLONE3 > /* This clone3 is modelled with glibc clone semantics where a function > pointer is passed and executed in child process. */ > new_pid = clone3 (__spawni_child, __spawni_args, > &((struct clone_args) {CLONE3_RESET_SIGHAND, ... }), ...); > if (new_pid == -1 && errno == EINVAL) > { > __spawni_args.xflags |= RESET_SIGNALS; > new_pid = clone3 (__spawni_child, __spawni_args, > &((struct clone_args) {0, ... }), ...); > } > #else > __spawni_args.xflags |= RESET_SIGNALS; > new_pid = clone (__spawni_child, __spawni_args, ...); > #endif > > We can add __ASSUME_CLONE3_RESET_SIGHAND which would allow to not require > check for EINVAL, but it would be another build permutation... > > Is there a way to advertise it to *child* process somehow? Now that flags > is passed in a struct, maybe reset the flags that current kernel does not > accept so underlying process could act accordantly? I've been thinking about two things how to do this: - mask the flags that the kernel does not support - add another argument to struct clone_args that is "known_flags" when the syscall returns it'll be set to all the flags this kernel knows about The advantage with the latter method is that the struct get's extended with an additonal argument. And since clone3() deals with larger structs correctly you can pass a larger struct from userspace with the known_flags member included and if it is non-zero when clone3() returns you know a) that this kernel supports the known_flags extension and b) you know what flags this kernel supports... Florian, Adhmerval et al. what would you prefer? Christian