linux-kernel - Re: [patch] drivers: wait for threaded probes between initcall levels

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:	Fri, 27 Oct 2006 13:15:29 -0700
From:	Andrew Morton <akpm@...l.org>
To:	Stephen Hemminger <shemminger@...l.org>
Cc:	Pavel Machek <pavel@....cz>, Greg KH <greg@...ah.com>,
	Matthew Wilcox <matthew@....cx>, Adrian Bunk <bunk@...sta.de>,
	Linus Torvalds <torvalds@...l.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	linux-pci@...ey.karlin.mff.cuni.cz
Subject: Re: [patch] drivers: wait for threaded probes between initcall
 levels

On Fri, 27 Oct 2006 11:47:29 -0700
Stephen Hemminger <shemminger@...l.org> wrote:

> On Fri, 27 Oct 2006 11:42:37 -0700
> Andrew Morton <akpm@...l.org> wrote:
> 
> > From: Andrew Morton <akpm@...l.org>
> > 
> > The multithreaded-probing code has a problem: after one initcall level (eg,
> > core_initcall) has been processed, we will then start processing the next
> > level (postcore_initcall) while the kernel threads which are handling
> > core_initcall are still executing.  This breaks the guarantees which the
> > layered initcalls previously gave us.
> > 
> > IOW, we want to be multithreaded _within_ an initcall level, but not between
> > different levels.
> > 
> > Fix that up by causing the probing code to wait for all outstanding probes at
> > one level to complete before we start processing the next level.
> > 
> > Cc: Greg KH <greg@...ah.com>
> > Signed-off-by: Andrew Morton <akpm@...l.org>
> > ---
> > 
> 
> This looks like a good place to use a counting semaphore.
> 

I couldn't work out a way of doing that.  I guess one could a) count the
number of threads which are going to be started, b) start them all, c) do
an up() when each thread ends and d) handle errors somehow.

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