On 23.09.2024 12:14, Alejandro Vallejo wrote: > On Fri Sep 20, 2024 at 3:12 PM BST, Roger Pau Monné wrote: >> On Wed, Sep 18, 2024 at 02:05:54PM +0100, Alejandro Vallejo wrote: >>> Moves sti directly after the cr2 read and immediately after the #PF >>> handler. >> >> I think you need to add some context about why this is needed, iow: >> avoid corrupting %cr2 if a nested 3PF happens. > > I can send a v3 with: > > ``` > Hitting a page fault clobbers %cr2, so if a page fault is handled while > handling a previous page fault then %cr2 will hold the address of the latter > fault rather than the former. This patch makes the page fault path delay > re-enabling IRQs until %cr2 has been read in order to ensure it stays > consistent.
And under what conditions would we experience #PF while already processing an earlier #PF? If an interrupt kicks in, that's not supposed to by raising any #PF itself. Which isn't to say that the change isn't worthwhile to make, but it would be nice if it was explicit whether there are active issues, or whether this is merely to be on the safe side going forward. > Furthermore, the patch preserves the invariant of "IRQs are only re-enabled > if they were enabled in the interrupted context" in order to not break > IRQs-off faulting contexts. This last part is just stating the obvious then, in that you're not breaking existing behavior? Seems a little odd to have in this form then. Jan
