Memory mapped to userspace from /dev/mem cannot be used with a process-shared futex() on ARM, but can on at least x86_64 (other architectures untested).  This breaks userspace locking under this scenario.

The cause looks to be that ARM doesn't yet implement get_user_pages_fast(), which is called in get_futex_key() for a non-process private futex.

On ARM the weak wrapper function in mm/util.c is used as a compatibility fallback.  This fallback takes the mm->mmap_sem lock, and calls through to get_user_pages().  Unfortunately get_user_pages() returns -EFAULT for pages marked with VM_IO | VM_PFNMAP set.  Memory which has been mapped to userspace through /dev/mem is correctly flagged in this way.  

get_user_pages_fast() on other platforms, as implemented in arch/.../gup.c does not check for VM_IO or VM_PFNMAP, so succeeds to allow the futex() functionality to work.

Implementing get_user_pages_fast() to the same spec on ARM should fix this.  The weak get_user_pages_fast() may also need fixing or removing since it's behaviour isn't the same as get_user_pages_fast() in all cases.

If might be the case that get_user_pages_fast() is wrong to return vma's with VM_IO or VM_PFNMAP flagged, but in such a case that is a bug carried on all existing architectures, so may be considered separately.