On 12/17, Eric W. Biederman wrote: > > I am sitting here wondering why we bother to ignore init, as init > is protected from all signals it doesn't explicitly setup a signal > handler for. > ... > So I believe we can delete we can delete > the is_init check entirely without changing anything and with a less > surprising if anyone ever cares.
is_init() is very cheap. But if we send a signal and it is not ignored we will wake up /sbin/init without good reason, just to complete unneded do_signal(). Also, we may have a special setup so that this signal really means something for init (and it has a handler for). In that case the caller of kill(-1, sig) will be surprised. Btw, de_thread() already takes care about multithread init, but get_signal_to_deliver() does not: if (current == child_reaper(current)) continue; // handle sig_kernel_stop()/sig_fatal() This doesn't protect init from SIGKILL if we send it to sub-thread (and this can happen even if we use kill(1, sig), not tkill). Yes, the main thread will survive, but still this is not what we want. SIGSTOP will manage to stop entire group because sub-thread sets ->group_stop_count. > > Christoph Hellwig <[EMAIL PROTECTED]> writes: > > > > This also looks rather unreadable, an > > > > } else if (pid) { > > ret = kill_pgrp_info(sig, info, find_pid(-pid)); > > } else { > > ret = kill_pgrp_info(sig, info, task_pgrp(current)); > > } > > > > might be slightly more code, but also a lot more readable. I personally disagree, but this is matter of taste. Ok, it was a cleanup only, let's forget it. Still I don't like "p->pid > 1" check. And I don't think we need a new helper (pid_leader or such) now. When we have multiple pid namespaces we should rework kill(-1, sig) anyway. Right now this check means "skip init", nothing more. Oleg. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/