Re: What's the best solution for getting me a cancellable FUTEX_WAIT?

[Steven Stewart-Gallus <sstewartgallus00 at mylangara dot bc dot ca>]

> They make problematic for applications to make syscalls directly,
> since the application is then unlikely to be portable to all archs.

This is the kind of broken kernel interface that I hate. This is NOT a
reason to make it more difficult to use the kernel APIs.

> Are you volunteering to document that list? :)

I already noted that I need to use futexes but I'll probably need to
use set_robust_list at some point. pivot_root is a system call which
is useful when using CLONE_NEWNS for sandboxing as it is much simpler
and more obviously correct than the move mount. GLibc forces one to
specify an alternate stack when using clone so it's easiest to use the
system call directly. Many times one needs to use gettid. In a few
cases one needs to use getpid directly because of GLibc's caching
behaviour.As well, one has to use getdents directly when one needs to
write asynch-signal safe code as opendir and readdir can allocate and
aren't reentrant. These are all the cases that I can thing of right
now. Aside from those cases, whenever any new system call is created
one either has to wait for GLibc to wrap it or one can call it
directly oneself.

> Using clone() "directly" with CLONE_NEWUSER should work as long as
> you don't use CLONE_VM. Updating of cached pid takes place
> automatically in glibc.

GLibc forces one to specify an alternate stack when using clone so
it's easiest for me to use the system call directly.

> Making the syscall yourself is a very bad idea because clone has one
> of the most notoriously arch-specific call signatures.

Again, this is the kind of broken kernel interface that I hate. This
is NOT a reason to make it more difficult to use the kernel APIs.

> Not the case. A good example of this and other issues below is
> SYS_rt_sigaction. Not only does the struct vary by arch; it also
> differs between userspace and kernelspace, and on some archs, you MUST
> add SA_RESTORER and set pointers to functions written in asm that make
> a SYS_sigreturn or SYS_rt_sigreturn syscall after adjusting the stack
> pointer appropriately. This is NOT the kind of code that belongs in
> individual applications.

Again, this is the kind of broken kernel interface that I hate. This
is NOT a reason to make it more difficult to use the kernel APIs.

> Actually sigaction is also potentially an example of the above
> (caching), since there's a proposal for glibc to wrap signal handlers
> to save/restore errno and possibly other state. Going around libc and
> calling SYS_rt_sigaction yourself would of course break this. And
> perhaps more importantly, even now, if you happened to call
> SYS_rt_sigaction with one of the signal numbers reserved for internal
> use by the threads implementation, you could badly break multithreaded
> code in the same process.

I don't need to call sigaction myself so what's your point? This is a
straw man. I'm not advocating calling functionality like sigaction for
oneself, I'm advocating calling simple and easy to use functionality
like futex oneself.

> Basically, I think there's a huge volume of knowledge that's needed
> for making syscalls directly from applications to be "safe", at
> present it's undocumented, and documenting it tends to lock in
> current libc implementation choices that may turn out to be bad in
> the future (by officially "allowing" certain direct syscall usage
> that would admit a better libc implementation if it were
> disallowed).

Please give an example that's not a straw man.

> I think the burden to document relies on whoever wants this to be a
> documented public interface, not those who say it shouldn't be.

What the fsck is wrong with you? The Linux kernel is an entirely
separate project from GLibc and the less magic voodoo that the two use
to interface the more everybody benefits. This attitude that some
things are for GLibc to know and not for others is idiotic. Besides,
didn't you write your own libc with musl? How can you possibly
advocate for less documentation when it would directly help you and
people like you?

> On ILP32 and LP64 models (which are always used on Linux), intptr_t
> has the same size/range/representation as long, so that does not
> solve the problem.

Right, I was mistaken there. What syscall should really take is
arguments that are the size of the biggest integral register type.

> Yes, the system call does have alignment requirements. However that
> could be an additional documented part of the API rather than
> (non-)enforced via the type system. I hadn't even thought of
> unsigned, but of course that's a really good point too; in practice,
> the data usually is unsigned (e.g. using 0x80000000 as a flag rather
> than a sign bit) even when the type is nominally signed. In
> principle you could also use futex with pointers on ILP32 targets,
> but of course this would be bad since the code would not be portable
> to 64-bit...

It might have been smarter when making the system call originally that
it used pointer size types but now it is too late to change that. Oh
well.

> Rich

Thank you for hearing me out,
Steven Stewart-Gallus