linux-kernel - Re: [PATCH 5/5] PNP: HP nx6325 fixup: reserve unreported resources

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: <AANLkTikogB78xPGiQZpg6nWKYVffr61A_Adm0a+C3mbR@mail.gmail.com>
Date:	Tue, 14 Dec 2010 12:34:20 -0800
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Bjorn Helgaas <bjorn.helgaas@...com>
Cc:	Jesse Barnes <jbarnes@...tuousgeek.org>,
	Len Brown <lenb@...nel.org>, linux-pci@...r.kernel.org,
	linux-kernel@...r.kernel.org, "Rafael J. Wysocki" <rjw@...k.pl>,
	linux-acpi@...r.kernel.org, "H. Peter Anvin" <hpa@...or.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...e.hu>, Adam Belay <abelay@....edu>
Subject: Re: [PATCH 5/5] PNP: HP nx6325 fixup: reserve unreported resources

On Sat, Dec 11, 2010 at 10:17 PM, Bjorn Helgaas <bjorn.helgaas@...com> wrote:
>
> Not really -- the main point here is to make multi-host bridge
> machines work reliably, and I really don't see a way to do that
> without using _CRS.
>
> If we're going to use _CRS, I think in the long run we'll be better
> off if we do it similarly to Windows, despite these early problems.

It's not about any "despite these early problems".

It's about "clearly we're not doing things at all like Windows, and
it's just broken".

The thing is, we will never be able to match Windows exactly. It may
well have random hardcoded quirks we simply don't know about.

I'm perfectly happy with you aiming to use _CRS. I am _not_ happy with
you then using that as an excuse to then do things that don't work.

We will NOT start doing random BIOS-specific quirks just because
top-down allocations hit other bugs than bottom-up ones do. Just no.
We'll continue doing that we have tried to do, which is to perhaps
have quirks that are specific to *hardware* (like the ones in
drivers/pci/quirks.c) and just filling in stuff that some BIOSes are
known to get wrong.

That's a maintainable approach. But it's maintainable ONLY if we then
don't do other random changes that invalidates all the years of
testing we've had.

                            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/