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@lists.xensource.com http://lists.xensource.com/xen-devel
complete_domain_destroy() is called via call_rcu(). -- Keir On 24/02/2009 02:53, "Jayaraman, Bhaskar" <Bhaskar.Jayaraman@lsi.com> 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@lists.xensource.com http://lists.xensource.com/xen-devel
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@eu.citrix.com] Sent: Tuesday, February 24, 2009 5:36 PM To: Jayaraman, Bhaskar; xen-devel@lists.xensource.com 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@lsi.com> 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@lists.xensource.com http://lists.xensource.com/xen-devel
What preemption would it disable? Xen is non-preemptive. -- Keir On 27/02/2009 12:56, "Jayaraman, Bhaskar" <Bhaskar.Jayaraman@lsi.com> 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@eu.citrix.com] > Sent: Tuesday, February 24, 2009 5:36 PM > To: Jayaraman, Bhaskar; xen-devel@lists.xensource.com > 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@lsi.com> 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@lists.xensource.com http://lists.xensource.com/xen-devel
Thanks Keir, I just needed to know as much. Bhaskar. ________________________________________ From: Keir Fraser [keir.fraser@eu.citrix.com] Sent: Friday, February 27, 2009 8:07 AM To: Jayaraman, Bhaskar; xen-devel@lists.xensource.com Subject: Re: [Xen-devel] RCU locks in Xen! What preemption would it disable? Xen is non-preemptive. -- Keir On 27/02/2009 12:56, "Jayaraman, Bhaskar" <Bhaskar.Jayaraman@lsi.com> 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@eu.citrix.com] > Sent: Tuesday, February 24, 2009 5:36 PM > To: Jayaraman, Bhaskar; xen-devel@lists.xensource.com > 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@lsi.com> 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@lists.xensource.com http://lists.xensource.com/xen-devel