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.0809301052200.3436@nehalem.linux-foundation.org>
Date:	Tue, 30 Sep 2008 11:01:38 -0700 (PDT)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Rene Herman <rene.herman@...access.nl>
cc:	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@...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>
Subject: Re: [patch 2/2] PNP: don't check disabled PCI BARs for conflicts in
 quirk_system_pci_resources()



On Tue, 30 Sep 2008, Linus Torvalds wrote:
> 
> In contrast, the PnP fixup thing is called from pnp_fixup_device, called 
> from __pnp_add_device(), called from pnp_add_device() (and 
> pnp_add_card(), but that should be later), and those in turn from
> pnpacpi_add_device and pnpacpi_init(). 
> 
> And pnpacpi_init is _also_ a subsys_initcall [...]

Btw, why is that? We very much have a separate

	/**
	 * Reserve motherboard resources after PCI claim BARs,
	 * but before PCI assign resources for uninitialized PCI devices
	 */
	fs_initcall(pnp_system_init);

which is called much later. That seems to be the _right_ point for any 
quirks. It seems that the _real_ problem here is that the PnP device fixup 
is simply called from the wrong point. Ie, why do we do device discovery - 
and thus PnP quirks - in pnp_init (before the PCI bus is actually fully 
initialized!), rather than in pnp_system_init?

Ie, maybe the proper thing to do is to simply be *consistent* in the PnP 
subsystem, and always use fs_initcall (for the stated reasons!) for the 
device discovery. Ie the patch would be something like the appended, and 
then you really can depend on the PCI subsystem having been set up, 
including having all relevant resources inserted into the tree!

Hmm?  Bjorn? Everything that is true about "pnp_system_init" should be 
equally true abote pnpacpi_init and pnpbios_init, no?

			Linus

---
 drivers/pnp/pnpacpi/core.c |    2 +-
 drivers/pnp/pnpbios/core.c |    2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/pnp/pnpacpi/core.c b/drivers/pnp/pnpacpi/core.c
index c1b9ea3..53561d7 100644
--- a/drivers/pnp/pnpacpi/core.c
+++ b/drivers/pnp/pnpacpi/core.c
@@ -268,7 +268,7 @@ static int __init pnpacpi_init(void)
 	return 0;
 }
 
-subsys_initcall(pnpacpi_init);
+fs_initcall(pnpacpi_init);
 
 static int __init pnpacpi_setup(char *str)
 {
diff --git a/drivers/pnp/pnpbios/core.c b/drivers/pnp/pnpbios/core.c
index 19a4be1..662dfcd 100644
--- a/drivers/pnp/pnpbios/core.c
+++ b/drivers/pnp/pnpbios/core.c
@@ -571,7 +571,7 @@ static int __init pnpbios_init(void)
 	return 0;
 }
 
-subsys_initcall(pnpbios_init);
+fs_initcall(pnpbios_init);
 
 static int __init pnpbios_thread_init(void)
 {
--
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/