lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20110824214418.474b24c6@neptune.home>
Date:	Wed, 24 Aug 2011 21:44:18 +0200
From:	Bruno Prémont <bonbons@...ux-vserver.org>
To:	Oleg Nesterov <oleg@...hat.com>
Cc:	Greg Kurz <gkurz@...ibm.com>,
	containers@...ts.linux-foundation.org, akpm@...ux-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 Tue, 23 August 2011 Oleg Nesterov <oleg@...hat.com> wrote:
> On 08/23, Greg Kurz wrote:
> >
> > On Tue, 2011-08-23 at 15:33 +0200, Oleg Nesterov wrote:
> > > [...]
> > > 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?
> > >
> >
> > I don't see either what could go wrong with you approach.
> 
> Thanks ;)
> 
> Just in case... instead of WIFSIGNALED/WTERMSIG we can also report
> the exit code in the upper bits. I mean,
> 
> 	switch (reboot_cmd) {
> 	case LINUX_REBOOT_CMD_RESTART:
> 		code = 1 << 16;
> 		break;
> 	case LINUX_REBOOT_CMD_HALT:
> 		code = 2 << 16;
> 		break;
> 	}

That looks nice and simple!

> this can't be confused with the normal exit(code), just the parent
> should be careful, I am not sure this can't confuse WIFEXITED/WEXITSTATUS
> user-space macroses.

For recent glibc (2.12.2):
sys/wait.h and stdlib.h:
# define WIFEXITED(status) __WIFEXITED (__WAIT_INT (status))
# define WEXITSTATUS(status)       __WEXITSTATUS (__WAIT_INT (status))
bits/waitstatus.h:
#define     __WIFEXITED(status)     (__WTERMSIG(status) == 0)
#define     __WTERMSIG(status)      ((status) & 0x7f)
#define     __WEXITSTATUS(status)   (((status) & 0xff00) >> 8)


For this version of glibc on x86 and amd64 it looks fine.
Would have to look at other versions and other libcs to make sure there
are no surprises.

Bruno

> wait(&status) takes "int *", we have a room for additional info, and
> wait_task_zombie() simply copies exit_code.
> 
> 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

Powered by Openwall GNU/*/Linux Powered by OpenVZ