From mboxrd@z Thu Jan 1 00:00:00 1970 From: Lai Jiangshan Subject: [BUG] kvm: dereference srcu-protected pointer without srcu_read_lock() held Date: Mon, 19 Apr 2010 17:58:53 +0800 Message-ID: <4BCC295D.1040807@cn.fujitsu.com> References: <4BCC2543.7050104@cn.fujitsu.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit To: Avi Kivity , Marcelo Tosatti , "Paul E. McKenney" , LKML , kvm@vger.kernel.org Return-path: Received: from cn.fujitsu.com ([222.73.24.84]:62775 "EHLO song.cn.fujitsu.com" rhost-flags-OK-FAIL-OK-OK) by vger.kernel.org with ESMTP id S1753096Ab0DSJ7O (ORCPT ); Mon, 19 Apr 2010 05:59:14 -0400 In-Reply-To: <4BCC2543.7050104@cn.fujitsu.com> Sender: kvm-owner@vger.kernel.org List-ID: Applied the patch I just sent and let CONFIG_PROVE_RCU=y, we can got the following dmesg. And we found that it is because some codes in KVM dereferences srcu-protected pointer without srcu_read_lock() held or update-side lock held. It is not hard to fix, the problem is that: Where is the most proper place to put a srcu_read_lock()? I can not determine the answer, so I report this bug instead of fixing it. Thanks. Lai. Reported-by: Lai Jiangshan =================================================== [ INFO: suspicious rcu_dereference_check() usage. ] --------------------------------------------------- arch/x86/kvm/x86.h:72 invoked rcu_dereference_check() without protection! other info that might help us debug this: rcu_scheduler_active = 1, debug_locks = 0 1 lock held by qemu-system-x86/3027: #0: (&vcpu->mutex){+.+.+.}, at: [] vcpu_load+0x1a/0x66 [kvm] stack backtrace: Pid: 3027, comm: qemu-system-x86 Not tainted 2.6.34-rc4-tip-01028-g939eab1-dirty #28 Call Trace: [] lockdep_rcu_dereference+0xaa/0xb3 [] unalias_gfn_instantiation+0x56/0xaf [kvm] [] gfn_to_hva+0x14/0x4c [kvm] [] kvm_write_guest_page+0x2a/0x7f [kvm] [] kvm_write_guest+0x41/0x83 [kvm] [] kvm_write_guest_virt+0x78/0xa1 [kvm] [] pio_copy_data+0x46/0x75 [kvm] [] ? sub_preempt_count+0x9/0x83 [] complete_pio+0x91/0x1b9 [kvm] [] kvm_arch_vcpu_ioctl_run+0x93/0xd2b [kvm] [] ? kvm_arch_vcpu_ioctl_run+0x8e5/0xd2b [kvm] [] ? __lock_acquire+0x7b4/0x16d5 [] kvm_vcpu_ioctl+0x103/0x97b [kvm] [] ? kvm_vm_ioctl+0x364/0x38d [kvm] [] ? fget_light+0xf1/0x241 [] vfs_ioctl+0x32/0xa6 [] do_vfs_ioctl+0x495/0x4db [] ? fget_light+0x231/0x241 [] ? fget_light+0xf1/0x241 [] sys_ioctl+0x47/0x6a [] system_call_fastpath+0x16/0x1b