|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v2 3/9] libxl_internal: Introduce libxl__ev_lock for devices hotplug via QMP
Anthony PERARD writes ("[PATCH v2 3/9] libxl_internal: Introduce libxl__ev_lock
for devices hotplug via QMP"):
> The current lock `domain_userdata_lock' can't be used when modification
> to a guest is done by sending command to QEMU, this is a slow process
> and requires to call CTX_UNLOCK, which is not possible while holding
> the `domain_userdata_lock'.
>
> To resolve this issue, we create a new lock which can take over part
> of the job of the json_lock.
Thanks. This is basically fine. I have only trivial comments.
> +void libxl__ev_lock_get(libxl__egc *egc, libxl__ev_lock *lock)
I wonder if this is the right name for this. Effectively you have
called this lock "lock". Maybe "dlock" or "devlock" or "sdlock" (slow
device lock) or something ? Sorry for bikeshedding but hopefully
seddery will be easy.
> +static void ev_lock_prepare_fork(libxl__egc *egc, libxl__ev_lock *lock)
> +{
...
> + /* All other errno: EBADF, EINVAL, ENOLCK, EWOULDBLOCK */
> + LOGED(ERROR, domid,
> + "unexpected error while trying to lock %s, fd=%d,
> errno=%d",
> + lockfile, fd, errno);
LOGED prints strerror(errno) so you don't need to print the numeric
value with %d too. That's what the E in its name is.
> +void libxl__ev_unlock(libxl__gc *gc, libxl__ev_lock *lock)
> +{
> + int r;
> +
> + assert(!libxl__ev_child_inuse(&lock->child));
> +
> + /* It's important to unlink the file before releasing the lock to avoid
> + * the following race (if unlock/close before unlink):
> + *
> + * P1 LOCK P2 UNLOCK
> + * fd1 = open(lockfile)
> + * unlock(fd2)
> + * flock(fd1)
> + * fstat and stat check success
> + * unlink(lockfile)
> + * return lock
> + *
> + * In above case P1 thinks it has got hold of the lock but
> + * actually lock is released by P2 (lockfile unlinked).
> + */
I wonder if it would be better to refer to the other copy of this
comment by libxl__unlock_domain_userdata.
Regards,
Ian.
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |