linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: mhocko@kernel.org (Michal Hocko)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 00/10] mm: adjust get_user_pages* functions to explicitly pass FOLL_* flags
Date: Wed, 19 Oct 2016 19:01:27 +0200	[thread overview]
Message-ID: <20161019170127.GN24393@dhcp22.suse.cz> (raw)
In-Reply-To: <5807A427.7010200@linux.intel.com>

On Wed 19-10-16 09:49:43, Dave Hansen wrote:
> On 10/19/2016 02:07 AM, Michal Hocko wrote:
> > On Wed 19-10-16 09:58:15, Lorenzo Stoakes wrote:
> >> On Tue, Oct 18, 2016 at 05:30:50PM +0200, Michal Hocko wrote:
> >>> I am wondering whether we can go further. E.g. it is not really clear to
> >>> me whether we need an explicit FOLL_REMOTE when we can in fact check
> >>> mm != current->mm and imply that. Maybe there are some contexts which
> >>> wouldn't work, I haven't checked.
> >>
> >> This flag is set even when /proc/self/mem is used. I've not looked deeply into
> >> this flag but perhaps accessing your own memory this way can be considered
> >> 'remote' since you're not accessing it directly. On the other hand, perhaps this
> >> is just mistaken in this case?
> > 
> > My understanding of the flag is quite limited as well. All I know it is
> > related to protection keys and it is needed to bypass protection check.
> > See arch_vma_access_permitted. See also 1b2ee1266ea6 ("mm/core: Do not
> > enforce PKEY permissions on remote mm access").
> 
> Yeah, we need the flag to tell us when PKEYs should be applied or not.
> The current task's PKRU (pkey rights register) should really only be
> used to impact access to the task's memory, but has no bearing on how a
> given task should access remote memory.

The question I had earlier was whether this has to be an explicit FOLL
flag used by g-u-p users or we can just use it internally when mm !=
current->mm

-- 
Michal Hocko
SUSE Labs

  reply	other threads:[~2016-10-19 17:01 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-10-13  0:20 [PATCH 00/10] mm: adjust get_user_pages* functions to explicitly pass FOLL_* flags Lorenzo Stoakes
2016-10-13  0:20 ` [PATCH 01/10] mm: remove write/force parameters from __get_user_pages_locked() Lorenzo Stoakes
2016-10-18 12:43   ` Jan Kara
2016-10-13  0:20 ` [PATCH 02/10] mm: remove write/force parameters from __get_user_pages_unlocked() Lorenzo Stoakes
2016-10-13  6:54   ` Paolo Bonzini
2016-10-18 12:46   ` Jan Kara
2016-10-13  0:20 ` [PATCH 03/10] mm: replace get_user_pages_unlocked() write/force parameters with gup_flags Lorenzo Stoakes
2016-10-18 12:50   ` Jan Kara
2016-10-13  0:20 ` [PATCH 04/10] mm: replace get_user_pages_locked() " Lorenzo Stoakes
2016-10-18 12:54   ` Jan Kara
2016-10-18 13:56     ` Lorenzo Stoakes
2016-10-19  7:32       ` Jan Kara
2016-10-19  7:33   ` Jan Kara
2016-10-13  0:20 ` [PATCH 05/10] mm: replace get_vaddr_frames() " Lorenzo Stoakes
2016-10-19  7:34   ` Jan Kara
2016-10-13  0:20 ` [PATCH 06/10] mm: replace get_user_pages() " Lorenzo Stoakes
2016-10-17  9:22   ` Jesper Nilsson
2016-10-19  7:44   ` Jan Kara
2016-10-13  0:20 ` [PATCH 07/10] mm: replace get_user_pages_remote() " Lorenzo Stoakes
2016-10-19  7:47   ` Jan Kara
2016-10-13  0:20 ` [PATCH 08/10] mm: replace __access_remote_vm() write parameter " Lorenzo Stoakes
2016-10-19  7:59   ` Jan Kara
2016-10-19  8:13     ` Michal Hocko
2016-10-19  8:40       ` Lorenzo Stoakes
2016-10-19  8:52         ` Michal Hocko
2016-10-19  9:06           ` Lorenzo Stoakes
2016-10-19  9:23             ` Michal Hocko
2016-10-13  0:20 ` [PATCH 09/10] mm: replace access_remote_vm() " Lorenzo Stoakes
2016-10-13  0:20 ` [PATCH 10/10] mm: replace access_process_vm() " Lorenzo Stoakes
2016-10-17  9:23   ` Jesper Nilsson
2016-10-13  7:32 ` [PATCH 00/10] mm: adjust get_user_pages* functions to explicitly pass FOLL_* flags Christian König
2016-10-18 15:30 ` Michal Hocko
2016-10-19  8:58   ` Lorenzo Stoakes
2016-10-19  9:07     ` Michal Hocko
2016-10-19 16:49       ` Dave Hansen
2016-10-19 17:01         ` Michal Hocko [this message]
2016-10-19 17:23           ` Dave Hansen
2016-10-20 19:26             ` Michal Hocko

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=20161019170127.GN24393@dhcp22.suse.cz \
    --to=mhocko@kernel.org \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).