mirror of
https://github.com/AuxXxilium/linux_dsm_epyc7002.git
synced 2024-12-26 07:45:12 +07:00
bf3d32e115
Lockdep reported that there is a potential for deadlock because vcpu->arch.tbacct_lock is not irq-safe, and is sometimes taken inside the rq_lock (run-queue lock) in the scheduler, which is taken within interrupts. The lockdep splat looks like: ====================================================== [ INFO: HARDIRQ-safe -> HARDIRQ-unsafe lock order detected ] 3.12.0-rc5-kvm+ #8 Not tainted ------------------------------------------------------ qemu-system-ppc/4803 [HC0[0]:SC0[0]:HE0:SE1] is trying to acquire: (&(&vcpu->arch.tbacct_lock)->rlock){+.+...}, at: [<c0000000000947ac>] .kvmppc_core_vcpu_put_hv+0x2c/0xa0 and this task is already holding: (&rq->lock){-.-.-.}, at: [<c000000000ac16c0>] .__schedule+0x180/0xaa0 which would create a new lock dependency: (&rq->lock){-.-.-.} -> (&(&vcpu->arch.tbacct_lock)->rlock){+.+...} but this new dependency connects a HARDIRQ-irq-safe lock: (&rq->lock){-.-.-.} ... which became HARDIRQ-irq-safe at: [<c00000000013797c>] .lock_acquire+0xbc/0x190 [<c000000000ac3c74>] ._raw_spin_lock+0x34/0x60 [<c0000000000f8564>] .scheduler_tick+0x54/0x180 [<c0000000000c2610>] .update_process_times+0x70/0xa0 [<c00000000012cdfc>] .tick_periodic+0x3c/0xe0 [<c00000000012cec8>] .tick_handle_periodic+0x28/0xb0 [<c00000000001ef40>] .timer_interrupt+0x120/0x2e0 [<c000000000002868>] decrementer_common+0x168/0x180 [<c0000000001c7ca4>] .get_page_from_freelist+0x924/0xc10 [<c0000000001c8e00>] .__alloc_pages_nodemask+0x200/0xba0 [<c0000000001c9eb8>] .alloc_pages_exact_nid+0x68/0x110 [<c000000000f4c3ec>] .page_cgroup_init+0x1e0/0x270 [<c000000000f24480>] .start_kernel+0x3e0/0x4e4 [<c000000000009d30>] .start_here_common+0x20/0x70 to a HARDIRQ-irq-unsafe lock: (&(&vcpu->arch.tbacct_lock)->rlock){+.+...} ... which became HARDIRQ-irq-unsafe at: ... [<c00000000013797c>] .lock_acquire+0xbc/0x190 [<c000000000ac3c74>] ._raw_spin_lock+0x34/0x60 [<c0000000000946ac>] .kvmppc_core_vcpu_load_hv+0x2c/0x100 [<c00000000008394c>] .kvmppc_core_vcpu_load+0x2c/0x40 [<c000000000081000>] .kvm_arch_vcpu_load+0x10/0x30 [<c00000000007afd4>] .vcpu_load+0x64/0xd0 [<c00000000007b0f8>] .kvm_vcpu_ioctl+0x68/0x730 [<c00000000025530c>] .do_vfs_ioctl+0x4dc/0x7a0 [<c000000000255694>] .SyS_ioctl+0xc4/0xe0 [<c000000000009ee4>] syscall_exit+0x0/0x98 Some users have reported this deadlock occurring in practice, though the reports have been primarily on 3.10.x-based kernels. This fixes the problem by making tbacct_lock be irq-safe. Signed-off-by: Paul Mackerras <paulus@samba.org> Signed-off-by: Alexander Graf <agraf@suse.de> |
||
|---|---|---|
| .. | ||
| 44x_emulate.c | ||
| 44x_tlb.c | ||
| 44x_tlb.h | ||
| 44x.c | ||
| book3s_32_mmu_host.c | ||
| book3s_32_mmu.c | ||
| book3s_32_sr.S | ||
| book3s_64_mmu_host.c | ||
| book3s_64_mmu_hv.c | ||
| book3s_64_mmu.c | ||
| book3s_64_slb.S | ||
| book3s_64_vio_hv.c | ||
| book3s_64_vio.c | ||
| book3s_emulate.c | ||
| book3s_exports.c | ||
| book3s_hv_builtin.c | ||
| book3s_hv_cma.c | ||
| book3s_hv_cma.h | ||
| book3s_hv_interrupts.S | ||
| book3s_hv_ras.c | ||
| book3s_hv_rm_mmu.c | ||
| book3s_hv_rm_xics.c | ||
| book3s_hv_rmhandlers.S | ||
| book3s_hv.c | ||
| book3s_interrupts.S | ||
| book3s_mmu_hpte.c | ||
| book3s_paired_singles.c | ||
| book3s_pr_papr.c | ||
| book3s_pr.c | ||
| book3s_rmhandlers.S | ||
| book3s_rtas.c | ||
| book3s_segment.S | ||
| book3s_xics.c | ||
| book3s_xics.h | ||
| book3s.c | ||
| book3s.h | ||
| booke_emulate.c | ||
| booke_interrupts.S | ||
| booke.c | ||
| booke.h | ||
| bookehv_interrupts.S | ||
| e500_emulate.c | ||
| e500_mmu_host.c | ||
| e500_mmu_host.h | ||
| e500_mmu.c | ||
| e500.c | ||
| e500.h | ||
| e500mc.c | ||
| emulate.c | ||
| fpu.S | ||
| irq.h | ||
| Kconfig | ||
| Makefile | ||
| mpic.c | ||
| powerpc.c | ||
| timing.c | ||
| timing.h | ||
| trace_booke.h | ||
| trace_pr.h | ||
| trace.h | ||