linux-kernel - Re: implementing Futex

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <4A85367B.5080603@lumino.de>
Date:	Fri, 14 Aug 2009 12:03:39 +0200
From:	Michael Schnell <mschnell@...ino.de>
To:	Arnd Bergmann <arnd@...db.de>, linux-kernel@...r.kernel.org
CC:	Mike Frysinger <vapier.adi@...il.com>,
	Paul Mundt <lethal@...ux-sh.org>,
	Thomas Chou <thomas@...ron.com.tw>
Subject: Re: implementing Futex

Arnd Bergmann wrote:

> It sounds like this would be an optional feature of the FPGA code,
> and therefore I'd still suggest implementing option A with a compile-time
> choice so you don't need to have it. 

Yep that is the plan.

If the custom instruction is not provided either the "common area" trick
is used or (worse of course) the pthread_mutex calls fall back to use an
OS based mutex instead of a FUTEX.

>>  If so
>>  in that code sequence we are in "System Mode".
> 
> Yes.

Great !

Thus supposedly, as of Kernel 2.6.31, We don't need modifications in the
Kernel at all for NIOS supporting FUTEX. Only the user land library
needs to be tweaked.

OK, if we decide to use the "Common Area for atomic functions" trick, we
do need to create same in the Kernel startup code and enhance interrupt
return code appropriately. But I suppose we can borrow most of this from
the  Blackfin or sh implementation.

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