From: Arnd Bergmann <arnd@arndb.de>
To: Mike Frysinger <vapier.adi@gmail.com>
Cc: linux-kernel@vger.kernel.org, Paul Mundt <lethal@linux-sh.org>
Subject: Re: making asm-generic/futex.h completely usable
Date: Fri, 3 Jul 2009 17:51:46 +0200 [thread overview]
Message-ID: <200907031751.46280.arnd@arndb.de> (raw)
In-Reply-To: <8bd0f97a0907030114g459863e9l829a6291e990b9cf@mail.gmail.com>
On Friday 03 July 2009, Mike Frysinger wrote:
> ive been reading up on futexes of late and have been poking around the
> futex kernel pieces to see what is needed to get Blackfin working with
> it.
>
> Blackfin falls into the "no hardware atomic instructions" category as
> can easily be seen in our atomic.h: disable interrupts, do
> load/stores, restore interrupts. my understanding of the
> futex_atomic_op_inuser() function is that this runs in process
> context, so this same interrupt trick should work fine. which leads
> me to wonder why doesnt the asm-generic/futex.h header already take
> this approach ?
The code does not run in user space, the name indicates that it
operates on variables in user space while running in the kernel.
The irq-disable trick fundamentally does not work on SMP systems,
which need architecture specific atomic operations for this.
> seems to me that the SuperH implementation fits the bill nicely.
> their arch/sh/include/asm/futex-irq.h looks like it could be literally
> straight copied into asm-generic/futex.h thus making it fully
> functional for everyone by default.
That sounds reasonable for the arch/sh/include/asm/futex.h file, but
the futex-irq.h file would still be reserved for non-SMP architectures.
I believe that out of the architectures currently using asm-generic/futex.h,
blackfin is the only one that supports SMP, so you still lose ;-)
On blackfin, being NOMMU, you could problably do a respective implementation
for SMP, along the lines of
/* include/asm-generic/futex-nommu-smp.h */
static inline int atomic_futex_op_xchg_set(int oparg, int __user *uaddr,
int *oldval)
{
int *addr = (__force void *)uaddr; /* only valid on NOMMU */
if (!access_ok(VERIFY_WRITE, uaddr, 4))
return -EFAULT;
*oldval = xchg(addr, oparg);
return 0;
}
static inline int atomic_futex_op_xchg_add(int oparg, int __user *uaddr,
int *oldval)
{
int *addr = (__force void *)uaddr; /* only valid on NOMMU */
int tmp;
if (!access_ok(VERIFY_WRITE, uaddr, 4))
return -EFAULT;
tmp = *addr;
while ((*oldval = cmpxchg(addr, tmp, tmp + oparg)) != tmp)
tmp = *oldval;
return 0;
}
I.e. if your user space access is trivial, you can implement this using
the standard cmpxchg and xchg functions even on SMP.
Arnd <><
next prev parent reply other threads:[~2009-07-03 15:52 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-07-03 8:14 making asm-generic/futex.h completely usable Mike Frysinger
2009-07-03 15:51 ` Arnd Bergmann [this message]
2009-07-03 18:12 ` Mike Frysinger
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=200907031751.46280.arnd@arndb.de \
--to=arnd@arndb.de \
--cc=lethal@linux-sh.org \
--cc=linux-kernel@vger.kernel.org \
--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