linux-kernel - Re: making asm-generic/futex.h completely usable

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]

Date:	Fri, 3 Jul 2009 17:51:46 +0200
From:	Arnd Bergmann <arnd@...db.de>
To:	Mike Frysinger <vapier.adi@...il.com>
Cc:	linux-kernel@...r.kernel.org, Paul Mundt <lethal@...ux-sh.org>
Subject: Re: making asm-generic/futex.h completely usable

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