Re: [musl] Fix the return value of pthread_getschedparam in musl libc

["dalias@aerifal.cx" <dalias@aerifal.cx>]

On Thu, May 28, 2020 at 02:27:55PM +0000, tangyizhou wrote:
> > There's not such an issue. t->killlock is held so that this can't
> > happen, and more importantly, so that the thread can't exit and
> > the tid be reassigned to a new thread or process that would
> > wrongly be acted upon.
> 
> Sorry for late reply.
> 
> t->killlock is held only in pthread functions, and it won't work in
> the following situation. Assuming process A is running on CPU core
> 0, process B is running on CPU core 1, process C is running on CPU
> core 2. Process A calls pthread_getschedparam() to query the
> information of process B.

This is not possible. pthread_getschedparam operates on threads not
processes. A pthread_t is only valid in the context of a process.
There is simply no way to pass a pthread_t for a thread in a different
process, because the identifiers are in a separate space. Two
pthread_t values could be numerically identical but refer to
completely different threads, or one of them be invalid, just because
they're local to the process -- and mechanically, the address space --
they're in.

> After SYS_sched_getparam succeeds and
> before SYS_sched_getscheduler starts, we assume the scheduling
> timeslice of A is running out, then A is put in the runqueue of the
> kernel. This is a chance for C to call kill() to kill B. When A is
> running again, SYS_sched_getparam returns -ESRCH.

You seem to be confusing threads and processes. kill signals processes
not threads. It's possible to send a signal to a particular thread;
there's a standard interface to do this within a process,
pthread_kill, and you could go outside the standard interfaces and do
it cross-process using kernel tids with tkill. But that does not cause
the thread to cease to exist. It makes a signal pending for the
thread, and depending on the action for that signal, it may either
cause a signal handler to run or cause *the whole process* to
terminate.

There is no way to forcibly terminate a single thread, from within the
same process or a different one, short of UB or using trace/debugging
type interfaces to attach to the process and do bad things to it.

> Process B may be terminated due to other reasons when A is put in
> the runqueue. For example, B is running and encounters a bus error,
> then B is terminated because of SIGBUS signal.

If SIGBUS is not caught, the whole *process* terminates, not the
thread.

> It very hard to see these situations, but they exist in a
> theoretical way. There isn't such an issue for the implementation of
> pthread_getschedparam() of glibc.

These are non-issues based on your misunderstanding of what threads
are.

Rich