linux-kernel - Re: regression fixed by using pci=rom

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:	Fri, 9 May 2008 08:44:03 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Jesse Barnes <jbarnes@...tuousgeek.org>,
	Dave Airlie <airlied@...il.com>,
	kernel list <linux-kernel@...r.kernel.org>,
	Gary Hade <garyhade@...ibm.com>,
	Thomas Gleixner <tglx@...utronix.de>
Subject: Re: regression fixed by using pci=rom

* Linus Torvalds <torvalds@...ux-foundation.org> wrote:

> On Thu, 8 May 2008, Jesse Barnes wrote:
> > 
> > Hm, yeah in many cases we definitely *do* want to try to get the 
> > expansion ROM space allocated.  But maybe it should be a lower 
> > priority than other BARs...  Gary?
> 
> The thing is, a lot of these things have been done this way because 
> not doing them that way breaks.
> 
> We want to allocate expansion ROM space - even if we don't enable it - 
> because not doing so will screw up bus sizing etc, and can make it 
> impossible to allocate later.
> 
> In general, changing PCI allocation strategy is really _really_ 
> dangerous, even when it is "right", because it tends to expose a lot 
> of issues where something worked just because it was perhaps 
> indirectly causing a layout that worked.

i tend to believe that the best strategy would be to generally do what 
other OSs do for PCI BAR sizing and PCI resource setup [on desktop 
systems that would be Windows in particular] - and i believe there are 
still a number of gratuitous-looking differences in our code that seem 
unnecessary. Especially on the myriads of desktop systems Windows is 
what gets tested primarily, and by deviating from that legacy layout we 
just set up ourselves for unnecessary failures.

To Linux the primary interest is in devices not failing due to 
unexpected layout and them not overlapping any magic areas - good 
resource compression is something that larger systems can opt-in into 
anyway if it's really needed. In that sense this commit that came 
through us failed that strict benchmark :-/

> So the reason I immediately reverted this is that it was simply 
> totally wrong. If somebody cares about multi-node systems, the onus of 
> making those work should be on *that*, not on old systems that already 
> work.
> 
> Ingo, Thomas: I would _seriously_ suggest that you don't consider the 
> x86 PCI setup code to be "x86" code. Because it isn't. Not in that 
> sense. Just don't take patches to it.

yeah, we stopped doing that in this window (the commits you got form us 
in this window were all leftovers and acked by Jesse) - and we've 
already bounced over all PCI-looking patches to Jesse and asked Jesse 
about all PCI affecting pulls as well in this window. Even this window's 
leftovers we made separate topics and sent separate pull requests for 
them (all tested and acked by Jesse) because it's not really arch/x86 
and PCI commits just need to be considered separately from all other 
changes.

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