Red Hat Bugzilla – Bug 63643
Missing begin comment in /usr/include/asm/atomic.h
Last modified: 2007-04-18 12:42:03 EDT
From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; Q312461; .NET
Description of problem:
In glibc-kernheaders-2.4-7.13 the file /usr/include/asm/atomic.h at line 11
is missing a begin comment at "Make sure", so compiles fail when including
* Atomic operations that C can't guarantee us. Useful for
* resource counting etc..
* Make sure gcc doesn't try to be clever and move things around
* on us. We need to use _exactly_ the address the user gave us,
* not some alias that contains the same information.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Examine /usr/include/asm/atomic.h
Yup, fixed already.
However nothing should ever include atomic.h though.....
The Apache Portable Runtime (http://apr.apache.org) explicitly includes
this file in include/apr_atomic.h.
APR is broken. Very broken. It makes assumptions that are just not true.....
what assumptions does it make?
it looks like the current 'standard' kernel version of atomic.h is different
to redhat's ('beta') version
is there a actual reason for this (bug#)
1) it makes the assumption that those functions are also atomic in userspace,
which isn't the case actually (not even on i386)
2) it makes the assumption that those functions compile in userspace, which
the case all architectures (some architectures need to use spinlocks for this
since the cpu doesn't have the atomic ops themselves)
3) this is not a kernel header. It's a glibc header which happens to be derived
from the kernel.
There reasons for the header to be different:
1) it doesn't do what people think it does resulting in nasty bugs (see #1
above). Our developer support department had several nasty cases with this.
2) it's a kernel private header. there's NO guarantee about this not breaking
for different kernel versions. The glibc headers package however is there to
provide a stable API for userspace. This means that internal,
not-for-userspace headers (or parts of headers) cannot be in that since the
kernel developers don't guarantee API stability in those, not even in a
stable kernel series. (and esp not for userspace use)
3) There's the angle that these inlines are covered by the GPL license. Programs
using them would therefor include compiled gpl code in their binary, which
is a legal minefield at best
Our biggest concern is that Linux doesn't have any userspace atomic interface
(such as FreeBSD-CURRENT does).
I have submitted a patch to the APR development list to use handcoded assembly
(based on FreeBSD's assembly code since APR can't touch the Linux source code),
but I really feel that this is something that the core OS should be handling.
firstname.lastname@example.org: I agree, however that would be a glibc task, not a
kernel one; you don't want a syscall for every atomic operation....