Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1270824 > unrolled thread

[PATCH 02/37] mm, frame_vector: do not use get_user_pages_locked()

Started byDave Hansen <dave@sr71.net>
First post2015-11-17 04:50 +0100
Last post2015-11-18 18:10 +0100
Articles 3 — 3 participants

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.


Contents

  [PATCH 02/37] mm, frame_vector: do not use get_user_pages_locked() Dave Hansen <dave@sr71.net> - 2015-11-17 04:50 +0100
    Re: [PATCH 02/37] mm, frame_vector: do not use  get_user_pages_locked() Jan Kara <jack@suse.cz> - 2015-11-18 13:30 +0100
      Re: [PATCH 02/37] mm, frame_vector: do not use  get_user_pages_locked() Andrea Arcangeli <aarcange@redhat.com> - 2015-11-18 18:10 +0100

#1270824 — [PATCH 02/37] mm, frame_vector: do not use get_user_pages_locked()

FromDave Hansen <dave@sr71.net>
Date2015-11-17 04:50 +0100
Subject[PATCH 02/37] mm, frame_vector: do not use get_user_pages_locked()
Message-ID<qvFrj-82I-11@gated-at.bofh.it>
From: Dave Hansen <dave.hansen@linux.intel.com>

get_user_pages_locked() appears to be for use when a caller needs
to know that its lock on mmap_sem was invalidated by the gup
call.

But, get_vaddr_frames() is not one of those users.  It
unconditionally locks the mmap_sem and unconditionally unlocks it
after the gup call.  It takes no special action and does not need
to know whether its lock was invalidated or not.

Replace get_user_pages_locked() with a vanilla get_user_pages()
and save a few lines of code.

Note that this was the *ONLY* use of get_user_pages_locked() in
the entire kernel tree.

Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
Cc: Jan Kara <jack@suse.cz>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Andrea Arcangeli <aarcange@redhat.com>
---

 b/mm/frame_vector.c |    9 +++------
 1 file changed, 3 insertions(+), 6 deletions(-)

