All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michael.McTernan.2001@cs.bris.ac.uk (Michael McTernan)
To: linux-arm-kernel@lists.infradead.org
Subject: mm: get_user_pages_fast()
Date: Tue, 05 Nov 2013 22:43:15 +0000	[thread overview]
Message-ID: <52797483.2000105@cs.bris.ac.uk> (raw)

Hi all,

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.

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() then 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 architectures, as implemented in 
arch/.../gup.c doesn't appear have the same checks for VM_IO or 
VM_PFNMAP, so futex functionality can work.

Implementing get_user_pages_fast() to the same spec on ARM should fix 
this.  The weak get_user_pages_fast() may then also need fixing or 
eventually removing since its behaviour isn't the same as 
get_user_pages_fast() in all cases and may be causing bugs where it us 
used.  Bugs in locking are not very nice.

I've seen a couple of patches go by that provide get_user_pages_fast() 
on ARM, but none yet accepted.  I therefore would like to highlight this 
particular case for context, and also to perhaps generate some movement 
on this issue, which I also reported here:

https://bugzilla.kernel.org/show_bug.cgi?id=64321

For reference, here are some previous patches and discussion on adding 
this function:

http://lists.infradead.org/pipermail/linux-arm-kernel/2013-April/162115.html
https://lkml.org/lkml/2013/10/3/529
http://patches.linaro.org/21130/

Kind Regards,

Mike

             reply	other threads:[~2013-11-05 22:43 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-11-05 22:43 Michael McTernan [this message]
2013-11-06 10:19 ` mm: get_user_pages_fast() Will Deacon
2013-11-06 10:54 ` Russell King - ARM Linux
2013-11-06 11:07   ` Will Deacon
2013-11-06 19:38   ` Michael McTernan
2013-11-06 19:57     ` Russell King - ARM Linux
2013-11-06 22:31       ` Michael McTernan

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=52797483.2000105@cs.bris.ac.uk \
    --to=michael.mcternan.2001@cs.bris.ac.uk \
    --cc=linux-arm-kernel@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.