On Thu, Oct 19, 2017 at 10:08:57AM +1100, Balbir Singh wrote: > On Wed, 18 Oct 2017 14:29:24 -0700 > Ram Pai <linux...@us.ibm.com> wrote: > > > On Thu, Oct 19, 2017 at 06:57:32AM +1100, Balbir Singh wrote: > > > On Fri, 8 Sep 2017 15:45:06 -0700 > > > Ram Pai <linux...@us.ibm.com> wrote: > > > > > > > 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. > > > > > 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
