On Friday 18 July 2014 14:07:42 Ley Foon Tan wrote: > On Thu, Jul 17, 2014 at 7:07 PM, Arnd Bergmann <arnd@xxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
