* 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        

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 
with perf profiling, but they are special: they don't use the 'idtentry' macro 
are open coded and restore user CR3 unconditionally so don't seem to have this 



Reply via email to