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:	Wed, 30 Jun 2010 14:45:05 -0700
From:	"Darrick J. Wong" <djwong@...ibm.com>
To:	"H. Peter Anvin" <hpa@...or.com>
Cc:	Andrew Morton <akpm@...ux-foundation.org>, mingo@...hat.com,
	linux-kernel@...r.kernel.org, muli@...ibm.com,
	cschultz@...ux.vnet.ibm.com, stable@...nel.org, tglx@...utronix.de,
	mingo@...e.hu, linux-tip-commits@...r.kernel.org
Subject: Re: [tip:x86/urgent] x86, Calgary: Increase max PHB number

On Wed, Jun 30, 2010 at 02:31:44PM -0700, H. Peter Anvin wrote:
> On 06/29/2010 03:51 PM, Andrew Morton wrote:
> > On Fri, 25 Jun 2010 15:29:50 GMT
> > "tip-bot for Darrick J. Wong" <djwong@...ibm.com> wrote:
> > 
> >> Commit-ID:  499a00e92dd9a75395081f595e681629eb1eebad
> >> Gitweb:     http://git.kernel.org/tip/499a00e92dd9a75395081f595e681629eb1eebad
> >> Author:     Darrick J. Wong <djwong@...ibm.com>
> >> AuthorDate: Thu, 24 Jun 2010 14:26:47 -0700
> >> Committer:  Ingo Molnar <mingo@...e.hu>
> >> CommitDate: Fri, 25 Jun 2010 16:14:58 +0200
> >>
> >> x86, Calgary: Increase max PHB number
> > 
> > arch/x86/kernel/pci-calgary_64.c: In function 'calgary_init_one':
> > arch/x86/kernel/pci-calgary_64.c:1059: warning: comparison is always false due to limited range of data type
> > 
> > from
> > 
> >         BUG_ON(dev->bus->number >= MAX_PHB_BUS_NUM);
> > 
> > with
> > 
> > http://userweb.kernel.org/~akpm/stuff/config-akpm2.txt
> 
> This comes from:
> 
> /*
>  * The maximum PHB bus number.
>  * x3950M2 (rare): 8 chassis, 48 PHBs per chassis = 384
>  * x3950M2: 4 chassis, 48 PHBs per chassis        = 192
>  * x3950 (PCIE): 8 chassis, 32 PHBs per chassis   = 256
>  * x3950 (PCIX): 8 chassis, 16 PHBs per chassis   = 128
>  */
> #define MAX_PHB_BUS_NUM		384
> 
> Clearly there can't be 384 busses with standard PCI numbering (bus
> numbers are 8 bits).  That means either that the number 384 is just
> wrong, or it means that there are multiple PCI domains involved, and
> that the BUG_ON() should be something else.
> 
> Furthermore, in get_tce_space_from_tar() we have:
> 
> 	for (bus = 0; bus < MAX_PHB_BUS_NUM; bus++) {
> 		struct calgary_bus_info *info = &bus_info[bus];
> 		unsigned short pci_device;
> 		u32 val;
> 
> 		val = read_pci_config(bus, 0, 0, 0);
> 		pci_device = (val & 0xFFFF0000) >> 16;
> 
> ... which assumes the bus is a PCI bus number, no domain involved.
> 
> Does this mean the limit should be 256 (in which case we can just drop
> the BUG_ON()), or is there support for domains which should be in this
> code but isn't?

Yes, it should be 256.  Some time ago there was talk of building 8-node
x3950M2s with PCI domain support, but the final word now is that nobody will
ever have more than 4 nodes.  The BUG_ON can be dropped, too.  I'll send a
patch shortly that incorporates both updates.

(Honestly I sort of wonder if the Calgary code should be removed entirely,
but that's a whole different battle....)

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