Re: Specific Linux syscalls for glibc API

[Rich Felker <dalias at libc dot org>]

On Wed, Nov 18, 2015 at 11:07:06AM +0100, Florian Weimer wrote:
> On 11/17/2015 05:34 PM, Joseph Myers wrote:
> 
> > Old functions (where any relevant syscalls have been in the kernel since 
> > 3.2 or earlier, when routine addition of syscall wrappers to glibc 
> > stopped):
> > 
> > * gettid, pthread_gettid_np (bug 6399).
> 
> I have no problem with adding those for Linux only.  I have some
> concerns about exposing them as a general (OS-independent) interface
> because they NPTL deals with TIDs appears quite broken.  On the other
> hand, it looks like a better implementation would support all uses cases
> currently supported by NPTL in a race-free manner, and some other useful
> scenarios as well.

It should be noted that there are some serious caveats to using tids
directly. Unlike pthread_t, a tid is immediately freed and available
for reuse as soon as the thread exits. This means additional
synchronization with the target thread's exit is required to avoid
TOCTOU races when use them.

I don't think this is a reason not to support gettid, but it _might_
be a reason not to support pthread_gettid_np -- you cannot safely
get/use _another_ thread's tid without synchronizing with it to ensure
that it doesn't exit before your use.

Either way, this needs to be documented very well in the manual,
because I don't think most potential users of the interfaces are aware
of this risk.

> (My concern is that TIDs are invalidated before pthread_join is called.)
> 
> > * futex and more specific futex_* interfaces for individual operations 
> > (bug 9712).
> 
> I think we should treat futex like socketcall and not wrap it.  We
> discussed this in the context of the the open wrapper, and it turned out
> impossible to intercept and forward such a vararg call properly in C
> code.  Exposing individual futex operations as functions is a good idea.

I want to see both exported unless you intend to export all of the
futex commands, even the ones that have erroneously been treated as
obsolete just because glibc has no internal use for them anymore.

Rich