Message-ID: <20110823133302.GA19582@redhat.com>
Date:	Tue, 23 Aug 2011 15:33:02 +0200
From:	Oleg Nesterov <oleg@...hat.com>
To:	Bruno Prémont <bonbons@...ux-vserver.org>
Cc:	Daniel Lezcano <daniel.lezcano@...e.fr>,
	"Serge E. Hallyn" <serge@...lyn.com>, akpm@...ux-foundation.org,
	containers@...ts.linux-foundation.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/2] Send a SIGCHLD to the init's pid namespace parent
	when reboot

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.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists