linux-kernel - Re: Regression with commit f9cde5f in 2.6.30-gitX

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] [day] [month] [year] [list]

Date:	Wed, 24 Jun 2009 16:44:40 -0700 (PDT)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Larry Finger <Larry.Finger@...inger.net>
cc:	Yinghai Lu <yhlu.kernel@...il.com>,
	Gary Hade <garyhade@...ibm.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Jesse Barnes <jbarnes@...tuousgeek.org>,
	Jaswinder Singh Rajput <jaswinder@...nel.org>,
	LKML <linux-kernel@...r.kernel.org>, Ingo Molnar <mingo@...e.hu>,
	x86 maintainers <x86@...nel.org>, Len Brown <lenb@...nel.org>
Subject: Re: Regression with commit f9cde5f in 2.6.30-gitX



On Wed, 24 Jun 2009, Larry Finger wrote:
> 
> From what I read in Linus's mails, it may be a moot point; however, my
> system boots with these 3, and only these 3, patches applied.

Well, it's definitely not moot. We want "use_crs" to work, whether it's 
the default or not. I just doubt it should be the default (necessarily 
ever).

The resources listed in the _CRS table may well be useful to make 
decisions on (minimally: "is this a root bridge", but possibly also 
scanning decisions). But I seriously doubt it makes any sense to insert 
the _CRS resources into the bus resource list. 

It might, for example, make sense to add them to the resource tree (after 
scanning), the same way we add the e820 resources to the resource tree. 

But judging from your dmesg:

	pci_bus 0000:00: resource 0 io:  [0x00-0xcf7]
	pci_bus 0000:00: resource 1 io:  [0xd00-0xffff]
	pci_bus 0000:00: resource 2 mem: [0x0a0000-0x0bffff]
	pci_bus 0000:00: resource 3 mem: [0x0c0000-0x0c3fff]
	pci_bus 0000:00: resource 4 mem: [0x0c4000-0x0c7fff]
	pci_bus 0000:00: resource 5 mem: [0x0c8000-0x0cbfff]
	pci_bus 0000:00: resource 6 mem: [0x0cc000-0x0cffff]
	pci_bus 0000:00: resource 7 mem: [0x0d4000-0x0d7fff]
	pci_bus 0000:00: resource 8 mem: [0x0d8000-0x0dbfff]
	pci_bus 0000:00: resource 9 mem: [0x0dc000-0x0dffff]
	pci_bus 0000:00: resource 10 mem: [0x0e0000-0x0e3fff]
	pci_bus 0000:00: resource 11 mem: [0x0e4000-0x0e7fff]
	pci_bus 0000:00: resource 12 mem: [0x0e8000-0x0ebfff]
	pci_bus 0000:00: resource 13 mem: [0x0ec000-0x0effff]
	pci_bus 0000:00: resource 14 mem: [0x0f0000-0x0fffff]
	pci_bus 0000:00: resource 15 mem: [0xc0000000-0xfebfffff]
	pci_bus 0000:01: resource 1 mem: [0xfc100000-0xfc1fffff]
	pci_bus 0000:01: resource 3 io:  [0x00-0xcf7]
	pci_bus 0000:01: resource 4 io:  [0xd00-0xffff]
	pci_bus 0000:01: resource 5 mem: [0x0a0000-0x0bffff]
	pci_bus 0000:01: resource 6 mem: [0x0c0000-0x0c3fff]
	pci_bus 0000:01: resource 7 mem: [0x0c4000-0x0c7fff]
	pci_bus 0000:01: resource 8 mem: [0x0c8000-0x0cbfff]
	pci_bus 0000:01: resource 9 mem: [0x0cc000-0x0cffff]
	pci_bus 0000:01: resource 10 mem: [0x0d4000-0x0d7fff]
	pci_bus 0000:01: resource 11 mem: [0x0d8000-0x0dbfff]
	pci_bus 0000:01: resource 12 mem: [0x0dc000-0x0dffff]
	pci_bus 0000:01: resource 13 mem: [0x0e0000-0x0e3fff]
	pci_bus 0000:01: resource 14 mem: [0x0e4000-0x0e7fff]
	pci_bus 0000:01: resource 15 mem: [0x0e8000-0x0ebfff]
	pci_bus 0000:01: resource 16 mem: [0x0ec000-0x0effff]
	pci_bus 0000:01: resource 17 mem: [0x0f0000-0x0fffff]
	pci_bus 0000:01: resource 18 mem: [0xc0000000-0xfebfffff]

none of those look in any way like sensible "resources" to be put in the 
device. Quite frankly, they look like total garbage to me.

			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/