linux-kernel - Re: atomics: document that linux expects certain atomic behaviour from unsigned long

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:	Sun, 04 Jan 2009 19:05:45 +0100
From:	Tilman Schmidt <tilman@...p.cc>
To:	Alan Cox <alan@...rguk.ukuu.org.uk>
CC:	Pavel Machek <pavel@...e.cz>,
	kernel list <linux-kernel@...r.kernel.org>,
	Andrew Morton <akpm@...l.org>, mtk.manpages@...il.com,
	rdunlap@...otime.net, linux-doc@...r.kernel.org
Subject: Re: atomics: document that linux expects certain atomic behaviour
 from unsigned long

On Sat 2009-01-03 20:19:55, Alan Cox wrote:
> On Sat, 3 Jan 2009 13:44:00 +0100
> Pavel Machek <pavel@...e.cz> wrote:
> 
> > Linux relies on unsigned long to behave like atomic for read/write.
> 
> Actually it isn't that simple and this advice shouldn't be given IMHO.
> 
> unsigned long is not the same as atomic in several respects including
> ordering and caching of the result.

I'm confused. I remember distinctly being told, when merging the
Gigaset driver, that reading and writing of "pointer sized objects"
(I specifically remember that term) was assumed to be atomic across
large parts of the kernel anyway, that locking around a single read
or write of such an item was therefore pointless, and that "atomic_t"
only made sense if I wanted to use atomic_inc or atomic_dec on them.
The patches I submitted in following that advice, specifically commit
4d1ff582246de67b15e3cd2427a39875943ae895 "gigaset: remove pointless
locking" and 9d4bee2b9de9e30057a860d2d6794f874caffc5e "gigaset: atomic
cleanup", were confirmed to do the right thing and merged without any
objection.

What am I missing?

Thanks,
Tilman

-- 
Tilman Schmidt                    E-Mail: tilman@...p.cc
Bonn, Germany
Diese Nachricht besteht zu 100% aus wiederverwerteten Bits.
Ungeöffnet mindestens haltbar bis: (siehe Rückseite)

Download attachment "signature.asc" of type "application/pgp-signature" (255 bytes)