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-next>] [day] [month] [year] [list]
Message-ID: <20070308163844.GA6638@tv-sign.ru>
Date:	Thu, 8 Mar 2007 19:38:44 +0300
From:	Oleg Nesterov <oleg@...sign.ru>
To:	Andrew Morton <akpm@...ux-foundation.org>
Cc:	"linux-os (Dick Johnson)" <linux-os@...logic.com>,
	Roland McGrath <roland@...hat.com>,
	linux-kernel@...r.kernel.org
Subject: Re: Kernel threads

Andrew Morton wrote:
>
> > On Tue, 6 Mar 2007 11:03:48 -0500 "linux-os \(Dick Johnson\)" <linux-os@...logic.com> wrote:
> >
> > In linux-2.6.16.24, there is a problem with kernel threads
> > and the aic79xx.c driver.
> >
> > When nash is executing /initrd/linuxrc in the initial RAM disk
> > during boot, it will be installing drivers. One driver, aic79xx.c
> > creates some kernel threads that will exit after the initialization
> > procedure. Actually the number of tasks depends upon the number
> > of disks found as the driver spawns these tasks so initialization
> > can occur in the background. The kernel tasks have been 'parented'
> > to init. This may be fine for the real init, but nash and other
> > shells receive the SIGCHLD signal and think that the fork()/exec()
> > they have executed is complete. This makes nash insert drivers
> > when the needed previous ones have not yet initialized. Also, when
> > booting a shell, the signals from the exiting kernel tasks confuse
> > it.
>
> ug.  I've always disliked the kernel's dependence upon init to reap exitted
> kernel threads.  It Just Seems Wrong.

Yes. It is ugly to kick init to reap the kernel thread. I was going to
do this change a long ago, but I don't have time to do even a minimal
testing now.

reparent_to_init() expects that thread_group_empty() == true anyway,
we can set ->exit_signal = -1 and make this thread invisible to init.

Roland, what do you think?

Oleg.

--- WQ/kernel/exit.c~rti	2007-02-18 22:56:49.000000000 +0300
+++ WQ/kernel/exit.c	2007-03-08 19:26:39.000000000 +0300
@@ -276,8 +276,8 @@ static void reparent_to_init(void)
 	current->parent = child_reaper(current);
 	add_parent(current);
 
-	/* Set the exit signal to SIGCHLD so we signal init on exit */
-	current->exit_signal = SIGCHLD;
+	/* make the task autoreap */
+	current->exit_signal = -1;
 
 	if (!has_rt_policy(current) && (task_nice(current) < 0))
 		set_user_nice(current, 0);

-
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