Messages in this thread | | | Date | Wed, 12 Nov 2008 11:04:21 -0800 | From | Sukadev Bhattiprolu <> | Subject | Re: Signals to cinit |
| |
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 ?
| I seem to already did something like sig_init_ignored(), but I forgot.
Yes, I think we had that in the patchset but that was not merged.
| | Or, we can just ignore this (imho) minor problem.
I think so too.
| The ancestor ns | must know it can't reliably kill cinit with (say) SIGTERM. It can | be ignored, or it can have have a handler, and it can be lost because | SIGTERM is already pending. Only SIGKILL is special. | | Actually. I personally think that if we manage to achieve that | | - the sub-namespace can't kill its init | | - the ancestor can always kill cinit with SIGKILL
Yep.
| | then imho we should not worry very much about other issues ;) | | Oleg.
| |