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:	Mon, 11 Dec 2006 14:55:39 +1100
From:	Benjamin Herrenschmidt <benh@...nel.crashing.org>
To:	Stephen Hemminger <shemminger@...l.org>
Cc:	Greg Kroah-Hartman <gregkh@...e.de>,
	linux-pci@...ey.karlin.mff.cuni.cz, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 4/6] MTHCA driver (infiniband) use new pci interfaces

On Fri, 2006-12-08 at 10:22 -0800, Stephen Hemminger wrote:
> plain text document attachment (mthca-rbc.patch)
> Use new pci interfaces to set read request tuning values
> Untested because of lack of hardware.

I'm worried by this... At no point do you check the host bridge
capabilities, and thus will happily set the max read req size to some
value larger than the max the host bridge can cope...

I've been having exactly that problem on a number of setups, for
example, the sky2 cards tend to start with a value of 512 while the G5's
host bridge can't cope with more than 256 (iirc). The firmware fixes
that up properly on the G5 at least (but not on all machines), but if
you allow drivers to go tweak the value without a way to go check what
are the host bridge capabilities, you are toast.

Of course, on PCI-X, this is moot, there is no clear definition on how
to get to a host bridge config space (if any), but on PCI-E, we should
be more careful.

So for PCI-X, if we want tat, we need a pcibios hook for the platform
to validate the size requested. For PCI-E, we can use standard code to
look for the root complex (and bridges on the path to it) and get the
proper max value.

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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