This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] [GLIBC RFC] clone3: add CLONE3_RESET_SIGHAND
On Thu, Oct 10, 2019 at 04:49:26PM +0200, Florian Weimer wrote:
> * 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?
Kernel people don't like wasting space so yes... :)
In other words, we need to come up with something that we can convince
both sides is useful.
>
> > 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.
Right, that's a good question.
I think we want it to only report features.
I'll need to think about this for a bit.
If this flag doesn't cause any action then we need to report a
meaningful error to the caller.
>
> 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.
Phew... That's a hard decision to make but it feels wrong to mix these
semantics.
Christian