* Josh Poimboeuf <jpoim...@redhat.com> wrote: > I haven't actually seen any real-world bugs caused by this, so I'm not > sure how theoretical it is. I just stumbled upon it in code review when > looking for another bug.
I believe it's a real bug, but the fix is wrong with irq tracing or lockdep enabled as Dave points out. I think the reason we haven't seen this bug yet is that "paranoid" entry points are limited to: idtentry double_fault do_double_fault has_error_code=1 paranoid=2 idtentry debug do_debug has_error_code=0 paranoid=1 shift_ist=DEBUG_STACK idtentry int3 do_int3 has_error_code=0 paranoid=1 shift_ist=DEBUG_STACK idtentry machine_check do_mce has_error_code=0 paranoid=1 Only machine_check is one that will interrupt an IRQS-off critical section asynchronously - and machine check events are rare. The other main asynchronous entries are NMI entries, which can be very high-freq with perf profiling, but they are special: they don't use the 'idtentry' macro but are open coded and restore user CR3 unconditionally so don't seem to have this bug. Thanks, Ingo