mm: get_user_pages_fast()

[Will Deacon]

On Wed, Nov 06, 2013 at 10:54:00AM +0000, Russell King - ARM Linux wrote:
> On Tue, Nov 05, 2013 at 10:43:15PM +0000, Michael McTernan wrote:
> > I think there's a problem on ARM with futex calls to FUTEX_WAIT and  
> > similar for addresses that have been mapped to userspace from /dev/mem  
> > or a device which sets VM_IO or VM_PFNMAP.  This can break  
> > pthread_mutex_lock() if placed on such mapped memory and attributed as  
> > process-shared.
> 
> Firstly, please stop this madness.  Placing futexes in IO memory is not
> supported, period.  You can't map random bits of /dev/mem and expect
> this stuff to work.

Yikes, I didn't notice that when I read the original post!

> (a) you're generally not allowed to map kernel memory via /dev/mem, so
> that rules out all kernel managed memory.
> (b) you are allowed to map memory outside of that, but you get it as
> strongly ordered memory.
> 
> (b) means that the load/store exclusives, which userspace mutexes will
> use on ARMv6+, will not work correctly.  (they're not supported to
> strongly ordered memory by the architecture.)
> 
> In other words, don't put mutexes in memory you've remapped from /dev/mem.
> In fact, as an application, you should not be mapping /dev/mem at all.

Completely agreed.

As an aside, fastgup is still something we want on ARM (it is required to
support futexes on transparent huge pages, which is what I originally
assumed this was about), so my previous comments about Steve's patches still
stand.

Will