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:	Thu, 24 Sep 2009 07:24:18 -0600
From:	Bjorn Helgaas <bjorn.helgaas@...com>
To:	Yinghai Lu <yhlu.kernel@...il.com>
Cc:	Larry Finger <Larry.Finger@...inger.net>,
	Gary Hade <garyhade@...ibm.com>,
	Jesse Barnes <jbarnes@...tuousgeek.org>,
	Jaswinder Singh Rajput <jaswinder@...nel.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...e.hu>, Len Brown <lenb@...nel.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>, x86@...nel.org,
	linux-kernel@...r.kernel.org
Subject: Re: fixing "pci=use_crs"

On Wed, 2009-09-23 at 21:42 -0700, Yinghai Lu wrote:
> On Wed, Sep 23, 2009 at 8:21 PM, Bjorn Helgaas <bjorn.helgaas@...com> wrote:
> > On Wed, 2009-09-23 at 16:28 -0700, Yinghai Lu wrote:
> >> On Wed, Sep 23, 2009 at 4:23 PM, Bjorn Helgaas <bjorn.helgaas@...com> wrote:
> >
> >> > P.S.  Yinghai, you posted some patches earlier dealing with "only one
> >> > HT chain."  You apparently have some insight into what's going on here,
> >> > but unfortunately, the changelogs mean absolutely nothing to me.  Can
> >> > you give me any clues?
> >>
> >> which commit?
> >>
> >> normally we only need to have split root resource into several pieces
> >> when we have two HT chains or other io chains...
> >
> > I meant the patches here:
> >  http://lkml.org/lkml/2009/6/24/557
> >
> > My opinion is that ACPI is there to give us an abstract description of
> > the machine, and we shouldn't have to introduce knowledge like "this
> > machine has two HT chains" or add checks in amd_bus.c about
> > "pci_root_num <= 1".
> >
> > But maybe if I knew what an HT chain was and why you think it affects
> > the description returned by _CRS, it would give me a clue about how to
> > deal with this in a generic way.
> 
> we could use _CRS, but lots of BIOS just provide messed up resources
> in _CRS to OS.

We do have to assume there are BIOS defects here, but in most cases, I
look for Linux deficiencies first.  I'm assuming (without real evidence)
that Windows does look at the _CRS, so the worst BIOS defects should be
weeded out by Windows testing.

> for example, the HW conf register does have mmio high range there, but
> _CRS doesn't report them.

On Larry's box, _CRS reports *more* ranges than Linux was prepared for.
This would be a bug in the other direction, where _CRS reports *less*
than it should.

> thought we can use whilelist to use _CRS for them.

I'm opposed to a whitelist for this issue because it means we have to
continually update the whitelist for new, correctly working machines.
If we can't figure out anything better, we could use a date-based
blacklist (ignore _CRS for all machines older than today).

But first, we have to establish that there really is a requirement to
look at _CRS, then have a good try at making Linux smart enough to deal
with whatever it finds.

Bjorn


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

Powered by Openwall GNU/*/Linux Powered by OpenVZ