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: <20160323161158.GC205791@stormcage.americas.sgi.com>
Date:	Wed, 23 Mar 2016 11:11:58 -0500
From:	Alex Thorlton <athorlton@....com>
To:	Thomas Gleixner <tglx@...utronix.de>
Cc:	Alex Thorlton <athorlton@....com>, linux-kernel@...r.kernel.org,
	Ingo Molnar <mingo@...hat.com>,
	"H. Peter Anvin" <hpa@...or.com>, Hedi Berriche <hedi@....com>,
	x86@...nel.org
Subject: Re: [PATCH 1/2] Disable UV BAU by default

On Wed, Mar 23, 2016 at 12:27:44PM +0100, Thomas Gleixner wrote:
> On Mon, 21 Mar 2016, Alex Thorlton wrote:
> 
> First of all, please use proper patch prefixes.
> 
> x86/platform/uv: ....

Ah - sorry about that!

> And please fold the documentation change into the patch which changes the
> parameter.

Got it.  No problem!

> > +	if (!strncmp(arg, "on", 2)) {
> > +		nobau = 0;
> > +		pr_info("UV BAU Enabled\n");
> > +	} else if (!strncmp(arg, "off", 3)) {
> > +		nobau = 1;
> > +		pr_info("UV BAU Disabled\n");
> > +	}
> 
> What's the value of having that extra argument?
> 
> The default is off, so we can do with a simple "bau" or "enable_bau" and be
> done with it.

This was actually what I initially wrote, but we decided to go with the
on/off switch instead, because, in the UV4 time-frame, we're hoping to
get a few things changed so that we can default to having the bau *on*
for the new UV4 systems.

I left that detail out of the original commit message, as I didn't
figure our future (still tentative) plans were all that important to the
community.  I can add that information to my commit message, if you
would prefer to see it there.

I'll get the other stuff fixed up.  Please let me know if you'd like for
me to give a bit more detail in the commit message about the motivation
for the on/off switch vs. an enable flag.

Thanks for the input!

- Alex

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