linux-kernel - Re: [Patch 1/1] x86 pci: Add option to not assign BAR's if not already assigned

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 1 Jun 2010 16:49:55 -0600
From:	Bjorn Helgaas <bjorn.helgaas@...com>
To:	Mike Travis <travis@....com>
Cc:	"H. Peter Anvin" <hpa@...or.com>, Ingo Molnar <mingo@...hat.com>,
	Thomas Gleixner <tglx@...utronix.de>, x86@...nel.org,
	Jesse Barnes <jbarnes@...tuousgeek.org>,
	Jacob Pan <jacob.jun.pan@...el.com>, Tejun Heo <tj@...nel.org>,
	Mike Habeck <habeck@....com>,
	LKML <linux-kernel@...r.kernel.org>, linux-pci@...r.kernel.org
Subject: Re: [Patch 1/1] x86 pci: Add option to not assign BAR's if not already assigned

[Re-added linux-pci, which got lost again somewhere.]

On Monday, May 31, 2010 05:12:00 am Mike Travis wrote:
> H. Peter Anvin wrote:
> > On 05/28/2010 10:10 AM, Mike Travis wrote:
> >> H. Peter Anvin wrote:
> >>> On 05/28/2010 09:53 AM, Mike Travis wrote:
> >>>> Any further consideration for this patch, or has it been rejected?

I'm disappointed that you didn't rework this to make it generic,
not x86-specific.  That would be pretty easy and would remove
the need for somebody else to come and clean it up later.

> >>> Well, it's really up to Jesse, but as far as I can see, this patch is a
> >>> net loss of functionality and doesn't actually add anything.  Without
> >>> this patch, some resources that were not assigned by BIOS will be
> >>> unreachable.  With this patch, *all* resources that were not assigned by
> >>> BIOS will be unreachable...
> >>>
> >>> 	-hpa
> >>>
> >> Apparently you're missing the point of the patch?  The patch is needed
> >> because BIOS is purposely not assigning I/O BAR's to devices that won't
> >> use them, freeing up the resource for devices that do need them.  Where
> >> is the "all" resources that are not reachable?
> > 
> > No, the patch isn't needed for those.
> > 
> > Without your patch:
> > 
> > - Devices assigned by BIOS remain assigned;
> > - Devices not assigned by BIOS get assigned until address space
> >   exhausted.
> > 
> > With your patch:
> > 
> > - Devices assigned by BIOS remain assigned;
> > - Devices not assigned by BIOS never get assigned at all.
> > 
> > What am I missing here?
> 
> BIOS still assigns the MMIO BAR's so the devices are alive.

I'm sorry; I don't follow this.  BIOS assigns MMIO BARs regardless
of whether we have your patch.

I'm still having trouble reconciling the stated purpose, i.e., the
changelog, with the behavior.  The changelog implies that the patch
is required to make >16 devices with I/O BARs work at all, but per
Mike Habeck, the patch just gets rid of some warnings and maybe helps
with hot-add of devices using I/O space.

Is there a deeper problem that happens if we exhaust I/O space?
Are we releasing device resources in pci_assign_unassigned_bridge_resources()
and then we fail to reassign even MMIO resources after we exhaust
I/O space?

Maybe a complete dmesg log showing the failure would be helpful.  if
so, you could open a kernel.org bugzilla and reference it in your
changelog so we can take this issue into account in future PCI work.

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/