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:	Thu, 27 Jul 2006 16:16:21 +0100
From:	"Jan Beulich" <jbeulich@...ell.com>
To:	"Michael Buesch" <mb@...sch.de>
Cc:	<jgarzik@...ox.com>, <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] fix Intel RNG detection

>> +#ifdef CONFIG_SMP
>> +static volatile char __initdata waitflag;
>
>I don't think we want to add yet another use of volatile
>(see the kernel archives for why).
>Use memory barriers instead, please.

I can certainly do that.

>> +#define waitflag err
>
>That's really confusing magic.

Any better idea? I just wanted to prevent adding another #ifdef CONFIG_SMP, and since it doesn't matter where the write
goes for UP, doing it that way seemed the simplest solution.

>> +	writeb(0xff, mem);
>> +	writeb(0x90, mem);
>> +	mfg = readb(mem + 0);
>> +	dvc = readb(mem + 1);
>> +	writeb(0xff, mem);
>
>Do these magic registers have names? Possible to use #defines for it?

While one could certainly make up names for them (the documentation of the functionality used here isn't the best I've
seen), I generally dislike creating defines when their values are used just in a single place *and* when their naming
can at best be artificial (i.e. doesn't serve documentation purposes). But if you and/or Jeff insist, I can certainly do
a change like that.

Jan

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