[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

 


Rackspace

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