Re: Specific Linux syscalls for glibc API

[Adhemerval Zanella <adhemerval dot zanella at linaro dot org>]

On 18-11-2015 14:32, Rich Felker wrote:
> 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.

Do we really have a compelling reason for gettid? Although I noted it is
used on about 300 pages on debian (using codesearch.debian.net) mostly
cases are used for thread debug functions.  For instance, analysing
some packages usages:

SYS_gettid - 300 packages

hwloc:
  Used internally on hwloc_linux_get_tid_last_cpu_location to read /proc/<tid>/stat
  of current thread.

gxine / strongswan / libaria
  Used on thread debug reports

suricata
  Used with sched_setaffinity

llvm / gperftools
  On wrapper for sanitizer and lldb

The 'suricata' case is IMHO an interface abuse, this could easily replace by
pthread_setaffinity_np. The llvm and gperftools are wrappers to code
instrumentation, which at least for sanitizer case it is required. The debug
case I am still trying to check it is still something worth to take in
consideration, since debug information falls in a place where the information
depends of the context and the person analysing it.

> 
>> (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
>