On Thu, Oct 19, 2017 at 10:08:57AM +1100, Balbir Singh wrote:

On Wed, 18 Oct 2017 14:29:24 -0700
Ram Pai [off-list ref] wrote:

quoted

On Thu, Oct 19, 2017 at 06:57:32AM +1100, Balbir Singh wrote:

quoted

On Fri,  8 Sep 2017 15:45:06 -0700
Ram Pai [off-list ref] wrote:
  

quoted

Make sure that the kernel does not access user pages without
checking their key-protection.
 

Why? This makes the routines AMR/thread specific? Looks like
x86 does this as well  

Yes. the memkey semantics implemented by x86, assumes that the keys and
their access-permission are per thread.  In other words, a key which is
enabled in the context of one thread, will not be enabled in the context
of another thread.

quoted

but these routines are used by GUP from
the kernel.  

See a problem?

No, I don't understand why gup (called from driver context, probably) should
worry about permissions and keys?

There are some user level features; eg: pipe,  where the userspace
donates one of its pages to the kernel, to buffer the pipe stream.

But if the donated page has a non-permissive key associated, the
kernel should reject and return failure. Access to a page
associated with a non-permissive key should fail regardless of who
accesses the page (userspace, or kernel on userspace's behalf).

That is the reason we tap into the GUP routines to validate such
access.

RP