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]

Message-ID: <495FFA73.6030705@shaw.ca>
Date:	Sat, 03 Jan 2009 17:53:23 -0600
From:	Robert Hancock <hancockr@...w.ca>
To:	Pavel Machek <pavel@...e.cz>
CC:	Alan Cox <alan@...rguk.ukuu.org.uk>,
	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

Pavel Machek wrote:
> On Sat 2009-01-03 20:30:44, Alan Cox wrote:
>>> If it is okay and linux relies on it, it should be documented.
>>>
>>> If it is not okay, I guess we should document it, too -- it seems to
>>> be common mistake. 
>> A lot of old code did it knowing it was under the BKL, outside of the BKL
>> its a very bad idea. There were lots of them in the tty layer and I don't
>> doubt there are some left I missed too 8(
> 
> I have seen this in new code (some LED driver last time), definitely
> no BKL.
> 
> Is there concrete architecture where it breaks? I'd expect i386/x86-64
> to be safe, and pretty much everyone to be safe as long as that long
> is aligned.... or that was the result of arch-maintainers
> discussion...
> 
> I'd really like to document if it is right or not, so that I can point
> people to documentation...
> 								Pavel

If you look at the atomic implementation on x86 all it does is assign 
and read the internal int variable directly for atomic_set and 
atomic_read, so I suppose it would be OK to just use a normal variable 
in that case.. but then there's no performance hit so you might as well 
use atomic_t anyway. On some architectures like arm and sparc there is 
some magic involved in atomic_set and/or atomic_read (but those may just 
be to guard against other concurrent atomic ops, I'm not sure).

Certainly unless the code is really performance critical there is no 
point messing around, just use an atomic if it needs to be accessed 
without locking. Note that memory barriers may be an issue as well..
--
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/