linux-kernel - Re: [PATCH 0/2] Send a SIGCHLD to the init's pid namespace parent when reboot

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]

Date:	Mon, 22 Aug 2011 17:44:48 +0200
From:	Oleg Nesterov <oleg@...hat.com>
To:	Daniel Lezcano <daniel.lezcano@...e.fr>
Cc:	"Serge E. Hallyn" <serge@...lyn.com>, akpm@...ux-foundation.org,
	bonbons@...ux-vserver.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, Daniel Lezcano wrote:
>
> If we pass the reason to the exit_code of the init process, that will be
> a bit weird as the process is signaled and did not exited  no ?

Just in case, you shouldn't change ->exit_code blindly. We should only
change it if init was a) SIGKILL'ed and b) pid_ns->reboot_cmd is set.
In this case we can assume that it was killed by sys_reboot.

Now. I didn't really mean exit_state should be equal to sys_reboot's
cmd arg. I thought about something like

	swicth (reboot_cmd) {
	case LINUX_REBOOT_CMD_RESTART:
		code = SIGHUP;
		break;
	case LINUX_REBOOT_CMD_HALT:
		code = SIGINT;	// doesn't really matter what we report
		...
	}

we know that init can't be killed by SIGHUP/SIGINT, and this can't be
confused with the case when init does exit(exit_code).

But in fact I do not not think that WIFSIGNALED() is that important.
init shouldn't exit anyway.

> Furthermore, how to differentiate an application container (eg. a
> script) exiting with an error with the same value of a reboot reason ?

Well, I think it is better to fix the script than the kernel.

Daniel, I am not arguing. I agree that this looks like the hack anyway.
Just I think that other approaches are even worse imho. We should try
to make the kernel change as simple as possible.

> Wouldn't make sense to let the user to specify a signal via prctl where
> the si_code is filled with the reason ?

Sorry, I don't quite understand the idea...

And, iiuc, the point was to "fix" sys_reboot() so that we do not need
to mofify the distro/userspace?

In short. Please do what you like more. But I'd like you to know,
I'll argue with any complications which (afaics!) we can avoid,
I promise ;)

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/