On 7/23/20 10:08 AM, Andy Lutomirski wrote: > Suppose some kernel code (a syscall or kernel thread) changes PKRS > then takes a page fault. The page fault handler needs a fresh PKRS. > Then the page fault handler (say a VMA’s .fault handler) changes > PKRS. The we get an interrupt. The interrupt *also* needs a fresh > PKRS and the page fault value needs to be saved somewhere. > > So we have more than one saved value per thread, and thread_struct > isn’t going to solve this problem. Taking a step back... This is all true only if we decide that we want protection keys to provide protection during exceptions and interrupts. Right now, the code supports nesting: kmap(foo); kmap(bar); kunmap(bar); kunmap(foo); with a reference count. So, the nested kmap() will see the count elevated and do nothing. I'm generally OK with this getting merged without extending PKS protection to interrupts and exceptions. Ira and Fenghua should certainly give it a go, but I'd like to see it as an add-on feature and we can judge the benefits versus complexity separately. Ira was looking at adding it because it _looked_ simple. Andy has me really scared about it now. :)
