| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
RE: [Xen-devel] RCU locks in Xen!
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
|
|
|
| |
|
Home