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>] [day] [month] [year] [list]

Date:	Thu, 08 Apr 2010 12:12:18 +0200
From:	Michael Schnell <mschnell@...ino.de>
To:	Giuseppe Calderaro <giuseppecalderaro@...il.com>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	nios2-dev <nios2-dev@...c.et.ntust.edu.tw>
Subject: Re: atomic RAM ?

On 04/08/2010 11:43 AM, Giuseppe Calderaro wrote:
>
> In the past I used the mutex connected to the avalon bus to get atomic
> test and set instructions:
> http://www.altera.com/literature/hb/nios2/n2cpu_nii51020.pdf
>
Of course I do know the Altera hardware Mutex, but same just implements
a single Mutex. To allow for FUTEX, which is the base of doing threaded
application with the pthread functions provided by libc, the application
programmer can create any number of pthread_mutex'es (of course a decent
restriction by hardware to some 1000 would usually not harm with typical
embedded applications).

Of course a multithreaded application should not be done in an
architecture depending way, but should be compilable for any arch and
thus the count of allowable pthread_mutex'es should not be greatly
restricted by the underlying hardware (be it NIOS or whatever else).

Of course you are right that using custom instructions to do a decent
count of atomic (hardware-) mutex'es necessary for implementing decent
SMP aware FUTEX (or even Kernel Mutex) stuff with NIOS and similar archs
is not strictly necessary, but I think it's handy to use them instead of
I/O-elements, as the MMU would disallow user space access to "normal"
I/O addresses.

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