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

[Keir Fraser <keir.fraser@xxxxxxxxxxxxx>]

What preemption would it disable? Xen is non-preemptive.

 -- Keir

On 27/02/2009 12:56, "Jayaraman, Bhaskar" <Bhaskar.Jayaraman@xxxxxxx> wrote:

> 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