On 11/01, sukadev@xxxxxxxxxxxxxxxxxx wrote: > > Other approaches to try ? I think we should try to do something simple, even if not perfect. Because most users do not care about this problem since they do not use containers at all. It would be very sad to add intrusive changes to the code. I think we should fix another problem first. send_signal()->copy_siginfo() path must be changed anyway, when the signal comes from the parent ns we report the "wrong" si_code/si_pid, yes? So, somehow send_signal() must have "bool from_parent_ns" (or whatever) annyway. Now, let's forget forget for a moment that send_signal()->__sigqueue_alloc() can fail. I think we should encode this "from_parent_ns" into "struct siginfo". I do not think it is good idea to extend this structure, I think we can introduce SI_FROM_PARENT_NS or we perhaps can use "SI_FROMUSER(info) && info->si_pid == 0". Or something. yes, sys_rt_sigqueueinfo() is problematic... Now, copy_process(CLONE_NEWPID) sets child->signal |= SIGNAL_UNKILLABLE, this protects cinit from unwanted signals. Then we change get_signal_to_deliver() - if (unlikely(signal->flags & SIGNAL_UNKILLABLE) && + if (unlikely(signal->flags & SIGNAL_UNKILLABLE) && !siginfo_from_parent_ns(info) and now we can kill cinit from parent ns. This needs more checks if we want to stop/strace it, but perhaps this is enough for the start. Note that we do not need to change complete_signal(), at least for now, the code under "if (sig_fatal(p, sig)" is just optimization. So, afaics, the only real problem is how we can handle the case when __sigqueue_alloc() fails. I think for the start we can just return -ENOMEM in this case (when from_parent_ns == T). Then we can improve this behaviour. We can change complete_signal() to ensure that the fatal signal from the upper ns always kills cinit, and in this case we ignore the the failed __sigqueue_alloc(). This way at least SIGKILL always works. Yes, this is not perfect, and it is very possible I missed something else. But simple. Oleg. _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/containers