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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <4A8532EA.20506@lumino.de>
Date:	Fri, 14 Aug 2009 11:48:26 +0200
From:	Michael Schnell <mschnell@...ino.de>
To:	unlisted-recipients:; (no To-header on input)
CC:	linux-kernel@...r.kernel.org,
	Mike Frysinger <vapier.adi@...il.com>,
	Paul Mundt <lethal@...ux-sh.org>
Subject: Re: implementing Futex

Arnd Bergmann wrote:
> On Thursday 13 August 2009, Michael Schnell wrote:
>> I am planning to implement a Futex on the upcoming MMU-enabled NIOS
>> architecture.
> 
> Ah, I'm always interested in new architectures. Are you already using
> all the asm-generic header files that we have in 2.6.31? Please tell
> me if you find problems with those.

Hi Arnd,
Thanks a lot for answering.

I've not really started coding, as I need to use the port of gcc 4,
Kernel, and libraries done by Montavista on behalf of Altera and going
to be managed by "uClinux-NIOS", currently in Taipei, Taiwan. The
releasing of the source code to "public domain" is expected within the
next few days and as of that I can start the project.

Currently I do my researches based on Kernel 2.6.30. I do suppose the
distribution will be upgraded to 2.6.31 soon.

> 
> Common trap. Just don't look at any x86 code when implementing
> a new architecture. The code isn't necessarily bad, but much of
> it has either too much compatibility crap for old interfaces, or
> it optimizes some functionality much more than you'd care for.
> 
> In case of futex, look at how arch/sh does it. As Mike Frysinger
> mentioned in http://lkml.org/lkml/2009/7/3/70 , the asm-generic
> version is currently lacking functionality and we should use
> the sh version for new stuff. 

OK, I'll take a look there.

> 
> Feel free to submit a patch that implements the operations correctly
> for non-SMP architectures in include/asm-generic/futex.h.

With NIOS this is not that obvious. At the moment we are discussing two
completely different ways to solve the problem of nonexistent atomic
operations.

A) do it like many other non-SMP archs do: in Kernel mode disable the
interrupt temporarily and in user mode (The hardware prevents disabling
interrupt here) use a common code page that holds the would-be atomic
code sequences and in Interrupt-exit code check the PC if we are in that
area and if necessary restart the atomic function.

B) take advantage of the possibility to implement custom instructions
with the FPGA based processor. Unfortunately it's not possible to
directly implement atomic operations nor is it possible to temporarily
disable interrupt with a custom instruction. So out first idea is to do
a hardware FUTEX with a custom instruction that can be used in
user-space to protect the three-instruction sequences that would
implement the atomic code sequences.

(A) would be more "standard" and is a well-verified paradigm, (B) would
offer less overhead (i.e. no overhead to UNRELATED interrupts at all)
and later could be portable to an SMP Kernel.

As even with B I suppose we would need to use the disable interrupt
trick in Kernel modem, I need to understand which code sequences really
are used and in which mode they run (the CPUs "System mode" or "user
mode", interrupt disabled or enabled.)

>> In a non-SMP environment do we need to use really atomic code here, or
>> does futex_atomic_op_inuser() run with interrupt disabled, anyway?
> 
> The sh version just disables interrupts to get atomicity.

Do you think I am correct assuming that sh CPU like NIOS also has a
"System Mode" (interrupt disabling is allowed) and a "User Mode" (trying
to disable the interrupt generates an "Illegal Instruction" trap). If so
 in that code sequence are in "System Mode".

> 
> You misread futex_wake_op(). The operation comes from the second parameter
> of the syscall, not the last one.
> 

Ooops, thanks a lot for looking this up for me !

I'll take another look !

Thanks again,
-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/