This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Add finit_module syscall for Linux


On Fri, Jan 25, 2013 at 07:53:06PM -0500, KOSAKI Motohiro wrote:
> 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.

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.

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

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.

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

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

Look, we identified a man page bug that should be fixed. :-)

Rich


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]