diff -puN mm/frame_vector.c~remove-get_user_pages_locked-user mm/frame_vector.c
--- a/mm/frame_vector.c~remove-get_user_pages_locked-user	2015-11-16 12:35:35.282169293 -0800
+++ b/mm/frame_vector.c	2015-11-16 12:35:35.285169429 -0800
@@ -40,7 +40,6 @@ int get_vaddr_frames(unsigned long start
 	struct vm_area_struct *vma;
 	int ret = 0;
 	int err;
-	int locked;
 
 	if (nr_frames == 0)
 		return 0;
@@ -49,7 +48,6 @@ int get_vaddr_frames(unsigned long start
 		nr_frames = vec->nr_allocated;
 
 	down_read(&mm->mmap_sem);
-	locked = 1;
 	vma = find_vma_intersection(mm, start, start + 1);
 	if (!vma) {
 		ret = -EFAULT;
@@ -58,8 +56,8 @@ int get_vaddr_frames(unsigned long start
 	if (!(vma->vm_flags & (VM_IO | VM_PFNMAP))) {
 		vec->got_ref = true;
 		vec->is_pfns = false;
-		ret = get_user_pages_locked(current, mm, start, nr_frames,
-			write, force, (struct page **)(vec->ptrs), &locked);
+		ret = get_user_pages(current, mm, start, nr_frames,
+			write, force, (struct page **)(vec->ptrs), NULL);
 		goto out;
 	}
 
@@ -87,8 +85,7 @@ int get_vaddr_frames(unsigned long start
 		vma = find_vma_intersection(mm, start, start + 1);
 	} while (vma && vma->vm_flags & (VM_IO | VM_PFNMAP));
 out:
-	if (locked)
-		up_read(&mm->mmap_sem);
+	up_read(&mm->mmap_sem);
 	if (!ret)
 		ret = -EFAULT;
 	if (ret > 0)
_
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]


#1272122 — Re: [PATCH 02/37] mm, frame_vector: do not use get_user_pages_locked()

FromJan Kara <jack@suse.cz>
Date2015-11-18 13:30 +0100
SubjectRe: [PATCH 02/37] mm, frame_vector: do not use get_user_pages_locked()
Message-ID<qwa27-2NS-21@gated-at.bofh.it>
In reply to#1270824
On Mon 16-11-15 19:35:14, Dave Hansen wrote:
> 
> From: Dave Hansen <dave.hansen@linux.intel.com>
> 
> get_user_pages_locked() appears to be for use when a caller needs
> to know that its lock on mmap_sem was invalidated by the gup
> call.
> 
> But, get_vaddr_frames() is not one of those users.  It
> unconditionally locks the mmap_sem and unconditionally unlocks it
> after the gup call.  It takes no special action and does not need
> to know whether its lock was invalidated or not.
> 
> Replace get_user_pages_locked() with a vanilla get_user_pages()
> and save a few lines of code.
> 
> Note that this was the *ONLY* use of get_user_pages_locked() in
> the entire kernel tree.

I've used get_user_pages_locked() because of a comment before that function
saying:

 * We can leverage the VM_FAULT_RETRY functionality in the page fault
 * paths better by using either get_user_pages_locked() or
 * get_user_pages_unlocked().
 *
 * get_user_pages_locked() is suitable to replace the form:
 *
 *      down_read(&mm->mmap_sem);
 *      do_something()
 *      get_user_pages(tsk, mm, ..., pages, NULL);
 *      up_read(&mm->mmap_sem);
 *
 *  to:
 *
 *      int locked = 1;
 *      down_read(&mm->mmap_sem);
 *      do_something()
 *      get_user_pages_locked(tsk, mm, ..., pages, &locked);
 *      if (locked)
 *          up_read(&mm->mmap_sem);

So I understood it as a way to reduce mmap_sem hold time by doing a try
first. Did I understand that comment wrong?

								Honza

> Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
> Cc: Jan Kara <jack@suse.cz>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Cc: Andrea Arcangeli <aarcange@redhat.com>
> ---
> 
>  b/mm/frame_vector.c |    9 +++------
>  1 file changed, 3 insertions(+), 6 deletions(-)
> 
> diff -puN mm/frame_vector.c~remove-get_user_pages_locked-user mm/frame_vector.c
> --- a/mm/frame_vector.c~remove-get_user_pages_locked-user	2015-11-16 12:35:35.282169293 -0800
> +++ b/mm/frame_vector.c	2015-11-16 12:35:35.285169429 -0800
> @@ -40,7 +40,6 @@ int get_vaddr_frames(unsigned long start
>  	struct vm_area_struct *vma;
>  	int ret = 0;
>  	int err;
> -	int locked;
>  
>  	if (nr_frames == 0)
>  		return 0;
> @@ -49,7 +48,6 @@ int get_vaddr_frames(unsigned long start
>  		nr_frames = vec->nr_allocated;
>  
>  	down_read(&mm->mmap_sem);
> -	locked = 1;
>  	vma = find_vma_intersection(mm, start, start + 1);
>  	if (!vma) {
>  		ret = -EFAULT;
> @@ -58,8 +56,8 @@ int get_vaddr_frames(unsigned long start
>  	if (!(vma->vm_flags & (VM_IO | VM_PFNMAP))) {
>  		vec->got_ref = true;
>  		vec->is_pfns = false;
> -		ret = get_user_pages_locked(current, mm, start, nr_frames,
> -			write, force, (struct page **)(vec->ptrs), &locked);
> +		ret = get_user_pages(current, mm, start, nr_frames,
> +			write, force, (struct page **)(vec->ptrs), NULL);
>  		goto out;
>  	}
>  
> @@ -87,8 +85,7 @@ int get_vaddr_frames(unsigned long start
>  		vma = find_vma_intersection(mm, start, start + 1);
>  	} while (vma && vma->vm_flags & (VM_IO | VM_PFNMAP));
>  out:
> -	if (locked)
> -		up_read(&mm->mmap_sem);
> +	up_read(&mm->mmap_sem);
>  	if (!ret)
>  		ret = -EFAULT;
>  	if (ret > 0)
> _
-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]


#1272394 — Re: [PATCH 02/37] mm, frame_vector: do not use get_user_pages_locked()

FromAndrea Arcangeli <aarcange@redhat.com>
Date2015-11-18 18:10 +0100
SubjectRe: [PATCH 02/37] mm, frame_vector: do not use get_user_pages_locked()
Message-ID<qwep5-5SC-29@gated-at.bofh.it>
In reply to#1272122
On Wed, Nov 18, 2015 at 01:29:38PM +0100, Jan Kara wrote:
> On Mon 16-11-15 19:35:14, Dave Hansen wrote:
> > 
> > From: Dave Hansen <dave.hansen@linux.intel.com>
> > 
> > get_user_pages_locked() appears to be for use when a caller needs
> > to know that its lock on mmap_sem was invalidated by the gup
> > call.
> > 
> > But, get_vaddr_frames() is not one of those users.  It
> > unconditionally locks the mmap_sem and unconditionally unlocks it
> > after the gup call.  It takes no special action and does not need
> > to know whether its lock was invalidated or not.
> > 
> > Replace get_user_pages_locked() with a vanilla get_user_pages()
> > and save a few lines of code.
> > 
> > Note that this was the *ONLY* use of get_user_pages_locked() in
> > the entire kernel tree.
> 
> I've used get_user_pages_locked() because of a comment before that function
> saying:
> 
>  * We can leverage the VM_FAULT_RETRY functionality in the page fault
>  * paths better by using either get_user_pages_locked() or
>  * get_user_pages_unlocked().
>  *
>  * get_user_pages_locked() is suitable to replace the form:
>  *
>  *      down_read(&mm->mmap_sem);
>  *      do_something()
>  *      get_user_pages(tsk, mm, ..., pages, NULL);
>  *      up_read(&mm->mmap_sem);
>  *
>  *  to:
>  *
>  *      int locked = 1;
>  *      down_read(&mm->mmap_sem);
>  *      do_something()
>  *      get_user_pages_locked(tsk, mm, ..., pages, &locked);
>  *      if (locked)
>  *          up_read(&mm->mmap_sem);
> 
> So I understood it as a way to reduce mmap_sem hold time by doing a try
> first. Did I understand that comment wrong?

That is correct. get_user_pages_locked should not be downgraded to
get_user_pages or it can actually break userfaultfd, as userfaultfd
needs to be allowed to drop the mmap_sem within handle_mm_fault, to
function correctly. Furthermore get_user_pages_locked allows for
higher SMP scalability as it can take advantage of the optimized
pagecache code that drops the mmap_sem before waiting for I/O (and
then it retries the page fault after the I/O is complete).

The only case where get_user_pages without FOLL_FAULT_ALLOW_RETRY
makes any sense is the get_dump_page case which is actually not using
get_user_pages in the first place, so ideally get_user_pages should be
obsoleted and dropped.

Thanks,
Andrea
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]


Back to top | Article view | linux.kernel


csiph-web