Messages in this thread | | | From | (Eric W. Biederman) | Date | Mon, 16 Jul 2018 09:50:20 -0500 | Subject | Re: [RFC][PATCH 07/11] signal: Deliver group signals via PIDTYPE_TGID not PIDTYPE_PID |
| |
Oleg Nesterov <oleg@redhat.com> writes:
> On 07/10, Eric W. Biederman wrote: >> >> Now that we can make the distinction use PIDTYPE_TGID rather than >> PIDTYPE_PID. > > Wai, wait, this doesn't look right... > >> There is no immediate effect as they point point at the >> same task, > > How so? pid_task(pid, PIDTYPE_TGID) will return NULL unless this pid is actually > a group leader's pid, > >> --- a/kernel/signal.c >> +++ b/kernel/signal.c >> @@ -1315,7 +1315,7 @@ int kill_pid_info(int sig, struct siginfo *info, struct pid *pid) >> >> for (;;) { >> rcu_read_lock(); >> - p = pid_task(pid, PIDTYPE_PID); >> + p = pid_task(pid, PIDTYPE_TGID); >> if (p) >> error = group_send_sig_info(sig, info, p); > > So, currently kill(pid_nr) always works, even if pid_nr is a sub-thread's tid. > > After this change kill(2) will always fail with -ESRCH in this case. > > Or I am totally confused?
No you are not.
That does at least need to be documented in the description of the patch.
In practice since glibc does not make thread id's available I don't expect anyone relies on this behavior. Since no one relies on it we can change it without creating a regression.
I believe this can be described as fixing a bug that we were not able to before the introduction of PIDTYPE_TGID.
I will update my change description.
Eric
| |