linux-kernel - Re: atomic RAM ?

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: <20100409125426.5bc200da@lxorguk.ukuu.org.uk>
Date:	Fri, 9 Apr 2010 12:54:26 +0100
From:	Alan Cox <alan@...rguk.ukuu.org.uk>
To:	Michael Schnell <mschnell@...ino.de>
Cc:	linux-kernel <linux-kernel@...r.kernel.org>,
	nios2-dev <nios2-dev@...c.et.ntust.edu.tw>
Subject: Re: atomic RAM ?

> If "you" is You that might be true. But if "you" is me its utterly and
> totally wrong. For my heavily multithreaded application I need FUTEX but
> not SMP (yet). For me, SMP is no advantage if it does not support FUTEX
> and I suppose the SMP solution with a single hardware mutex can't do
> this (but maybe I'm wrong here and a software workaround is possible).

You are completing missing the point

Linux + glibc platforms don't "need" futex - you need fast user space
locks. Futex is an implementation of those locks really based around
platforms with atomic instructions. People were doing fast user space
locks before Linus was even born and on machines without atomic
operations.

Seperate out
- the purpose for which the system exists (fast user locking)
- the interfaces by which it must be presented (posix pthread mutex)
- the implementation of the system

> pthread_mutex..() uses FUTEX if available with the arch, so FUTEX is a
> way of complying to the POSIX standard. Of course there are other ways
> (that pthread_mutex_...() use if FUTEX is not available) but this asks
> for Kernel calls with any lock and any unlock and thus is a lot slower -
> maybe unusable with certain applications.

Nope. Glibc allows you to implement arch specific code for these locks
which may not be FUTEX but need not be kernel based. The user space
mechanics of the futex stuff include platform specific stuff for all
platforms. You might do the blocking kernel parts of it via the futex
syscall but what matters are the uncontended fast paths which are arch
specific C library code.

> IMHO, the only decent way to go is to provide FUTEX perfectly compatible
> to what other archs do, and thus have it be accessed via pthread_mutex()
> so that any "standard" POSIX compatible multithreaded application will
> take advantage of the speed gain.

You clearly need a pthread_mutex that is fast - but the idea that this
means FUTEX is misleading and futex on each platform in the user space
side is different per architecture anyway.

The idea that you need atomic operations to do fast user space locking is
also of course wrong - you only need store ordering.

Alan
--
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/