Quoting Oren Laadan (orenl@xxxxxxxxxxxxxxx): > > > Serge E. Hallyn wrote: > > Hi Oren, > > > > commit 9a45e26c0aabda6a94e2ac620befd8ee12a7363d adds > > reset of pdeath_signal. It does so unconditionally. I > > don't think that's safe. Perhaps if pdeath_signal is > > anything other than 0, it should only be restored if > > the task is capable(CAP_KILL)? > > Hmmm... maybe I'm missing something here, but -- Nope, you're not. I was thinking wrong. > pdeath_signal indicates that the process wishes to receive > a signal, not to send one. It may change through prctl() > without requiring any capabilities from the caller. Finally > it is reset at fork/clone. > > So at worse it will kill the specific task that holds it ? > > -- > > As a side note - for a brief moment I worried that it may > break restart with zombies, if the to-be-zombie process has > a child that already restarted (including pdeath_signal) and > then exits, then the child will receive a signal unwillingly. > > I then realized that it's safe as long as we restore parents > before their children. In turn this depends on the checkpoint > order, which indeed operates this way. > > Otherwise we would have needed set this to all processes > after all zombies indeed have terminated - which means another > sync point at restart, or a sweep by coordinator on all tasks. > > Oren. _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/containers
