This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]


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?


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]