All of lore.kernel.org
 help / color / mirror / Atom feed
From: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
To: Dave Hansen <dave@sr71.net>
Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org, x86@kernel.org,
	dave.hansen@linux.intel.com, akpm@linux-foundation.org,
	kirill.shutemov@linux.intel.com, aarcange@redhat.com,
	n-horiguchi@ah.jp.nec.com, vbabka@suse.cz, jack@suse.cz,
	Oleg Nesterov <oleg@redhat.com>
Subject: Re: [PATCH] mm, gup: introduce concept of "foreign" get_user_pages()
Date: Mon, 25 Jan 2016 18:47:24 +0530	[thread overview]
Message-ID: <20160125131723.GB17206@linux.vnet.ibm.com> (raw)
In-Reply-To: <20160122180219.164259F1@viggo.jf.intel.com>

> 
> One of Vlastimil's comments made me go dig back in to the uprobes
> code's use of get_user_pages().  I decided to change both of them
> to be "foreign" accesses.
> 
> This also fixes the nommu breakage that Vlastimil noted last time.
> 
> Srikar, I'd appreciate if you can have a look at the uprobes.c
> modifications, especially the comment.  I don't think this will
> change any behavior, but I want to make sure the comment is
> accurate.
> 
> ---
> 
> From: Dave Hansen <dave.hansen@linux.intel.com>
> 
> For protection keys, we need to understand whether protections
> should be enforced in software or not.  In general, we enforce
> protections when working on our own task, but not when on others.
> We call these "current" and "foreign" operations.
> 
> This patch introduces a new get_user_pages() variant:
> 
> 	get_user_pages_foreign()
> 
> We modify the vanilla get_user_pages() so it can no longer be
> used on mm/tasks other than 'current/current->mm', which is by
> far the most common way it is called.  Using it makes a few of
> the call sites look a bit nicer.
> 
> In other words, get_user_pages_foreign() is a replacement for
> when get_user_pages() is called on non-current tsk/mm.
> 
> This also switches get_user_pages_(un)locked() over to be like
> get_user_pages() and not take a tsk/mm.  There is no
> get_user_pages_foreign_(un)locked().  If someone wants that
> behavior they just have to use "__" variant and pass in
> FOLL_FOREIGN explicitly.
> 
> The uprobes is_trap_at_addr() location holds mmap_sem and
> calls get_user_pages(current->mm) on an instruction address.  This
> makes it a pretty unique gup caller.  Being an instruction access
> and also really originating from the kernel (vs. the app), I opted
> to consider this a 'foreign' access where protection keys will not
> be enforced.
> 

Changes for uprobes.c looks good to me.
Acked-by: Srikar Dronamraju <srikar@linux.vnet.ibm.com>

> Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Cc: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
> Cc: Andrea Arcangeli <aarcange@redhat.com>
> Cc: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
> Cc: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
> Cc: vbabka@suse.cz
> Cc: jack@suse.cz

