From: Arnd Bergmann <arnd@arndb.de>
To: Michael Schnell <mschnell@lumino.de>
Cc: linux-kernel@vger.kernel.org,
Mike Frysinger <vapier.adi@gmail.com>,
Paul Mundt <lethal@linux-sh.org>
Subject: Re: implementing Futex
Date: Thu, 13 Aug 2009 18:39:41 +0200 [thread overview]
Message-ID: <200908131839.41803.arnd@arndb.de> (raw)
In-Reply-To: <4A842B32.5030401@lumino.de>
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.
> One of the tasks is to provide the appropriate atomic user-space
> operations for the Futex implementation. I was able to successfully do
> this for the x86 user space code and we have been discussing, how to do
> this with other archs.
>
> Now in the Kernel code in "linux-2.6/arch/x86/include/asm/futex.h" there
> are two different implementations for some atomic operations for the Futex:
>
> "futex_atomic_op_inuser()" and
> "futex_atomic_cmpxhg__inatomic()"
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.
Feel free to submit a patch that implements the operations correctly
for non-SMP architectures in include/asm-generic/futex.h.
> "futex_atomic_op_inuser()" seemingly accesses user space data while
> being run in Kernel space (doing the .section __ex_table trick).
>
> Questions:
>
> Is this correct ?
yes.
> 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.
> From reading the code (futex_atomic_op_inuser() seems only to be called
> once (in futex.c) ), it seems that futex_atomic_op_inuser() is not
> really used at all. It seems that it'd only called for futex_wake, and
> here the "Operation" is derived from the last parameter of the system
> call, which the man page says is ignored. So, are all the operations
> implemented there really necessary or just "nice to have" ?
You misread futex_wake_op(). The operation comes from the second parameter
of the syscall, not the last one.
Arnd <><
next prev parent reply other threads:[~2009-08-13 16:39 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-08-13 15:03 implementing Futex Michael Schnell
2009-08-13 16:39 ` Arnd Bergmann [this message]
2009-08-13 17:28 ` Arnd Bergmann
2009-08-14 9:46 ` Michael Schnell
2009-08-14 11:44 ` Arnd Bergmann
2009-08-17 8:57 ` Mike Frysinger
2009-08-14 9:48 ` Michael Schnell
[not found] ` <4A8525A1.205@lumino.de>
[not found] ` <200908141128.01179.arnd@arndb.de>
2009-08-14 10:03 ` Michael Schnell
2009-08-14 10:11 ` Michael Schnell
2009-08-14 11:55 ` Michael Schnell
2009-08-14 12:38 ` Arnd Bergmann
2009-08-14 12:56 ` Michael Schnell
2009-08-14 13:33 ` Arnd Bergmann
2009-08-31 16:30 ` Darren Hart
2009-08-17 8:50 ` Michael Schnell
2009-08-17 11:53 ` [Nios2-dev] " Michael Schnell
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200908131839.41803.arnd@arndb.de \
--to=arnd@arndb.de \
--cc=lethal@linux-sh.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mschnell@lumino.de \
--cc=vapier.adi@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox