linux-kernel - Re: [PATCH 1/8] x86/mrst/pci: return 0 for non-present pci bars

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]

Date:	Mon, 17 May 2010 10:04:04 -0700
From:	"H. Peter Anvin" <hpa@...or.com>
To:	Bjorn Helgaas <bjorn.helgaas@...com>
CC:	Jacob Pan <jacob.jun.pan@...ux.intel.com>,
	LKML <linux-kernel@...r.kernel.org>, Ingo Molnar <mingo@...e.hu>,
	Thomas Gleixner <tglx@...utronix.de>,
	Alan Cox <alan@...ux.intel.com>,
	Arjan van de Ven <arjan@...ux.intel.com>
Subject: Re: [PATCH 1/8] x86/mrst/pci: return 0 for non-present pci bars

On 05/17/2010 09:58 AM, Bjorn Helgaas wrote:
> On Friday, May 14, 2010 03:41:14 pm Jacob Pan wrote:
>> Moorestown PCI code has special handling of devices with fixed BARs. In
>> case of BAR sizing writes, we need to update the fake PCI MMCFG space with real
>> size decode value.
>>
>> When a BAR is not present, we need to return 0 instead of ~0. ~0 will be
>> treated as device error per bugzilla 12006.
> 
> It would be more convenient if you included the URL,
> https://bugzilla.kernel.org/show_bug.cgi?id=12006,
> rather than just the bugzilla number.
> 
> You probably noticed already, but we reverted the patch I
> proposed in 12006 because it was too aggressive, so you may
> not need this patch for that reason.
> 
> Per 6.2.5.1 in the PCI 3.0 spec, "unimplemented Base Address
> registers are hardwired to zero," so it would make sense to me
> to follow that, but your patch affects the *write* path, not
> the read path, so I don't know how it's related to what
> __pci_read_base() will see when it reads the BAR.
> 

Very simple... these device headers are really just data structures in
RAM, so what is written is what is read.

	-hpa

-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.

--
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/