Re: [PATCH] Add finit_module syscall for Linux

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

On Fri, Jan 25, 2013 at 6:21 PM, Rich Felker <dalias@aerifal.cx> wrote:
> On Fri, Jan 25, 2013 at 05:20:22PM -0500, KOSAKI Motohiro wrote:
>> >> I have no idea how to return -ESRCH if using pointer. Do you have?
>> >
>> > there's no requirement to do so; in fact, doing so is harmful because
>> > the code may seem to work (kill failing) but then signal the wrong
>> > thread if the same tid got reassigned to a new thread. any use of a
>> > pthtead_t after its lifetime is a serious programming error that is
>> > fundamentally undetectable, just like using a pointer to malloc'd
>> > memory after it was freed or using a pid aftef it was waited on.
>>
>> Even though some one says "it's no requirement". Such applications don't
>> vanish.
>
> I don't see any reason to believe such applications exist. Even if
> they do, they're already very unreliable, it's not doing anyone a
> service to make these applications appear to work correctly 99% of the
> time and crash the other 1% of the time. It just leads to serious bugs
> going undetected. Even if the implementation does "detect" use a
> pthread_t whose lifetime has ended (e.g. by its presence in the cache
> of stacks for reuse), the proper behavior is to call abort() or
> otherwise crash, not to return ESRCH. Aborting is legal (conforming)
> because the application has invoked undefined behavior (by using a
> pthread_t whose lifetime has ended).

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.

Most reasonable case of as far as I observed, some HPC users have such usecase.
The applications cancel a calculation if it is too costly than expected.


And yes, I observed kill() was abused repeatedly and made serious
issue. Example,
Many daemon management tool have a feature to restart a daemon when daemon
was crached. And, at that time, send SIGKILL an old pid to avoid
accidental living dead daemon issue. however, of course, it often made
to kill innocent processes. I completely
agree with you, kill() and pthread_kill() have a race since it was born.

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.


>> I agree id reassignment issue can be happen. however it doesn't
>> bring any happy to applications.
>>
>> But anyway this is highly off topic. I have to stop hijack the thread.
>
> It may be mildly off-topic for the thread, but I think it's on-topic
> for this list in general.

Thank you.