On 29.04.15 06:49, Paul Mackerras wrote: > This fixes a regression introduced in commit 25fedfca94cf, "KVM: PPC: > Book3S HV: Move vcore preemption point up into kvmppc_run_vcpu", which > leads to a user-triggerable oops. > > In the case where we try to run a vcore on a physical core that is > not in single-threaded mode, or the vcore has too many threads for > the physical core, we iterate the list of runnable vcpus to make > each one return an EBUSY error to userspace. Since this involves > taking each vcpu off the runnable_threads list for the vcore, we > need to use list_for_each_entry_safe rather than list_for_each_entry > to traverse the list. Otherwise the kernel will crash with an oops > message like this: > > Unable to handle kernel paging request for data at address 0x000fff88 > Faulting instruction address: 0xd00000001e635dc8 > Oops: Kernel access of bad area, sig: 11 [#2] > SMP NR_CPUS=1024 NUMA PowerNV > ... > CPU: 48 PID: 91256 Comm: qemu-system-ppc Tainted: G D 3.18.0 #1 > task: c00000274e507500 ti: c0000027d1924000 task.ti: c0000027d1924000 > NIP: d00000001e635dc8 LR: d00000001e635df8 CTR: c00000000011ba50 > REGS: c0000027d19275b0 TRAP: 0300 Tainted: G D (3.18.0) > MSR: 9000000000009033 <SF,HV,EE,ME,IR,DR,RI,LE> CR: 22002824 XER: 00000000 > CFAR: c000000000008468 DAR: 00000000000fff88 DSISR: 40000000 SOFTE: 1 > GPR00: d00000001e635df8 c0000027d1927830 d00000001e64c850 0000000000000001 > GPR04: 0000000000000001 0000000000000001 0000000000000000 0000000000000000 > GPR08: 0000000000200200 0000000000000000 0000000000000000 d00000001e63e588 > GPR12: 0000000000002200 c000000007dbc800 c000000fc7800000 000000000000000a > GPR16: fffffffffffffffc c000000fd5439690 c000000fc7801c98 0000000000000001 > GPR20: 0000000000000003 c0000027d1927aa8 c000000fd543b348 c000000fd543b350 > GPR24: 0000000000000000 c000000fa57f0000 0000000000000030 0000000000000000 > GPR28: fffffffffffffff0 c000000fd543b328 00000000000fe468 c000000fd543b300 > NIP [d00000001e635dc8] kvmppc_run_core+0x198/0x17c0 [kvm_hv] > LR [d00000001e635df8] kvmppc_run_core+0x1c8/0x17c0 [kvm_hv] > Call Trace: > [c0000027d1927830] [d00000001e635df8] kvmppc_run_core+0x1c8/0x17c0 [kvm_hv] (unreliable) > [c0000027d1927a30] [d00000001e638350] kvmppc_vcpu_run_hv+0x5b0/0xdd0 [kvm_hv] > [c0000027d1927b70] [d00000001e510504] kvmppc_vcpu_run+0x44/0x60 [kvm] > [c0000027d1927ba0] [d00000001e50d4a4] kvm_arch_vcpu_ioctl_run+0x64/0x170 [kvm] > [c0000027d1927be0] [d00000001e504be8] kvm_vcpu_ioctl+0x5e8/0x7a0 [kvm] > [c0000027d1927d40] [c0000000002d6720] do_vfs_ioctl+0x490/0x780 > [c0000027d1927de0] [c0000000002d6ae4] SyS_ioctl+0xd4/0xf0 > [c0000027d1927e30] [c000000000009358] syscall_exit+0x0/0x98 > Instruction dump: > 60000000 60420000 387e1b30 38800003 38a00001 38c00000 480087d9 e8410018 > ebde1c98 7fbdf040 3bdee368 419e0048 <813e1b20> 939e1b18 2f890001 409effcc > ---[ end trace 8cdf50251cca6680 ]--- > > Fixes: 25fedfca94cf > Signed-off-by: Paul Mackerras <paulus@xxxxxxxxx> Reviewed-by: Alexander Graf <agraf@xxxxxxx> Paolo, can you please take this patch into 4.1 directly? Thanks a lot, Alex -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
