On 10/22/2015 01:57 PM, Jerome Glisse wrote: > I have not read all the patches, but here i assume that for GUP you do > not first call arch_vma_access_permitted(). So issue i see is that GUP > for a process might happen inside another process and that process might > have different pkru protection keys, effectively randomly allowing or > forbidding a device driver to perform a GUP from say some workqueue that > just happen to be schedule against a different processor/thread than the > one against which it is doing the GUP for. There are some places where there is no real context from which we can determine access rights. ptrace is a good example. We don't enforce PKEYs when walking _another_ process's page tables. Can you give an example of where a process might be doing a gup and it is completely separate from the CPU context that it's being executed under? > Second and more fundamental thing i have issue with is that this whole > pkru keys are centric to CPU POV ie this is a CPU feature. So i do not > believe that device driver should be forbidden to do GUP base on pkru > keys. I don't think of it as something necessarily central to the CPU, but something central to things that walk page tables. We mark page tables with PKEYs and things that walk them will have certain rights. > Tying this to the pkru reg value of whatever processor happens to be > running some device driver kernel function that try to do a GUP seems > broken to me. That's one way to look at it. Another way is that PKRU is specifying some real _intent_ about whether we want access to be allowed to some memory. > So as first i would just allow GUP to always work and then come up with > syscall to allow to set pkey on device file. This obviously is a lot more > work as you need to go over all device driver using GUP. I wouldn't be opposed to adding some context to the thread (like pagefault_disable()) that indicates whether we should enforce protection keys. If we are in some asynchronous context, disassociated from the running CPU's protection keys, we could set a flag. I'd really appreciate if you could point to some concrete examples here which could actually cause a problem, like workqueues doing gups. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>