> diff -puN kernel/events/uprobes.c~get_current_user_pages kernel/events/uprobes.c
> --- a/kernel/events/uprobes.c~get_current_user_pages	2016-01-22 08:43:42.602473969 -0800
> +++ b/kernel/events/uprobes.c	2016-01-22 09:36:14.203845894 -0800
> @@ -299,7 +299,7 @@ int uprobe_write_opcode(struct mm_struct
> 
>  retry:
>  	/* Read the page with vaddr into memory */
> -	ret = get_user_pages(NULL, mm, vaddr, 1, 0, 1, &old_page, &vma);
> +	ret = get_user_pages_foreign(NULL, mm, vaddr, 1, 0, 1, &old_page, &vma);
>  	if (ret <= 0)
>  		return ret;
> 
> @@ -1700,7 +1700,13 @@ static int is_trap_at_addr(struct mm_str
>  	if (likely(result == 0))
>  		goto out;
> 
> -	result = get_user_pages(NULL, mm, vaddr, 1, 0, 1, &page, NULL);
> +	/*
> +	 * The NULL 'tsk' here ensures that any faults that occur here
> +	 * will not be accounted to the task.  'mm' *is* current->mm,
> +	 * but we treat this as a 'foreign' access since it is
> +	 * essentially a kernel access to the memory.
> +	 */
> +	result = get_user_pages_foreign(NULL, mm, vaddr, 1, 0, 1, &page, NULL);
>  	if (result < 0)
>  		return result;
> 

-- 
Thanks and Regards
Srikar Dronamraju

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

WARNING: multiple messages have this Message-ID (diff)
From: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
To: Dave Hansen <dave@sr71.net>
Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org, x86@kernel.org,
	dave.hansen@linux.intel.com, akpm@linux-foundation.org,
	kirill.shutemov@linux.intel.com, aarcange@redhat.com,
	n-horiguchi@ah.jp.nec.com, vbabka@suse.cz, jack@suse.cz,
	Oleg Nesterov <oleg@redhat.com>
Subject: Re: [PATCH] mm, gup: introduce concept of "foreign" get_user_pages()
Date: Mon, 25 Jan 2016 18:47:24 +0530	[thread overview]
Message-ID: <20160125131723.GB17206@linux.vnet.ibm.com> (raw)
In-Reply-To: <20160122180219.164259F1@viggo.jf.intel.com>

> 
> One of Vlastimil's comments made me go dig back in to the uprobes
> code's use of get_user_pages().  I decided to change both of them
> to be "foreign" accesses.
> 
> This also fixes the nommu breakage that Vlastimil noted last time.
> 
> Srikar, I'd appreciate if you can have a look at the uprobes.c
> modifications, especially the comment.  I don't think this will
> change any behavior, but I want to make sure the comment is
> accurate.
> 
> ---
> 
> From: Dave Hansen <dave.hansen@linux.intel.com>
> 
> For protection keys, we need to understand whether protections
> should be enforced in software or not.  In general, we enforce
> protections when working on our own task, but not when on others.
> We call these "current" and "foreign" operations.
> 
> This patch introduces a new get_user_pages() variant:
> 
> 	get_user_pages_foreign()
> 
> We modify the vanilla get_user_pages() so it can no longer be
> used on mm/tasks other than 'current/current->mm', which is by
> far the most common way it is called.  Using it makes a few of
> the call sites look a bit nicer.
> 
> In other words, get_user_pages_foreign() is a replacement for
> when get_user_pages() is called on non-current tsk/mm.
> 
> This also switches get_user_pages_(un)locked() over to be like
> get_user_pages() and not take a tsk/mm.  There is no
> get_user_pages_foreign_(un)locked().  If someone wants that
> behavior they just have to use "__" variant and pass in
> FOLL_FOREIGN explicitly.
> 
> The uprobes is_trap_at_addr() location holds mmap_sem and
> calls get_user_pages(current->mm) on an instruction address.  This
> makes it a pretty unique gup caller.  Being an instruction access
> and also really originating from the kernel (vs. the app), I opted
> to consider this a 'foreign' access where protection keys will not
> be enforced.
> 

Changes for uprobes.c looks good to me.
Acked-by: Srikar Dronamraju <srikar@linux.vnet.ibm.com>

> Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Cc: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
> Cc: Andrea Arcangeli <aarcange@redhat.com>
> Cc: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
> Cc: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
> Cc: vbabka@suse.cz
> Cc: jack@suse.cz

> diff -puN kernel/events/uprobes.c~get_current_user_pages kernel/events/uprobes.c
> --- a/kernel/events/uprobes.c~get_current_user_pages	2016-01-22 08:43:42.602473969 -0800
> +++ b/kernel/events/uprobes.c	2016-01-22 09:36:14.203845894 -0800
> @@ -299,7 +299,7 @@ int uprobe_write_opcode(struct mm_struct
> 
>  retry:
>  	/* Read the page with vaddr into memory */
> -	ret = get_user_pages(NULL, mm, vaddr, 1, 0, 1, &old_page, &vma);
> +	ret = get_user_pages_foreign(NULL, mm, vaddr, 1, 0, 1, &old_page, &vma);
>  	if (ret <= 0)
>  		return ret;
> 
> @@ -1700,7 +1700,13 @@ static int is_trap_at_addr(struct mm_str
>  	if (likely(result == 0))
>  		goto out;
> 
> -	result = get_user_pages(NULL, mm, vaddr, 1, 0, 1, &page, NULL);
> +	/*
> +	 * The NULL 'tsk' here ensures that any faults that occur here
> +	 * will not be accounted to the task.  'mm' *is* current->mm,
> +	 * but we treat this as a 'foreign' access since it is
> +	 * essentially a kernel access to the memory.
> +	 */
> +	result = get_user_pages_foreign(NULL, mm, vaddr, 1, 0, 1, &page, NULL);
>  	if (result < 0)
>  		return result;
> 

-- 
Thanks and Regards
Srikar Dronamraju

  parent reply	other threads:[~2016-01-25 13:17 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-01-22 18:02 [PATCH] mm, gup: introduce concept of "foreign" get_user_pages() Dave Hansen
2016-01-22 18:02 ` Dave Hansen
2016-01-22 18:16 ` kbuild test robot
2016-01-22 18:16   ` kbuild test robot
2016-01-22 21:31   ` Dave Hansen
2016-01-22 21:31     ` Dave Hansen
2016-01-25 13:17 ` Srikar Dronamraju [this message]
2016-01-25 13:17   ` Srikar Dronamraju
2016-01-25 18:18   ` Oleg Nesterov
2016-01-25 18:18     ` Oleg Nesterov
2016-01-27 11:30 ` Vlastimil Babka
2016-01-27 11:30   ` Vlastimil Babka
2016-01-27 22:59   ` Dave Hansen
  -- strict thread matches above, loose matches on Subject: below --
2016-01-20 17:35 Dave Hansen
2016-01-20 17:35 ` Dave Hansen
2016-01-20 17:56 ` Vlastimil Babka
2016-01-20 17:56   ` Vlastimil Babka
2016-01-20 18:48   ` Dave Hansen
2016-01-20 18:48     ` Dave Hansen
2016-01-20 19:30 ` Vlastimil Babka
2016-01-20 19:30   ` Vlastimil Babka
2016-01-15 18:11 Dave Hansen
2016-01-15 18:11 ` Dave Hansen
2016-01-18 15:20 ` Vlastimil Babka
2016-01-18 15:20   ` Vlastimil Babka

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=20160125131723.GB17206@linux.vnet.ibm.com \
    --to=srikar@linux.vnet.ibm.com \
    --cc=aarcange@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=dave.hansen@linux.intel.com \
    --cc=dave@sr71.net \
    --cc=jack@suse.cz \
    --cc=kirill.shutemov@linux.intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=n-horiguchi@ah.jp.nec.com \
    --cc=oleg@redhat.com \
    --cc=vbabka@suse.cz \
    --cc=x86@kernel.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.