linux-kernel - Re: [tip:x86/cpu] x86, cpu: AMD errata checking framework

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]

Message-ID: <20100708180032.GJ11824@escobedo.osrc.amd.com>
Date:	Thu, 8 Jul 2010 20:00:32 +0200
From:	Hans Rosenfeld <hans.rosenfeld@....com>
To:	"H. Peter Anvin" <hpa@...or.com>
CC:	"mingo@...hat.com" <mingo@...hat.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"tglx@...utronix.de" <tglx@...utronix.de>,
	"linux-tip-commits@...r.kernel.org" 
	<linux-tip-commits@...r.kernel.org>
Subject: Re: [tip:x86/cpu] x86, cpu: AMD errata checking framework

On Thu, Jul 08, 2010 at 10:59:50AM -0400, H. Peter Anvin wrote:
> > I have looked into the issue and I think the main problem is not in
> > those patches, although either of the two patches could have fixed it
> > one way or another. Adding a dummy cpu_has_amd_erratum() would be one
> > way to do it, but I don't think it would be right.
> > 
> 
> It works well, and gcc will then remove the associated code.

Maybe it removes the code directly associated with the check, but the
rest of the stuff is still there. So when you build without AMD
support, you get whole lot of dead AMD-specific code. Well, I
personally don't care.

> > Second, the cpu_has_amd_erratum() function is supposed to be called
> > only once for each erratum by initialization code. You should never
> > ever call it repeatedly in loops or interrupt handlers. If you need to
> > check for an erratum in such a place, cache the result in a local
> > variable. That would even be advisable without specifying the erratum
> > in the argument list.
> 
> There is absolutely no reason to believe that that is actually the
> case... and even if it was, it could get changed by gcc behind the
> programmer's back.  This assertion is insane.

Maybe I'm getting something wrong here, but I highly doubt that gcc is
buggy enough to reorder function calls into loops or random unrelated
code. Also, having a function for a special purpose that requires
special handling is not such an uncommon thing, and documenting that
wouldn't pose much of a problem.

> > Really, I don't see what this change would gain us, but it would
> > certainly make it harder to maintain.
> 
> Centralization and abstraction.

Yes, thats a generally a good thing, in source code at least. Thats
why I added the abstraction for errata definitions in _one_ central
place, not in two. Where it ends up in memory once it's been compiled
isn't really of interest there.

>From your other mail,
> On a note on that... by passing the definition as arguments you're doing
> it asas *code*, which is seriously bloated over a memory structure.  The
> size of memory structures should be insignificant, and would be cold in
> memory anyway.

In case of the erratum 400 code (using 2 ranges), passing it as
arguments uses 4 bytes less. An erratum using 3 ranges will use 2
bytes more. While I don't think it matters at all, it is certainly not
"seriously bloated".

> Perhaps I wasn't making myself clear enough.  If you submit the same
> style of code again, I will veto it.

That is probably the first convincing argument in this discussion.

Hans

-- 
%SYSTEM-F-ANARCHISM, The operating system has been overthrown

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