linux-kernel - Re: 2.6.18 Headers

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, 16 Jul 2006 13:48:25 +0100
From:	Russell King <rmk+lkml@....linux.org.uk>
To:	Kyle Moffett <mrmacman_g4@....com>
Cc:	Albert Cahalan <acahalan@...il.com>, dwmw2@...radead.org,
	arjan@...radead.org, maillist@...55.com, ralf@...ux-mips.org,
	linux-kernel@...r.kernel.org, davem@...emloft.net
Subject: Re: 2.6.18 Headers - Long

On Sun, Jul 16, 2006 at 08:34:53AM -0400, Kyle Moffett wrote:
> There is *NO* portable way to get atomic operations or locking in  
> userspace except through libpthread.

And as one of the maintainers of an architecture where this is true
(neither atomic.h nor bitops.h will work in userspace atomically) I
whole heartedly agree that the kernel's atomic operations must not
be exported to userspace via header files.

Anyone who thinks they will or should do is just kidding themselves.

The final point to add to this is that folk might be lucky, and the
kernel's atomic ops might _appear_ to work without raising any faults,
but that does _not_ mean that they are necessarily atomic in their
operation.  For example:

	unsigned long *a;

	a[bit >> 5] |= 1 << (bit & 31);

and

	set_bit(bit, &a);

are 100% equivalent in userspace if you use the kernel's asm-arm/bitops.h.
Neither will be atomic.  More importantly, _neither_ could be made to be
atomic.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 Serial core
-
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/