Re: [RFC PATCH] KVM: optimize apic interrupt delivery

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Sep 11, 2012 at 02:20:49PM +0300, Gleb Natapov wrote:
> On Mon, Sep 10, 2012 at 07:17:54PM +0300, Gleb Natapov wrote:
> > > 
> > > > +	rcu_assign_pointer(kvm->arch.apic_map, new);
> > > > +	mutex_unlock(&kvm->arch.apic_map_lock);
> > > > +
> > > > +	if (old)
> > > > +		call_rcu(&old->rcu, rcu_free_apic_map);
> > > 
> > > What guarantees rcu_free_apic_map is called before module goes away?
> > Why do we care?
> > 
> Ugh. We do not care that apic_map memory will stick after module unload, but we
> obviously care since rcu_free_apic_map() code itself will go away. Looks
> like general problem for all modular users of call_rcu(). Is there
> general solution in module unload code somewhere? Calling rcu_barrier()
> before unloading module should be enough.
> 
If nothing changed for the past 3 years each module should call
rcu_barrier() by itself:
http://paulmck.livejournal.com/7314.html

Looking at the code I see that it calls synchronize_rcu() on module
delete, but this is not enough. :(

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


[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux