| 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
| ||
|
Date: Sun, 28 Feb 2010 14:41:37 -0800 From: Yinghai Lu <yinghai@...nel.org> To: Linus Torvalds <torvalds@...ux-foundation.org> CC: Jesse Barnes <jbarnes@...tuousgeek.org>, "linux-pci@...r.kernel.org" <linux-pci@...r.kernel.org>, Linux Kernel Mailing List <linux-kernel@...r.kernel.org> Subject: Re: [git pull] PCI changes for 2.6.34 On 02/28/2010 01:19 PM, Linus Torvalds wrote: > > > On Sun, 28 Feb 2010, Yinghai wrote: >> >> Maybe we need to put back pci=try=num back >> And set pci_try_num=1 by default > > Well, why does your patch trigger any changes at all in the first place? > The old situation was fine. All the resources were mapped. > > Sure, there were ROM resources that aren't even enabled, but that is > _normal_. Iirc, several graphics chips actually alias the ROM resources > with the regular memory-mapped IO resource, ie you can't even map both of > them at the same time at some separate address, because the hardware > shares address decoding resources. > > There's a reson PCI ROM resources are treated specially by the kernel. > > And as far as I can see, all the other resources are already allocated > even without your patch. So there is some fundamental _bug_ there. This is > not about enabling/disabling your patch, this is about your patch > apparently simply being wrong. > looks like [ 0.942502] pci 0000:04:00.0: reg 10: [mem 0xc6000000-0xc6ffffff] [ 0.942510] pci 0000:04:00.0: reg 14: [mem 0xe0000000-0xefffffff 64bit pref] [ 0.942519] pci 0000:04:00.0: reg 1c: [mem 0xc4000000-0xc5ffffff 64bit] [ 0.942523] pci 0000:04:00.0: reg 24: [io 0x3000-0x307f] [ 0.942528] pci 0000:04:00.0: reg 30: [mem 0xfffe0000-0xffffffff pref] [ 0.942558] pci 0000:03:00.0: PCI bridge to [bus 04-04] [ 0.942613] pci 0000:03:00.0: bridge window [io 0x3000-0x3fff] [ 0.942616] pci 0000:03:00.0: bridge window [mem 0xc4000000-0xc6ffffff] [ 0.942619] pci 0000:03:00.0: bridge window [mem 0xe0000000-0xefffffff 64bit pref] [ 0.942657] pci 0000:05:00.0: reg 10: [mem 0xc2000000-0xc2ffffff] [ 0.942665] pci 0000:05:00.0: reg 14: [mem 0xd0000000-0xdfffffff 64bit pref] [ 0.942675] pci 0000:05:00.0: reg 1c: [mem 0xc0000000-0xc1ffffff 64bit] [ 0.942679] pci 0000:05:00.0: reg 24: [io 0x2000-0x207f] [ 0.942684] pci 0000:05:00.0: reg 30: [mem 0xfffe0000-0xffffffff pref] [ 0.942715] pci 0000:03:02.0: PCI bridge to [bus 05-05] [ 0.942770] pci 0000:03:02.0: bridge window [io 0x2000-0x2fff] [ 0.942773] pci 0000:03:02.0: bridge window [mem 0xc0000000-0xc2ffffff] [ 0.942777] pci 0000:03:02.0: bridge window [mem 0xd0000000-0xdfffffff 64bit pref] later [ 0.977506] pci 0000:04:00.0: no compatible bridge window for [mem 0xfffe0000-0xffffffff pref] [ 0.977575] pci 0000:05:00.0: no compatible bridge window for [mem 0xfffe0000-0xffffffff pref] that trigger the reallocating... it seems old code 1. read out from pci rom bar 2. disable it, if it is enabled, but don't registered it 3. before pci_assign_unassigned..., will check PCI_ASSIGN_ROMS, and could register it... 3. to allocate for ROM bar together with other bar, for disabled or enabled but don't have PCI_ASSIGN_ROMS 4. it will not update the BAR if old setting is not enabled by BIOS. looks like we should not allocate for those ROM bar at first place? YH -- 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/
Powered by blists - more mailing lists