linux-kernel - Re: [PATCH 2/3] pci: Clamp pcie_set_readrq() when using "performance" settings

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, 04 Oct 2011 18:08:13 +0200
From:	Benjamin Herrenschmidt <benh@...nel.crashing.org>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Jon Mason <mason@...i.com>, Greg Kroah-Hartman <gregkh@...e.de>,
	Jesse Barnes <jbarnes@...tuousgeek.org>,
	Bjorn Helgaas <bhelgaas@...gle.com>,
	linux-kernel@...r.kernel.org, linux-pci@...r.kernel.org,
	Benjamin LaHaise <bcrl@...ck.org>
Subject: Re: [PATCH 2/3] pci: Clamp pcie_set_readrq() when using
 "performance" settings

On Tue, 2011-10-04 at 08:48 -0700, Linus Torvalds wrote:
> On Tue, Oct 4, 2011 at 8:40 AM, Benjamin Herrenschmidt
> <benh@...nel.crashing.org> wrote:
> >
> > Hopefully most of these patches only affect the "performance" setting
> > which is no longer the default.
> >
> > But yes, more reviews are always welcome.
> 
> Well, bcrl argues that patches 1-2 of 3 are actively wrong.

This is an argument that isn't finished :-)

In any case, what Ben's arguing about is the whole "performance" mode
which is -already- implemented in your tree, except that the current
implementation you have is totally broken and those patches fix it. This
mode is optional and isn't the default.

> Quite frankly, my gut feel is that this late in the game, he only
> patch I should apply is 3/3, and even that I wonder about. But that
> seems to *really* disable all the games we do, and that all seem to be
> questionable.

Sort-of yes. The "safe" mode shouldn't be questionable. It's the right
way to safely configure the system. But as usual, we get defeated by
chipset errata.

Still, I think Jon has workarounds for a bunch and having those modes as
options for broken BIOSes is handy.

The real thing for me is that this ability to configure MPS and MRRS
from scratch is needed for platforms where the firmware isn't doing it
at all, such as some embedded platforms or our new upcoming "no pHyp"
KVM-oriented power platforms.

So I like having the code there and the ability to turn it on either
manually or from platform code.

But I agree that at this point, the right default for the x86 mess
should be "don't touch" which is what 3/3 does afaik.

> Comments? Please? I'm going to do an -rc9 today, and after that I'll
> be travelling a lot, so..

My vote is to apply Jon patches. 1/2 and 2/3 will have no effect unless
the "performance" mode is explicitly requested. Without them, it's
totally busted (ie the current implementation you have in your tree is
broken). Patch 3/3 will make sure that the default is to not do
anything.

Cheers,
Ben.

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