Oleg Nesterov [oleg@xxxxxxxxxx] wrote: | (lkml cced because containers list's archive is not useable) | | On 11/10, Oleg Nesterov wrote: | > | > 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. Yes, this was in both the patchsets we reviewed last year :-) I can send this fix out independently. | > | > 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... 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 ? Of course, this is a new scenario, specific to containers, and we may be able to define the policy without changing semantics. _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/containers