On Wed, Jul 03, 2019 at 04:47:01PM -0400, Steven Rostedt wrote: > On Wed, 3 Jul 2019 13:27:09 -0700 > Andy Lutomirski <l...@kernel.org> wrote: > > > > > @@ -1180,10 +1189,10 @@ idtentry xenint3 do_int3 > > > has_error_co > > > #endif > > > > > > idtentry general_protection do_general_protection has_error_code=1 > > > -idtentry page_fault do_page_fault has_error_code=1 > > > +idtentry page_fault do_page_fault has_error_code=1 > > > read_cr2=1 > > > > > > #ifdef CONFIG_KVM_GUEST > > > -idtentry async_page_fault do_async_page_fault has_error_code=1 > > > +idtentry async_page_fault do_async_page_fault has_error_code=1 > > > read_cr2=1 > > > #endif > > > > > > #ifdef CONFIG_X86_MCE > > > @@ -1338,18 +1347,9 @@ ENTRY(error_entry) > > > movq %rax, %rsp /* switch stack */ > > > ENCODE_FRAME_POINTER > > > pushq %r12 > > > - > > > - /* > > > - * We need to tell lockdep that IRQs are off. We can't do this > > > until > > > - * we fix gsbase, and we should do it before enter_from_user_mode > > > - * (which can take locks). > > > - */ > > > - TRACE_IRQS_OFF > > > > This hunk looks wrong. Am I missing some other place that handles the > > case where we enter from kernel mode and IRQs were on? > > Yeah, looks like we might be missing a TRACE_IRQS_OFF from the > from_usermode_stack_switch path.
Oh bugger, there's a second error_entry call.
