From mboxrd@z Thu Jan  1 00:00:00 1970
From: Marcelo Tosatti <mtosatti@redhat.com>
Subject: Re: [PATCH v2] KVM: Fix IOMMU RCU related warning
Date: Thu, 1 Jul 2010 13:16:22 -0300
Message-ID: <20100701161622.GE23469@amt.cnet>
References: <1277967650-16299-1-git-send-email-sheng@linux.intel.com>
 <1278000713-18752-1-git-send-email-sheng@linux.intel.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: Avi Kivity <avi@redhat.com>, kvm@vger.kernel.org
To: Sheng Yang <sheng@linux.intel.com>
Return-path: <kvm-owner@vger.kernel.org>
Received: from mx1.redhat.com ([209.132.183.28]:40492 "EHLO mx1.redhat.com"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S1752567Ab0GAQRi (ORCPT <rfc822;kvm@vger.kernel.org>);
	Thu, 1 Jul 2010 12:17:38 -0400
Content-Disposition: inline
In-Reply-To: <1278000713-18752-1-git-send-email-sheng@linux.intel.com>
Sender: kvm-owner@vger.kernel.org
List-ID: <kvm.vger.kernel.org>

On Fri, Jul 02, 2010 at 12:11:53AM +0800, Sheng Yang wrote:
> This patch fixes the following warning.
> 
> ===================================================
> [ INFO: suspicious rcu_dereference_check() usage. ]
> ---------------------------------------------------
> include/linux/kvm_host.h:259 invoked rcu_dereference_check() without
> protection!
> 
> other info that might help us debug this:
> 
> rcu_scheduler_active = 1, debug_locks = 0
> no locks held by qemu-system-x86/29679.
> 
> stack backtrace:
> Pid: 29679, comm: qemu-system-x86 Not tainted 2.6.35-rc3+ #200
> Call Trace:
>  [<ffffffff810a224e>] lockdep_rcu_dereference+0xa8/0xb1
>  [<ffffffffa018a06f>] kvm_iommu_unmap_memslots+0xc9/0xde [kvm]
>  [<ffffffffa018a0c4>] kvm_iommu_unmap_guest+0x40/0x4e [kvm]
>  [<ffffffffa018f772>] kvm_arch_destroy_vm+0x1a/0x186 [kvm]
>  [<ffffffffa01800d0>] kvm_put_kvm+0x110/0x167 [kvm]
>  [<ffffffffa0180ecc>] kvm_vcpu_release+0x18/0x1c [kvm]
>  [<ffffffff81156f5d>] fput+0x22a/0x3a0
>  [<ffffffff81152288>] filp_close+0xb4/0xcd
>  [<ffffffff8106599f>] put_files_struct+0x1b7/0x36b
>  [<ffffffff81065830>] ? put_files_struct+0x48/0x36b
>  [<ffffffff8131ee59>] ? do_raw_spin_unlock+0x118/0x160
>  [<ffffffff81065bc0>] exit_files+0x6d/0x75
>  [<ffffffff81068348>] do_exit+0x47d/0xc60
>  [<ffffffff8177e7b5>] ? _raw_spin_unlock_irq+0x30/0x36
>  [<ffffffff81068bfa>] do_group_exit+0xcf/0x134
>  [<ffffffff81080790>] get_signal_to_deliver+0x732/0x81d
>  [<ffffffff81095996>] ? cpu_clock+0x4e/0x60
>  [<ffffffff81002082>] do_notify_resume+0x117/0xc43
>  [<ffffffff810a2fa3>] ? trace_hardirqs_on+0xd/0xf
>  [<ffffffff81080d79>] ? sys_rt_sigtimedwait+0x2b5/0x3bf
>  [<ffffffff8177d9f2>] ? trace_hardirqs_off_thunk+0x3a/0x3c
>  [<ffffffff81003221>] ? sysret_signal+0x5/0x3d
>  [<ffffffff8100343b>] int_signal+0x12/0x17
> 
> Signed-off-by: Sheng Yang <sheng@linux.intel.com>
> ---
> I just realized the first version of patch unnecessarily covered
> kvm_iommu_map_memslots(), because that part had already been
> covered by kvm_vm_ioctl_assign_device() definitely(though unpaired
> callings seems a little strange...).

Since nesting srcu_read_lock is OK, its fine to have it in
kvm_iommu_map_memslots, even if unnecessary.