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: <ef16r7$vjo$1@sea.gmane.org>
Date:	Fri, 22 Sep 2006 17:34:31 +0000 (UTC)
From:	"Matthieu CASTET" <castet.matthieu@...e.fr>
To:	linux-kernel@...r.kernel.org
Subject:  Re: [PATCH 1/3] [BFIN] Blackfin architecture patch for 2.6.18

On Fri, 22 Sep 2006 17:48:03 +0800, Luke Yang wrote:

>> 9.  In struct sport_register, what are all of those volatiles
>> for?  Use of volatile usually
>> indicates bad locking or bad memory barriers, etc., somewhere.
>  This is not a bug. In embedded, a memory mapped register should be
> defined as volatile, becasue the hardware may change it without
> notifying the software.
>
No this is bad design. Each time you want to access those memory map
register you should use read{bwl}/in{bwl} variants.
After all memory mapped register are not so different of mmio on standard
PC.

For example on au1x00 mips platform [1], some helper are defined to access
those memory map registers.

using volatile is awful : instead of a clean API to access those
registers, you often forgot that volatile is need which lead to very hard
to debug bugs (depend of compiler optimization, state of memory, ...).
For example on a embedded platform (ADI fusiv) where volatile are used
everywhere, some developers forgot some, which lead to random lockup on
boot.

Matthieu


[1]
include/asm-mips/mach-au1x00/au1000.h
static inline u32 au_readl(unsigned long reg)
{
    return (*(volatile u32 *)reg);
}

-
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