Re: [PATCH v2] x86/msr: Add write msr notrace to avoid the debug codes splash

[Ingo Molnar <mingo@kernel.org>]

* Wanpeng Li <kernellwp@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 <peterz@infradead.org>
> Suggested-by: Paolo Bonzini <pbonzini@redhat.com>
> Cc: Ingo Molnar <mingo@kernel.org>
> Cc: Mike Galbraith <efault@gmx.de>
> Cc: Peter Zijlstra <peterz@infradead.org>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: Paolo Bonzini <pbonzini@redhat.com>
> Signed-off-by: Wanpeng Li <wanpeng.li@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.

Thanks,

	Ingo