Messages in this thread | | | Date | Fri, 14 Nov 2008 18:26:33 +0100 | From | Oleg Nesterov <> | Subject | Re: Signals to cinit |
| |
On 11/12, Sukadev Bhattiprolu wrote: > > Oleg Nesterov [oleg@redhat.com] wrote: > > | On 11/10, sukadev@linux.vnet.ibm.com wrote: > | > > | > Also, what happens if a fatal signal is first received from a descendant > | > and while that is still pending, the same signal is received from ancestor > | > ns ? Won't the second one be ignored by legacy_queue() for the non-rt case ? > > On second thoughts, cinit is a normal process in its ancestor ns so it > might very well ignore the second instance of the signal (as long as it > does not ignore SIGKILL/SIGSTOP) > > | > | Please see my another email: > | > | We must also change sig_ignored() to drop SIGKILL/SIGSTOP early when > | it comes from the same ns. Otherwise, it can mask the next SIGKILL > | from the parent ns. > > Ok. > > | > | But this perhaps makes sense anyway, even without containers. > | Currently, when the global init has the pending SIGKILL, we can't > | trust __wait_event_killable/etc, and this is actually wrong. > | > | We can drop other SIG_DFL signals from the same namespace early as well. > > I think Eric's patchset did this and iirc, we ran into the problem of > blocked SIG_DFL signals ?
Yes sure, I meant unblocked SIG_DFL signals. But SIGKILL can't be blocked fortunately.
Again, the parent ns can't rely on, say, SIGTERM. It can be missed if cinit has a handler, we can do nothing in this case. And if it is blocked, most probably cinit already has a handler, or it will set it later, say, after exec. Or it can be just ignored.
> | Or, we can just ignore this (imho) minor problem. > > I think so too.
Great, so perhaps we can ignore the problem for now, and fix it later if the need arises.
Oleg.
| |