On Tue, 12 Dec 2017, Peter Zijlstra wrote: > On Tue, Dec 12, 2017 at 10:22:48AM -0800, Andy Lutomirski wrote: > > > > Also, why is LAR deferred to user exit? And I thought that LAR didn't > > set the accessed bit. > > LAR does not set the ACCESSED bit indeed, we need to explicitly set that > when creating the descriptor. > > It also works if you do the LAR right after LLDT (which is what I > originally had). The reason its a TIF flag is that I originally LAR'ed > every entry in the table. > > It got reduced to CS/SS, but the TIF thing stayed. > > > If I had to guess, I'd guess that LAR is actually generating a read > > fault and forcing the pagetables to get populated. If so, then it > > means the VMA code isn't quite right, or you're susceptible to > > failures under memory pressure. > > > > Now maybe LAR will repopulate the PTE every time if you were to never > > clear it, but ick. > > I did not observe #PFs from LAR, we had a giant pile of trace_printk() > in there. The pages are populated _before_ the new ldt is installed. So no memory pressure issue, nothing. If the populate fails, then modify_ldt() returns with an error. Thanks, tglx -- 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>
