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
