Bug 64321

Summary: futex(FUTEX_WAIT) returns -EFAULT on VM_IO or VM_PFNMAP memory
Product: Memory Management Reporter: Michael.McTernan.2001
Component: OtherAssignee: Andrew Morton (akpm)
Status: RESOLVED WILL_NOT_FIX    
Severity: normal CC: alan
Priority: P1    
Hardware: ARM   
OS: Linux   
Kernel Version: HEAD Subsystem:
Regression: No Bisected commit-id:
Attachments: Test program to create a futex on some mmap() area

Description Michael.McTernan.2001 2013-11-03 14:09:37 UTC
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.
Comment 1 Michael.McTernan.2001 2013-11-03 14:26:21 UTC
Created attachment 113181 [details]
Test program to create a futex on some mmap() area
Comment 2 Andrew Morton 2013-11-04 21:52:18 UTC
OK, but I don't know which ARM developer might sit down and fix this.  I suggest that you email this report to linux-arm-kernel@lists.infradead.org.
Comment 3 Alan 2013-11-12 15:45:27 UTC
I think you'll need to fix it yourself probably, if the hardware can support the necessary properties.
Comment 4 Michael.McTernan.2001 2013-11-12 20:42:48 UTC
See thread here: http://www.spinics.net/lists/arm-kernel/msg284419.html

I'll close this now, thanks.