On 12/14/2017 12:54 PM, Peter Zijlstra wrote: >> That short-circuits the page fault pretty quickly. So, basically, the >> rule is: if the hardware says you tripped over pkey permissions, you >> die. We don't try to do anything to the underlying page *before* saying >> that you die. > That only works when you trip the fault from hardware. Not if you do a > software fault using gup(). > > AFAIK __get_user_pages(FOLL_FORCE|FOLL_WRITE|FOLL_GET) will loop > indefinitely on the case I described. So, the underlying bug here is that we now a get_user_pages_remote() and then go ahead and do the p*_access_permitted() checks against the current PKRU. This was introduced recently with the addition of the new p??_access_permitted() calls. We have checks in the VMA path for the "remote" gups and we avoid consulting PKRU for them. This got missed in the pkeys selftests because I did a ptrace read, but not a *write*. I also didn't explicitly test it against something where a COW needed to be done. I've got some additions to the selftests and a fix where we pass FOLL_* flags around a bit more instead of just 'write'. I'll get those out as soon as I do a bit more testing. -- 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>
