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.0809301001280.3389@nehalem.linux-foundation.org>
Date:	Tue, 30 Sep 2008 10:10:15 -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 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, Linus Torvalds wrote:
> 
> It's a scary change right now, and I wouldn't commit it as is (I think 
> that for 2.6.27 the thing to do is to just do the minimal "zero means 
> disabled" thing), but having some random driver level initialize before 
> the core architecture-specific PCI code does smell. So something like this 
> sounds conceptually right anyway.

A clearer (and more flexible) solution might be this patch. It's more 
explicit about the fact that it simply makes it clear that any drivers 
that are added by the architecture Makefile will be _first_ in the list of 
drivers.

I suspect we should do the same with 'libs' and 'core' too, for that 
matter, but we don't really use '*.a' libraries any more so link order 
doesn't matter apart from initcall ordering. And libraries should hopfully 
never have that issue. And 'core' is at least right now just the 
initramfs thing. So in practice, it's probably only drivers/ that coul 
have issues like this.

Sam added to Cc, since this is a build issue. What do people think? 

Background: We are very careful to add 'drivers/pci' _before_ 
'drivers/{acpi,pnp}' in the drivers/Makefile, but what happens now is that 
since the arch Makefile adds it's own drivers to the very end, the really 
core PCI initcalls actually get ordered at the end, not the beginning. 

		Linus

---
 Makefile |    4 +++-
 1 files changed, 3 insertions(+), 1 deletions(-)

diff --git a/Makefile b/Makefile
index 1d03c16..642b9b9 100644
--- a/Makefile
+++ b/Makefile
@@ -458,7 +458,6 @@ scripts: scripts_basic include/config/auto.conf

 # Objects we will link into vmlinux / subdirs we need to visit
 init-y		:= init/
-drivers-y	:= drivers/ sound/ firmware/
 net-y		:= net/
 libs-y		:= lib/
 core-y		:= usr/
@@ -517,6 +516,9 @@ endif

 include $(srctree)/arch/$(SRCARCH)/Makefile

+# Do this _after_ the architecture may have added its own core drivers
+drivers-y	+= drivers/ sound/ firmware/
+
 ifneq (CONFIG_FRAME_WARN,0)
 KBUILD_CFLAGS += $(call cc-option,-Wframe-larger-than=${CONFIG_FRAME_WARN})
 endif
--
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/