linux-kernel - Re: [PATCH] kthread: Don't depend on work queues

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:	Wed, 11 Apr 2007 00:03:16 -0700
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	ebiederm@...ssion.com (Eric W. Biederman)
Cc:	Oleg Nesterov <oleg@...sign.ru>,
	Davide Libenzi <davidel@...ilserver.org>,
	Jan Engelhardt <jengelh@...ux01.gwdg.de>,
	Ingo Molnar <mingo@...e.hu>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Robin Holt <holt@....com>, Roland McGrath <roland@...hat.com>,
	"Serge E. Hallyn" <serge@...lyn.com>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] kthread: Don't depend on work queues

On Tue, 10 Apr 2007 23:44:36 -0600 ebiederm@...ssion.com (Eric W. Biederman) wrote:

> Currently there is a circular reference between work queue initialization
> and kthread initialization.   This prevents the kernel thread
> infrastructure from initializing until after work queues have been
> initialized.
> 
> For kernel threads we want something that is as close as possible to the
> init_task and is not contaminated by user processes.  The later we start
> our kthreadd that forks the rest of the kernel threads the harder this is
> to do and the more of a mess we have to clean up because the defaults have
> changed on us.
> 
> So this patch modifies the kthread support to not use work queues but to
> instead use a simple list of structures, and to have kthreadd start from
> init_task immediately after our kernel thread that execs /sbin/init.
> 
> By being a true child of init_task we only have to change those process
> settings that we want to have different from init_task, such as our
> process name, blocking all signals and setting SIGCHLD to SIG_IGN
> so that all of our children are reaped automatically.
> 
> By being a tre child of init_task we also naturally get our ppid set to 0
> and do not wind up as a child of PID == 1.  Ensuring that kernel threads
> will not slow down the functioning of the wait family of functions.

argh.  Your description freely confuddles the terms "kernel thread" and
"kthread".  Can we not do that?  Henceforth the term "kernel thread" refers
to something which was started with kernel_thread() and "kthread" refers to
something which was created by kthread_create(), OK?

Your patch gets midly tangled up with Oleg's recent

reduce-reparent_to_init.patch
make-kernel-threads-invisible-to-sbin-init.patch
reparent-kernel-threads-to-swapper.patch

but they seemed fairly unpopular anyway so I'll drop 'em.

Your wait_event() will contribute to load average, I expect.  We get mail. 
I converted it to wait_event_interruptible().

I guess using PF_NOFREEZE rather than try_to_freeze() is OK, but one
wonders what thinking led to that?

Often when we have a singleton thread like this it is neater to use
wake_up_process() directly on it, rather than creating a rather pointless
waitqueue_head for it.  I started looking into that but it would have taken
more than 30 seconds.

-
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/