I don't think we can miss it. To simplify, let's consider kill(-1, SIGKILL)
and the forking process is P.
When P forks, copy_process() adds the child to the end of the init_task.tasks
list under ->siglock.
When kill_something_info()->group_send_sig_info(P) suceeds, we must see the
child, because we locked the same ->siglock and thus we have the necessary
barrier. (more precisely, we must see the new next values once we locked
->siglock). And P can't fork again.
Yes, kill(-1, /*say*/ SIGCONT) is different, we can miss the child which was
forked _after_ P has recieved/handled the signal, but probably this is OK,
we can pretend it was forked after kill(-1) has returned.
The more interesting case: P forks and exits _before_ we send the signal
to it. Can we miss the child? I don't think so, but I'm not sure.
fork() + exit() means list_add_rcu() + wmb() + list_del_rcu().
If we see the result of list_del_rcu() (ie, we don't see P on list), we
must see the result of list_add_rcu(), because of smp_read_barrier_depends()
in next_task().
But again, I'm not sure.
Yes, kill_pid_info() is fine, and other users call group_send_sig_info()
under tasklist.
Or, we can make somthing like
/* needs rcu lock */
int kill_group(int sig, struct siginfo *info, struct task_struct *g)
{
struct task_struct *p = g;
do {
ret = group_send_sig_info(sig, info, p);
if (ret != -ESRCH)
break;
} while_each_thread(g, p);
return ret;
}
Yes, I was wondering about this too.
Oh, I don't know what is supposed semantics. Perhaps this works in
practice during shutdown? we can change the state of /sbin/init so
that it won't spawn the new tasks, and then we can do kill(-1).
I don't know.
Hmm... not sure I understand why do we need find_ge_pid(). In fact,
I can't see which problems we have with kill_something_info() wrt
pid namespaces. I mean it should be changed of course, but these
changes should be relatively simple/straightforward? However I didn't
really think about this, may be wrong.
Oleg.
--
