On 11/12, Sukadev Bhattiprolu wrote: > > Oleg Nesterov [oleg@xxxxxxxxxx] wrote: > > | On 11/10, sukadev@xxxxxxxxxxxxxxxxxx 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. _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/containers
