linux-kernel - Re: [PATCH -v2] pci: clear bridge resource size if BIOS assign bad one

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:	Tue, 8 Jun 2010 16:48:58 -0600
From:	Bjorn Helgaas <bjorn.helgaas@...com>
To:	Jesse Barnes <jbarnes@...tuousgeek.org>
Cc:	Yinghai Lu <yinghai.lu@...cle.com>,
	Yannick Roehlly <yannick.roehlly@...e.fr>,
	"linux-pci@...r.kernel.org" <linux-pci@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH -v2] pci: clear bridge resource size if BIOS assign bad one

On Tuesday, June 08, 2010 03:43:50 pm Jesse Barnes wrote:
> On Thu, 03 Jun 2010 13:43:03 -0700
> Yinghai Lu <yinghai.lu@...cle.com> wrote:
> 
> > 
> > Make sure We can reject wrong size from BIOS.
> > 
> > https://bugzilla.kernel.org/show_bug.cgi?id=16009
> > Yannick found that video does not work with 2.6.34
> > 
> > the root cause:
> > BIOS assigned wrong range to pci bridge.  and before 2.6.34 kernel will
> > just get range that is needed.
> > for 2.6.34.
> > |	d65245c PCI: don't shrink bridge resources
> > will try to range size is bigger than old one.
> > (used by boot stage multi-try to get big BAR size for pci bridge,
> >  and pcie hotplug to get big range)
> > 
> > So try to 0 for old size for pci bridge in this boot stage case.
> > 
> > Reported-by: Yannick <yannick.roehlly@...e.fr>
> > Analyzed-by: Bjorn Helgaas <bjorn.helgaas@...com>
> > Signed-off-by: Yinghai Lu <yinghai@...nel.org>
> > 
> 
> Bjorn, are you ok with this version?  It would probably help to have
> some comments here too (I can add them), indicating that we'll try to
> reassign the resource later, rather than just ignoring it as the
> existing comment implies.

I guess I'm ok with it.  I can't make much sense out of the changelog,
and I don't really understand how the reallocation stuff works.

In this case, the aperture *size* from the BIOS is actually OK, but
the beginning of the aperture overlaps system memory.  With Yinghai's
patch, we reduce the size and move the start.  Windows was able to
just move the start of the aperture and preserve the original
0x20000000 size (but I think it had to move something else out of
the way).

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/