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]

Message-Id: <201106232242.29753.rjw@sisk.pl>
Date:	Thu, 23 Jun 2011 22:42:29 +0200
From:	"Rafael J. Wysocki" <rjw@...k.pl>
To:	Jesse Barnes <jbarnes@...tuousgeek.org>
Cc:	Ram Pai <linuxram@...ibm.com>,
	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, Bjorn Helgaas <bhelgaas@...gle.com>
Subject: Re: [PATCH 4/4] PCI: make cardbus-bridge resources nice-to-have

On Thursday, June 23, 2011, Jesse Barnes wrote:
> On Tue, 21 Jun 2011 17:48:16 -0700
> Ram Pai <linuxram@...ibm.com> wrote:
> > I assume majority of the platforms will have enough resources to satisfy all
> > the resource requests, and their BIOS would have done a decent job.
> > 
> > Even if the BIOS has not done a decent job, and there are enough resources
> > available we should not see a regression.
> > 
> > The only platforms that would expose a regression is when resources are under
> > contention and the BIOS has assigned enough resource to the cardbus bridge but
> > not to some other device. It will be hard to find such a platform, but I am
> > sure there is one out somewhere there.
> > 
> > I am sure we will see; some day, reports of regression because that platform
> > would have the exact right characteristics to expose the issue. But then that
> > platform is a highly constrained platform in the first place. Its debatable if
> > that should be characterised as a regression, or a platform that was riding on
> > good luck till now.
> > 
> > Even Oliver's platform is a highly constrained platform, and we probably can
> > treat his platform as 'riding on good luck till now'.
> > 
> > We won't be able to satisfy all the platforms with resource constraints.  I
> > think our probable choice is to select a solution that breaks least number of
> > platforms and special case those broken platforms through kernel command line
> > parameters.
> 
> Another option is to hide the new allocation behavior behind a kernel
> parameter.  I know Bjorn has opposed this in the past because really
> this sort of thing should "just work".  But so far it hasn't, and we've
> had to revert both Bjorn's resource tracking changes as well as the
> re-allocation code.
> 
> Hiding it behind a boot option would at least let us improve things
> over time and potentially switch over to new resource code in the
> future...
> 
> Thoughts?

Do I understand correctly that at the moment we have two set of systems,
one of which works with the new code and doesn't work with the old code
and the other one conversely?

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