linux-kernel - Re: [PATCH] kvm: make vcpu life cycle separated from kvm instance

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, 5 Dec 2011 10:41:59 +0200
From:	Gleb Natapov <gleb@...hat.com>
To:	Liu ping fan <kernelfans@...il.com>
Cc:	Jan Kiszka <jan.kiszka@...mens.com>, avi@...hat.com,
	kvm@...r.kernel.org, linux-kernel@...r.kernel.org,
	aliguori@...ibm.com
Subject: Re: [PATCH] kvm: make vcpu life cycle separated from kvm instance

On Mon, Dec 05, 2011 at 01:39:37PM +0800, Liu ping fan wrote:
> On Sun, Dec 4, 2011 at 8:10 PM, Gleb Natapov <gleb@...hat.com> wrote:
> > On Sun, Dec 04, 2011 at 07:53:37PM +0800, Liu ping fan wrote:
> >> On Sat, Dec 3, 2011 at 2:26 AM, Jan Kiszka <jan.kiszka@...mens.com> wrote:
> >> > On 2011-12-02 07:26, Liu Ping Fan wrote:
> >> >> From: Liu Ping Fan <pingfank@...ux.vnet.ibm.com>
> >> >>
> >> >> Currently, vcpu can be destructed only when kvm instance destroyed.
> >> >> Change this to vcpu's destruction taken when its refcnt is zero,
> >> >> and then vcpu MUST and CAN be destroyed before kvm's destroy.
> >> >
> >> > I'm lacking the big picture yet (would be good to have in the change log
> >> > - at least I'm too lazy to read the code):
> >> >
> >> > What increments the refcnt, what decrements it again? IOW, how does user
> >> > space controls the life-cycle of a vcpu after your changes?
> >> >
> >> In local APIC mode, delivering IPI to target APIC, target's refcnt is
> >> incremented, and decremented when finished. At other times, using RCU to
> > Why is this needed?
> >
> Suppose the following scene:
> 
> #define kvm_for_each_vcpu(idx, vcpup, kvm) \
>         for (idx = 0; \
>              idx < atomic_read(&kvm->online_vcpus) && \
>              (vcpup = kvm_get_vcpu(kvm, idx)) != NULL; \
>              idx++)
> 
> ------------------------------------------------------------------------------------------>
> Here kvm_vcpu's destruction is called
>               vcpup->vcpu_id ...  //oops!
> 
> 
And this is exactly how your code looks. i.e you do not increment
reference count in most of the loops, you only increment it twice
(in pic_unlock() and kvm_irq_delivery_to_apic()) because you are using
vcpu outside of rcu_read_lock() protected section and I do not see why
not just extend protected section to include kvm_vcpu_kick(). As far as
I can see this function does not sleep.

What should protect vcpu from disappearing in your example above is RCU
itself if you are using it right. But since I do not see any calls to
rcu_assign_pointer()/rcu_dereference() I doubt you are using it right
actually.

--
			Gleb.
--
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/