RE: [Xen-devel] RCU locks in Xen!

["Jayaraman, Bhaskar" <Bhaskar.Jayaraman@xxxxxxx>]

Keir, since rcu_read_lock doesn't disable/enable pre-emption in Xen, how will 
the rcu updater or call back invoker know whether any of the other CPU's are 
not in any of the RCU critical sections? Assuming that a context switch, user 
mode switch, or executed idle mode are the key and safe indicators to begin a 
grace period.

Regards,
Bhaskar.

-----Original Message-----
From: Keir Fraser [mailto:keir.fraser@xxxxxxxxxxxxx] 
Sent: Tuesday, February 24, 2009 5:36 PM
To: Jayaraman, Bhaskar; xen-devel@xxxxxxxxxxxxxxxxxxx
Subject: Re: [Xen-devel] RCU locks in Xen!

complete_domain_destroy() is called via call_rcu().

 -- Keir

On 24/02/2009 02:53, "Jayaraman, Bhaskar" <Bhaskar.Jayaraman@xxxxxxx> wrote:

> I see that rcu locks in Xen code are empty or in other words do nothing, and
> even rcu_dereference also doesn¹t assign pointers through a temporary
> variable. So is it possible that while domain destruction, while I¹m
> traversing through the domain_hash, list as in rcu_lock_domain_by_id(), I
> could end up with an invalid pointer?
> This is because I see that domain_destroy simply calls complete_domain_destroy
> which frees up the domain pointer and it seems like it could be possible that
> while traversing through the hash list in rcu_lock_domain_by_id I could end up
> with a domain pointer which domain_destroy might have just destroyed and I
> can¹t proceed further down the list.
>  
> Please let me know if there¹s something else that I¹m overlooking and if not
> then how come we don¹t see domains/Xen crashing because of this caveat.
>  
> Regards,
> Bhaskar.
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel