[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH v2 01/25] arm/altp2m: Add first altp2m HVMOP stubs.



Hello Tamas,

On 10/08/2016 16:49, Tamas K Lengyel wrote:
On Aug 10, 2016 03:52, "Julien Grall" <julien.grall@xxxxxxx
<mailto:julien.grall@xxxxxxx>> wrote:
On 09/08/2016 21:16, Tamas K Lengyel wrote:
On Wed, Aug 3, 2016 at 10:54 AM, Julien Grall <julien.grall@xxxxxxx
<mailto:julien.grall@xxxxxxx>> 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@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.