Re: [PATCH v2 21/29] nios2: Futex operations

[Arnd Bergmann <arnd@arndb.de>]

On Friday 18 July 2014 14:07:42 Ley Foon Tan wrote:
> On Thu, Jul 17, 2014 at 7:07 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> > The get_user/put_user functions really need to be annotated might_fault(),
> > because that's what they do.
> >
> > The whole point of get_user() is to access an unchecked user space
> > pointer, which  can do a number of things based on what the pointer
> > points to:
> >
> > - access a user space variable that resides in memory
> > - access a kernel pointer and fail because of the access_ok()
> >   check
> > - access a user space pointer that is not mapped and return
> >   through the __ex_table fixup.
> > - access a user space pointer that has a valid VMA but not PTE,
> >   causing a page fault to be resolved.
> >
> > It's the last case that breaks here.
> So, do you mean that we can't use get_user/put_user in futex support?
> BTW, some architectures like sh,parisc, m68k use get_user in futex
> function as well.
> Any recommendation way to support futex if we can't use get_user.
> Note, nios2 doesn't have atomic instruction.
> Thanks.

I looked at it again now and I'm no longer sure about my initial
interpretation. The way it seems to work is that pagefault_disable()
turns the case I mentioned into a simple error through the fixup,
so we return -EFAULT from get_user, and retry the futex from
futex_wake_op().

This would however also mean that there is no need for a spinlock
at all, atomicity is already implied by pagefault_disable() here
because you are running on a UP kernel and pagefault_disable() also
means there is no preemption.

If this understanding is right, we can probably just merge the
m68k implementation into the asm-generic version, as that does
exactly that, and just isn't SMP safe. I'm still unsure whether
I'm missing something here though, as everything else seems to
do this in assembly, even for non-SMP machines that could use
the trivial method that m68k has.

	Arnd