linux-kernel - Re: [patch 2/2] PNP: don't check disabled PCI BARs for conflicts in quirk_system_pci

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: <alpine.LFD.2.00.0809301244290.3262@nehalem.linux-foundation.org>
Date:	Tue, 30 Sep 2008 12:51:07 -0700 (PDT)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Ingo Molnar <mingo@...e.hu>
cc:	Arjan van de Ven <arjan@...radead.org>,
	Rene Herman <rene.herman@...access.nl>,
	Bjorn Helgaas <bjorn.helgaas@...com>,
	Jesse Barnes <jbarnes@...tuousgeek.org>,
	Len Brown <lenb@...nel.org>, Frans Pop <elendil@...net.nl>,
	"Rafael J. Wysocki" <rjw@...k.pl>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	linux-pci@...r.kernel.org, linux-acpi@...r.kernel.org,
	Adam Belay <abelay@....edu>, Avuton Olrich <avuton@...il.com>,
	Karl Bellve <karl.bellve@...ssmed.edu>,
	Willem Riede <wriede@...de.org>,
	Matthew Hall <mhall@...omputing.net>,
	Sam Ravnborg <sam@...nborg.org>
Subject: Re: [patch 2/2] PNP: don't check disabled PCI BARs for conflicts in
 quirk_system_pci_resources()

On Tue, 30 Sep 2008, Ingo Molnar wrote:
> 
> incidentally, i've been talking to Arjan about this recently in context 
> of the CONFIG_FASTBOOT feature. Because, as a side-effect, in the long 
> run, once the dependencies between initcalls fan out in a more natural 
> way, with explicit initcall ordering we'll also be able to boot a bit 
> faster and a bit more parallel.

Hell no.

We do not want any implicit parallelism in the initcalls. That way lies 
madness.

The probe functions that explicitly know that they are slow (like USB 
detection and/or other individual drivers that have timeouts) should put 
themselves in the background. We should _not_ use the dependency chain to 
do so automatically, because for most cases drivers are totally 
independent, but we still want a _reliable_  and _repeatable_ ordering.

Which means that I will not accept stuff that makes for a parallel bootup 
as a general initcall notion. I want things like network devices to show 
up in the same order for the same kernel, thank you very much - even if 
there is absolutely _zero_ ordering constraints between two independent 
network drivers.

Anything else will inevitably cause just totally random and undebuggable 
problems.

> i think the topological ordering should not be just an extension of the 
> current hardcoded initcall levels, but it should be symbol space based: 
> i.e. an initcall should depend not on some kind of artificial enum, but 
> it should depend on _another initcall_. (a list of initcalls more 
> generally)

Yes, it should be explicit.

However, I don't agree with the notion of having initcalls point to other 
initcalls. One big _idea_ of initcalls is that you can put them anywhere 
in the source code, and that CONFIG_XYZ variables will automatically run 
them or not depending on whether the code was compiled in. Having 
something like:

> so instead of the current hardcoded levels:
> 
>   core_initcall(sysctl_init);
> 
> we could have natural constructs like:
> 
>   initcall_depends_on(sysctl_init, securityfs_init);
>   initcall_depends_on(sock_init, sysctl_init)

would be a TOTAL DISASTER, because if you do that, then you are 
essentially back to the insane situation where people need to know what 
other parts are enabled.

So no. No "one call depends on another" crap.

But I think we could add a separate notion of a dependancy point, and have 
a setup where we describe "initcall X needs to happen before point A" and 
"initcall Z needs to happen after point A".

And then we can create a separate set of these dependency points, so that 
X and Y don't have to know about each other, they just have to have some 
knowledge about some common synchronization point - one that exists 
regardless of whether X or Y are even compiled in!

			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/