Re: [PATCH] Add finit_module syscall for Linux

[KOSAKI Motohiro <kosaki dot motohiro at gmail dot com>]

>> As you know, kill(2) has the exact same issue and pthread_kill() was naturally
>> derived from it. And we lived with kill() long time.
>>
>> In almost all case, ID reassignment is enough strong reason to avoid
>> pthread_kill.
>> However, in several case, application have "no new thread"
>> guarantee. therefore your worst scenario can't be happen.
>
> The values of pthread_t are not required to be thread-local. If
> pthread_t were a kernel-level tid, the natural implementation would
> use tkill, not tgkill, which would allow signaling threads in other
> processes. There's no fundamental reason the implementation needs to
> prevent such a thing, since it's UB anyway.

Sorry, I wouldn't join which is natural. Even though I don't agree with you, we
can't persuade each other. "Natural" seems subjective argument to me.


> Neither kill nor pthread_kill have race conditions if used correctly.
>
> For pthread_kill, the pthread_t value is only meaningful within the
> same process, and a correctly-written application would not even
> possess the pthread_t value anymore once pthread_join has been called
> on the thread (and would not even store the pthread_t value for a
> detached thread unless it were using some other method aside from
> joining to synchronize with thread completion). Following such
> practices, any use of a pthread_t value you still have with
> pthread_kill avoids invoking UB.
>
> For kill, the only way to use it without races is for your own child
> processes on which you have not yet waited.

I agree application can avoid an issue if it will be rewritten.
However, I also don't
want  to join supposition and application blaming. Especially when I'm
not developer
of the applications and the fault come from historical reason. sorry.

I have several chance to know several real world application issue and
then I talk about it sometimes. However please don't think I blame
libc. I just talk about an issue, not more.
I'm ok to keep status quo. oh, say, I never say pthread_self() should
be changed.


>> more offtopic. I think current man pages is misleading.
>>
>> http://man7.org/linux/man-pages/man3/pthread_kill.3.html
>>
>> >ERRORS
>> >
>> >       EINVAL An invalid signal was specified.
>> >       ESRCH  No thread with the ID thread could be found.
>>
>> I can't parse this sentence mean pthread_kill() can cause SEGV
>> if no thread could be found. I'm not surprised if people parse this as
>> pthread_kill() always return ESRCH, not crash when no such id.
>
> Indeed, this should be filed as a bug against the man page. In
> particular, the man page should include this text from POSIX XSH
> 2.9.2:
>
> "The lifetime of a thread ID ends after the thread terminates if it
> was created with the detachstate attribute set to
> PTHREAD_CREATE_DETACHED or if pthread_detach() or pthread_join() has
> been called for that thread. A conforming implementation is free to
> reuse a thread ID after its lifetime has ended. If an application
> attempts to use a thread ID whose lifetime has ended, the behavior is
> undefined."
>
> In particular, passing such a thread ID to pthread_kill is UB.

created an ticket of man pages.

https://bugzilla.kernel.org/show_bug.cgi?id=53061

Thank you for pointing exact paragraph.