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]

Message-Id: <20060716.182334.30182563.davem@davemloft.net>
Date:	Sun, 16 Jul 2006 18:23:34 -0700 (PDT)
From:	David Miller <davem@...emloft.net>
To:	mrmacman_g4@....com
Cc:	acahalan@...il.com, dwmw2@...radead.org, arjan@...radead.org,
	maillist@...55.com, ralf@...ux-mips.org,
	linux-kernel@...r.kernel.org
Subject: Re: 2.6.18 Headers - Long

From: Kyle Moffett <mrmacman_g4@....com>
Date: Sun, 16 Jul 2006 08:34:53 -0400

> Both of which may be easily cut and pasted into your GPL programs  
> with little or no effort (Hint: I do this all the time).  Those are  
> so stable you don't even have to maintain it!  IMHO, what you really  
> want, though, is for GCC to export a library of ASM intrinsics (like  
> memory barriers, atomic ops, etc), that are available on your current  
> architecture.  If there is no __gcc_atomic_inc then it wouldn't  
> #define it and you can just go back to pthread_mutex_lock/unlock for  
> protecting an atomic variable.  Such a library layer certainly  
> doesn't belong in the kernel, although if GCC got such a library  
> right the kernel might start to use it (although only the most recent  
> GCC would support it so it wouldn't be very useful).

I agree with your assertions that the stuff in asm/atomic.h should be
steered away from, since they generally are not expected to work in
userspace.  In fact, if you try to use the 32-bit sparc or parisc
ones, it simply won't link because the implementations are external
and use a hash table spinlock scheme which is in the kernel image.

However, the pthread based locking is bad if you want to recover
from arbitrary signals correctly.  I ran into this problem while
trying to get Linux/Sparc Mono working well.

When people want atomic cmpxchg or atomic increment/decrement, they
want a true atomic.  This means either finish the whole thing, or
leave no trace of the atomic having started in the first place.
Spinlock based atomic implementations, which is what a lot of
platforms lacking true atomic use, absolutely cannot reasonably
provide this semantic.
-
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/