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] [day] [month] [year] [list]
Date:	Fri, 21 Mar 2008 17:56:47 -0500
From:	Peter Tyser <ptyser@...-inc.com>
To:	Doug Thompson <norsk5@...oo.com>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	dougthompson@...ssion.com, alan@...rguk.ukuu.org.uk,
	linux-kernel@...r.kernel.org, Ingo Molnar <mingo@...e.hu>,
	Thomas Gleixner <tglx@...utronix.de>, Andi Kleen <ak@...e.de>
Subject: Re: [PATCH 3/3] EDAC Add e752x parameter for sysbus_parity
	selection

> > > +
> > > +	/* Allow module paramter override, else see if CPU supports parity */
> > > +	if (sysbus_parity != -1) {
> > > +		enable = sysbus_parity;
> > > +	} else if (cpu_id[0] &&
> > > +		   ((strstr(cpu_id, "Pentium") && strstr(cpu_id, " M ")) ||
> > > +		    (strstr(cpu_id, "Celeron") && strstr(cpu_id, " M ")) ||
> > > +		    (strstr(cpu_id, "Core") && strstr(cpu_id, "Duo")))) {
> > > +		e752x_printk(KERN_INFO, "System Bus Parity not "
> > > +			     "supported by CPU, disabling\n");
> > > +		enable = 0;
> > > +	}
> > 
> > Is that the best way of working out whether the CPU supports system bus
> > parity?  We do have cpu capability infrastructure in x86 core and I'd have
> > thought it would be better for x86 core to work this out, set the suitable
> > flag and have clients (ie: EDAC) test that flag?
> > 

The above implementation was the only way I could think of to
dynamically determine if hardware supported system bus parity at
runtime.  I agree that adding a new x86 cpu capability flag for system
bus parity support would be an ideal way to support this feature for use
by subsystems such as EDAC.  However, there are a whole lot of possible
x86 CPU/Northbridge combinations and I could think of no clean way to
easily determine which of those combinations do or don't support system
bus parity.  The logic needed to compare the incredibly large number of
CPU and Northbridge combinations seems rather daunting...

The current patch was manageable in that only a few CPU/Northbridge
combinations needed to be accounted for and a module parameter would
allow for a manual override if necessary.

If others have suggestions as far as a more generic or generally cleaner
approach, I'd be happy to implement and test.

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