On 09/13, Cedric Le Goater wrote: > > Oleg Nesterov wrote: > > On 09/10, sukadev@xxxxxxxxxx wrote: > >> (This is Oleg's patch with my pid ns additions. Compiled and unit tested > >> on 2.6.23-rc4-mm1 with other patches in this set. Oleg pls update this > >> patch if necessary and sign-off) > > > > Sukadev, my apologies. This patch does need some changes, > > > >> Notes: > >> > >> - Blocked signals are never ignored, so init still can receive > >> a pending blocked signal after sigprocmask(SIG_UNBLOCK). > >> Easy to fix, but probably we can ignore this issue. > > > > I was wrong. This should be fixed right now. I _think_ this is easy, > > and I was going to finish this patch yesterday, but - sorry! - I just > > can't switch to "kernel mode" these days, I am fighting with some urgent > > tasks on my paid job. > > > To respect the current init semantic, The current init semantic is broken in many ways ;) > shouldn't we discard any unblockable > signal (STOP and KILL) sent by a process to its pid namespace init process ? > Then, all other signals should be handled appropriately by the pid namespace > init. Yes, I think you are probably right, this should be enough in practice. After all, only root can send the signal to /sbin/init. On my machine, /proc/1/status shows that init doesn't have a handler for non-ignored SIGUNUSED == 31, though. But who knows? The kernel promises some guarantees, it is not good to break them. Perhaps some strange non-standard environment may suffer. > We are assuming that the pid namespace init is not doing anything silly and > I guess it's OK if the consequences are only on the its pid namespace and > not the whole system. The sub-namespace case is very easy afaics, we only need the "signal comes from the parent namespace" check, not a problem if we make the decision on the sender's path, like this patch does. Oleg. _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/containers