Hello Tamas,
On 10/08/2016 16:49, Tamas K Lengyel wrote:
On Aug 10, 2016 03:52, "Julien Grall" <julien.gr...@arm.com
<mailto:julien.gr...@arm.com>> wrote:
On 09/08/2016 21:16, Tamas K Lengyel wrote:
On Wed, Aug 3, 2016 at 10:54 AM, Julien Grall <julien.gr...@arm.com
<mailto:julien.gr...@arm.com>> wrote:
There is a rcu_lock_domain_by_any_id before we get to this check here,
so any other CPU looking to disable altp2m would be waiting there for
the current op to finish up, so there is no race condition AFAICT.
No, rcu_lock_domain_by_any_id only prevents the domain to be fully
destroyed by "locking" the rcu. It does not prevent multiple concurrent
access. You can look at the code if you are not convinced.
Ah thanks for clarifying. Then indeed there could be concurrency issues
if there are multiple tools accessing this interface. Normally that
doesn't happen though but probably a good idea to enforce it anyway.
Well, you need to think about the worst case scenario when you implement
an interface. If you don't lock properly, the state in Xen may be
corrupted. For instance Xen may think altp2m is active whilst it is not
properly initialized.
Regards,
--
Julien Grall
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
