linux-kernel - Re: [PATCH 4/4] PCI: make cardbus-bridge resources nice-to-have

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, 21 Jun 2011 11:50:43 -0700
From:	Jesse Barnes <jbarnes@...tuousgeek.org>
To:	Ram Pai <linuxram@...ibm.com>
Cc:	Dominik Brodowski <linux@...inikbrodowski.net>,
	linux-kernel@...r.kernel.org, linux-mmc@...r.kernel.org,
	svenkatr@...com, yinghai@...nel.org, cjb@...top.org,
	linux-pci@...r.kernel.org, linux-net-drivers@...arflare.com,
	bhutchings@...arflare.com
Subject: Re: [PATCH 4/4] PCI: make cardbus-bridge resources nice-to-have

On Tue, 21 Jun 2011 09:23:21 -0700
Ram Pai <linuxram@...ibm.com> wrote:

> On Tue, Jun 21, 2011 at 09:57:00AM +0200, Dominik Brodowski wrote:
> > On Mon, Jun 20, 2011 at 03:47:17PM -0700, Ram Pai wrote:
> > > Allocate resources to cardbus bridge only after all other genuine
> > > resources requests are satisfied. Dont retry if resource allocation
> > > for cardbus-bridge fails.
> > 
> > Well, for those who use cardbus cards, cardbus resources aren't "nice to
> > have", they are absolutely required. Of course, not all cardbus cards need
> > as many resources as are currently assigned, so I wouldn't oppose a patch
> > which marks _some_ of the currently assigned resources as "nice to have".
> > But this approach -- 0 required, all "nice to have" -- seems wrong to me.
> 
> Do you know how much minimal resource is good enough?  The value, before
> this patch, was 256 for IO ports and  64M for memory.
> 
> BTW: If the BIOS has already assigned enough resources for all the devices on
> the system, no devices will be starved including the cardbus. The OS intervenes
> and is forced to make this hard choice only when it sees unassigned resources to
> some devices along with resource contention.

I just know this is going to trigger regressions, so I think Dominik's
concern is valid.  We'll have some existing machine with a device whose
resource was never assigned, but we didn't care because it was unused.
Now this code will try to give it some address space at the expense of
something that *is* being used.

But OTOH this will at least try to allocate *some* space to cardbus, we
just won't try as hard as with some other resources.  I'd mainly like
to avoid the situation Dominik pointed out, where we have perfectly
good cardbus resources assigned (unlike in Oliver's case) but they're
stolen for a bridge that may get a hotplugged device or some other
device that didn't have a BIOS assignment.

-- 
Jesse Barnes, Intel Open Source Technology Center
--
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/