This is the mail archive of the libc-alpha@sourceware.org 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]

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


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