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]

Message-ID: <Pine.LNX.4.64.0610271840270.3849@g5.osdl.org>
Date:	Fri, 27 Oct 2006 18:50:41 -0700 (PDT)
From:	Linus Torvalds <torvalds@...l.org>
To:	Greg KH <greg@...ah.com>
cc:	Andrew Morton <akpm@...l.org>,
	Stephen Hemminger <shemminger@...l.org>,
	Pavel Machek <pavel@....cz>, Matthew Wilcox <matthew@....cx>,
	Adrian Bunk <bunk@...sta.de>,
	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, Greg KH wrote:
> 
> Heh, ok, I'll take this idea, and Andrew's patch, and rework things for
> the next round of 2.6.20-rc kernels, and mark the current stuff as
> BROKEN for now.

My interface stuff is kind of designed for:

 - keep the current "init" sequence as-is for now

 - keep the _actual_ PCI probing non-parallel, so that we actually do all 
   the bus _discovery_ in a repeatable and sane order.

 - use the new "execute_in_parallel()" interface for things that actually 
   _sleep_. For example, all the PCI IDE _driver_ attachement should be 
   done synchronously, but perhaps the code that tries to see if there are 
   actual disks (ie the stuff that has timeouts etc) can use the parallel 
   execution.

 - module loading would do a "allow_parallel(1)" and 
   "wait_for_parallel(1)" thing when calling the module init function (so 
   that a module could use "execute_in_parallel()" whether compiled in or 
   not, and each "init level" at boot would also do this (with some bigger 
   number, like 10), so that for drivers etc that want to do async stuff, 
   they can do so in parallel (but they'd still have done the actual hard 
   device find/init serially - keeping the link order relevant for things 
   like IDE controller discovery)

How does this sound?

There's really no reason to parallelise the actual PCI config cycles and 
probing and stuff. It's only when some driver knows that it might have to 
do some longer-running thing that it might want to execute a thread in 
parallel with other things - but it still needs to be done in a controlled 
situation, so that when "driver_init()" stops and "filesystem_init()" 
starts, we must wait for all the driver-init parallel tasks to finish 
(since "filesystem_init()" is allowed to depend on them).

Hmm?

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