linux-kernel - RE: Regression: 2.6.34 boot fails on E5405 system, bisected: de08e2c26

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: <43F901BD926A4E43B106BF17856F0755EA8EEA9B@orsmsx508.amr.corp.intel.com>
Date:	Wed, 14 Jul 2010 12:01:04 -0700
From:	"Pan, Jacob jun" <jacob.jun.pan@...el.com>
To:	Jesse Barnes <jbarnes@...tuousgeek.org>,
	"H. Peter Anvin" <hpa@...or.com>
CC:	Ben Greear <greearb@...delatech.com>,
	linux-kernel <linux-kernel@...r.kernel.org>
Subject: RE: Regression:  2.6.34 boot fails on E5405 system, bisected:
  de08e2c26



>-----Original Message-----
>From: Jesse Barnes [mailto:jbarnes@...tuousgeek.org]
>Sent: Wednesday, July 14, 2010 11:59 AM
>To: H. Peter Anvin
>Cc: Ben Greear; linux-kernel; Pan, Jacob jun
>Subject: Re: Regression: 2.6.34 boot fails on E5405 system, bisected:
>de08e2c26
>
>On Wed, 14 Jul 2010 11:52:44 -0700
>"H. Peter Anvin" <hpa@...or.com> wrote:
>
>> So I suggest the following changes...
>>
>> On 07/13/2010 07:19 PM, Jesse Barnes wrote:
>> >>
>> >> static int fixed_bar_cap(struct pci_bus *bus, unsigned int devfn)
>> >> {
>> >> 	int pos;
>> >> 	u32 pcie_cap = 0, cap_data;
>> >> 	printk("fixed_bar_cap, bus: %p  devfn: %u\n", bus, devfn);
>> >> 	pos = PCIE_CAP_OFFSET;
>> >> 	while (pos) {
>>
>> while (pos >= PCIE_CAP_OFFSET) {
>>
>> >> 		printk("Before read..\n");
>> >> 		if (raw_pci_ext_ops->read(pci_domain_nr(bus), bus->number,
>> >> 					  devfn, pos, 4, &pcie_cap))
>> >> 			return 0;
>> >> 		printk("pcie_cap: %u", pcie_cap);
>> >>
>>    -		if (pcie_cap == 0xffffffff)
>>    -			return 0;
>>
>>    +		if (PCI_EXT_CAP_ID(pcie_cap) == 0x0000 ||
>>    +		    PCI_EXT_CAP_ID(pcie_cap) == 0xffff)
>>    +			break;
>>
>> >> 		printk("Checking vendor..\n");
>>
>> >> 		if (PCI_EXT_CAP_ID(pcie_cap) == PCI_EXT_CAP_ID_VNDR) {
>> >> 			printk("reading domain_nr\n");
>> >> 			raw_pci_ext_ops->read(pci_domain_nr(bus), bus->number,
>> >> 					      devfn, pos + 4, 4, &cap_data);
>> >> 			printk("cap_data: %u\n", cap_data);
>> >> 			if ((cap_data & 0xffff) == PCIE_VNDR_CAP_ID_FIXED_BAR)
>> >> 				return pos;
>> >> 		}
>> >>
>> >> 		pos = pcie_cap >> 20;
>>
>> 		pos = (pcie_cap >> 20) & 0xffc;
>>
>> >> 		printk("pos after shift: %i\n", pos);
>> >> 	}
>> >>
>> >> 	printk("Returning from fixed_bar_cap\n");
>> >> 	return 0;
>> >> }
>> >>
>> >>
>> >
>> > I thought a related bug was fixed already; the code should be
>returning
>> > all zeros for non-existent BAR reads.
>
>Changes look ok to me, though I'd prefer not hitting this code at all
>on non-Moorestown if at all possible.

Can we use PCI_EXT_CAP_NEXT to replace this line?
pos = (pcie_cap >> 20) & 0xffc
--
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/