Oleg Nesterov [EMAIL PROTECTED] wrote: | On 11/10, [EMAIL PROTECTED] 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. _______________________________________________ Containers mailing list [EMAIL PROTECTED] https://lists.linux-foundation.org/mailman/listinfo/containers _______________________________________________ Devel mailing list [email protected] https://openvz.org/mailman/listinfo/devel
