linux-kernel - Re: [PATCH] smp/call: Detect stuck CSD locks

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 11 May 2015 16:00:03 +0200
From:	Ingo Molnar <mingo@...nel.org>
To:	Chris J Arges <chris.j.arges@...onical.com>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Rafael David Tinoco <inaddy@...ntu.com>,
	Peter Anvin <hpa@...or.com>,
	Jiang Liu <jiang.liu@...ux.intel.com>,
	Peter Zijlstra <peterz@...radead.org>,
	LKML <linux-kernel@...r.kernel.org>,
	Jens Axboe <axboe@...nel.dk>,
	Frederic Weisbecker <fweisbec@...il.com>,
	Gema Gomez <gema.gomez-solano@...onical.com>,
	the arch/x86 maintainers <x86@...nel.org>
Subject: Re: [PATCH] smp/call: Detect stuck CSD locks


* Chris J Arges <chris.j.arges@...onical.com> wrote:

> Later in the trace we see the same call followed by 
> vmx_handle_external_intr() ignoring the call:
> 
> [  603.248016]  2452.083823 |   0)               |    ptep_clear_flush() {
> [  603.248016]  2452.083824 |   0)               |      flush_tlb_page() {
> [  603.248016]  2452.083824 |   0)   0.109 us    |        leave_mm();
> [  603.248016]  2452.083824 |   0)               |        native_flush_tlb_others() {
> [  603.248016]  2452.083824 |   0)               |          smp_call_function_many() {
> [  603.248016]  2452.083825 |   0)               |            smp_call_function_single() {
> [  603.248016]  2452.083825 |   0)               |              generic_exec_single() {
> [  603.248016]  2452.083825 |   0)               |                native_send_call_func_single_ipi() {
> [  603.248016]  2452.083825 |   0)               |                  x2apic_send_IPI_mask() {
> [  603.248016]  2452.083826 |   0)   1.625 us    |                    __x2apic_send_IPI_mask();
> [  603.248016]  2452.083828 |   0)   2.173 us    |                  }
> [  603.248016]  2452.083828 |   0)   2.588 us    |                }
> [  603.248016]  2452.083828 |   0)   3.082 us    |              }
> [  603.248016]  2452.083828 |   0)               |              csd_lock_wait.isra.4() {
> [  603.248016]  2452.083848 |   1) + 44.033 us   |          }
> [  603.248016]  2452.083849 |   1)   0.975 us    |          vmx_read_l1_tsc();
> [  603.248016]  2452.083851 |   1)   1.031 us    |          vmx_handle_external_intr();
> [  603.248016]  2452.083852 |   1)   0.234 us    |          __srcu_read_lock();
> [  603.248016]  2452.083853 |   1)               |          vmx_handle_exit() {
> [  603.248016]  2452.083854 |   1)               |            handle_ept_violation() {
> [  603.248016]  2452.083856 |   1)               |              kvm_mmu_page_fault() {
> [  603.248016]  2452.083856 |   1)               |                tdp_page_fault() {
> [  603.248016]  2452.083856 |   1)   0.092 us    |                  mmu_topup_memory_caches();
> [  603.248016]  2452.083857 |   1)               |                  gfn_to_memslot_dirty_bitmap.isra.84() {
> [  603.248016]  2452.083857 |   1)   0.231 us    |                    gfn_to_memslot();
> [  603.248016]  2452.083858 |   1)   0.774 us    |                  }
> 
> So potentially, CPU0 generated an interrupt that caused 
> vcpu_enter_guest to be called on CPU1. However, when 
> vmx_handle_external_intr was called, it didn't progress any further.

So the IPI does look like to be lost in the KVM code?

So why did vmx_handle_external_intr() skip the irq injection - were 
IRQs disabled in the guest perhaps?

> Another experiment here would be to dump 
> vmcs_read32(VM_EXIT_INTR_INFO); to see why we don't handle the 
> interrupt.

Possibly, but also to instrument the KVM IRQ injection code to see 
when it skips an IPI and why.

Thanks,

	Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/