linux-kernel - Re: [113/197] x86, cacheinfo: Calculate L3 indices

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: <20100506081721.GA20616@aftab>
Date:	Thu, 6 May 2010 10:17:21 +0200
From:	Borislav Petkov <borislav.petkov@....com>
To:	Jiri Kosina <jkosina@...e.cz>
CC:	Greg KH <gregkh@...e.de>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"stable@...nel.org" <stable@...nel.org>,
	"stable-review@...nel.org" <stable-review@...nel.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Alan Cox <alan@...rguk.ukuu.org.uk>,
	"H. Peter Anvin" <hpa@...or.com>, Ingo Molnar <mingo@...e.hu>,
	Thomas Renninger <trenn@...e.de>, Jiri Benc <jbenc@...e.cz>,
	"Herrmann3, Andreas" <Andreas.Herrmann3@....com>,
	"Ostrovsky, Boris" <Boris.Ostrovsky@....com>
Subject: Re: [113/197] x86, cacheinfo: Calculate L3 indices

From: Jiri Kosina <jkosina@...e.cz>
Date: Wed, May 05, 2010 at 05:33:45PM -0400

> Yeah, you are right, returning -1 is bogus as well.
> 
> The point is though, that we really should be checking for return value of 
> node_to_k8_nb_misc() as it can legitimately return NULL, can't it? (and 
> other places, such as show_cache_disable() and store_cache_disable(), are 
> checking for this being NULL properly).

Well, I don't like sprinkling NULL ptr checks all over the place - this
makes the code unreadable and means that there's something wrong with
its design in the first place.

Therefore, it is better IMO to verify whether the K8_NB thing is
initialized properly and exit early if not. And this is what the two
patches I'm suggesting try to accomplish:

1. Call into K8_NB on AMD unconditionally so that we have those
initialized (we'll be needing them more in the future, I guess)

2. Check in the L3 cache code whether K8_NB has initted properly and
bail out if not.

With this, no need for NULL ptr checks anywhere and you got
better/smaller/more readable code with the proper assumptions in place.

Thanks.

-- 
Regards/Gruss,
Boris.

--
Advanced Micro Devices, Inc.
Operating Systems Research Center

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