linux-kernel - Re: [PATCH 1/3] [BFIN] Blackfin architecture patch for 2.6.18

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]

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/