On 08/22, Bruno Prémont wrote: > > On Mon, 22 August 2011 Oleg Nesterov wrote: > > On 08/22, Bruno Prémont wrote: > > > > > > Isn't it possible to add the two cases to si_code possible values, e.g. > > > CDL_RESTART, CDL_HALT (or CDL_SYS_RESTART, CDL_SYS_HALT > > > > How? You should change do_wait() paths then. Even if we could, personally > > I'd strongly object ;) Look, you have the very specific problem. The kernel > > can't do everything to make everyone happy. There is tradeoff. > > > > But if you really meant siginfo->si_code, I do not understand at all what > > you actually mean. This info is not preserved when the task exits. > > I've been reading do_wait() code a bit, it decides between CLD_KILLED and > CLD_DUMPED based on a bit of (struct task_struct).exit_code. Yes. But we were talking about the CLD_EXITED/CLD_KILLED difference. And in fact this CLD_ doesn't matter at all. sys_waitid(info) can see it, but you can simply look at "status". There is no additional info. > So struct_task IS still available Sure. But I do not understand why do you mention this... And, I think, in this discussion we can pretend that only task->exit_code is still available. > (how about it's namespace references? If > the namespaces are not the reboot reason would need to be stored somewhere > inside of struct task which might be some overhead too much) > > So as long as container init's task_struct exists the reboot reason could > be preserved and used to replace CLD_DUMPED/CLD_KILLED siginfo->si_code. At least now I understand why did you mention si_code/CLD before. You meant waitid(). I thought you were talking about the death-notifications which can't report CLD_ you need. I strongly object. We shouldn't uglify wait_task_zombie() to solve the very specific problem. And once again. sub_init->parent does wiat(&status) and sees WIFSIGNALED() && WTERMSIG(status) == SIGHUP. This can only mean that sys_reboot(LINUX_REBOOT_CMD_RESTART) was called. It _can not_ be really killed by SIGHUP, it must be CMD_RESTART. Why this can't work? Why do you want the additional complications? > > > > And, iiuc, the point was to "fix" sys_reboot() so that we do not need > > > > to mofify the distro/userspace? > > > > > > That's definitely the goal (not modify distro/userspace running inside > > > container). > > > > In this case I do not understand how prctl() can help. > > I'm not talking about prctl() - as I understand Daniel the prctl() part is > for the process outside of the container, not the one inside. > So for container hypervisor to say if it wants to get informed or not. OK, I certainly misunderstood him. And still can't understand what exactly was suggested ;) > > But please do not try to convince me, this is simply unnecessary ;) > > No, trying to know what's reasonably possible Can't resist... IMHO, imho, imho, but in this case I believe "reasonably possible" == "simplest" ;) Oleg. _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/containers
