2016-10-18 17:24 GMT+08:00 Ingo Molnar <mi...@kernel.org>:
>
> * Wanpeng Li <kernel...@gmail.com> wrote:
>
>>  ===============================
>>  [ INFO: suspicious RCU usage. ]
>>  4.8.0+ #24 Not tainted
>>  -------------------------------
>>  ./arch/x86/include/asm/msr-trace.h:47 suspicious rcu_dereference_check() 
>> usage!
>>
>>  other info that might help us debug this:
>>
>>  RCU used illegally from idle CPU!
>>  rcu_scheduler_active = 1, debug_locks = 0
>>  RCU used illegally from extended quiescent state!
>>  no locks held by swapper/1/0.
>>
>>   [<ffffffff9d492b95>] do_trace_write_msr+0x135/0x140
>>   [<ffffffff9d06f860>] native_write_msr+0x20/0x30
>>   [<ffffffff9d065fad>] native_apic_msr_eoi_write+0x1d/0x30
>>   [<ffffffff9d05bd1d>] smp_reschedule_interrupt+0x1d/0x30
>>   [<ffffffff9d8daec6>] reschedule_interrupt+0x96/0xa0
>>
>> As Peterz pointed out:
>>
>> | The thing is, many many smp_reschedule_interrupt() invocations don't
>> | actually execute anything much at all and are only send to tickle the
>> | return to user path (which does the actual preemption).
>>
>> This patch add write msr notrace to avoid the debug codes splash.
>>
>> Suggested-by: Peter Zijlstra <pet...@infradead.org>
>> Suggested-by: Paolo Bonzini <pbonz...@redhat.com>
>> Cc: Ingo Molnar <mi...@kernel.org>
>> Cc: Mike Galbraith <efa...@gmx.de>
>> Cc: Peter Zijlstra <pet...@infradead.org>
>> Cc: Thomas Gleixner <t...@linutronix.de>
>> Cc: Paolo Bonzini <pbonz...@redhat.com>
>> Signed-off-by: Wanpeng Li <wanpeng...@hotmail.com>
>> ---
>> v1 -> v2:
>>  * add write msr notrace to avoid debug codes splash instead of slowdown a 
>> very frequent interrupt
>>
>>  arch/x86/include/asm/apic.h |  4 ++--
>>  arch/x86/include/asm/msr.h  | 15 +++++++++++++++
>>  arch/x86/kernel/kvm.c       |  2 +-
>>  3 files changed, 18 insertions(+), 3 deletions(-)
>
> Could you please do this on top of -tip and also include the revert of:
>
>                         #  1ec6ec14a294 x86/smp: Add irq_enter/exit() in 
> smp_reschedule_interrupt()
>
> in your v3 patch, because I'd rather avoid rebasing x86/urgent.

It seems that v2 still doesn't handle paravirt part correctly, I will
revert 1ec6ec14a294 in v3 when I figure it out.

Regards,
Wanpeng Li

Reply via email to