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

Re: [Xen-devel][PATCH]improve suspend_evtchn lock processing



Chun Yan Liu writes ("Re: [Xen-devel][PATCH]improve suspend_evtchn lock 
processing"):
> Hope there could be some hints. Thanks.

I think we should defer this patch to 4.2.  But here are some
comments in response to your questions:

> First, following is a change to use fcntl instead of flock (not
> available in newlibc when "make stubdom") and O_EXCL file, but the
> lock file could not be unlinked safely. There will be many lock
> files left in system.

The usual approach is to say that:
  * When locking you must
      open the file
      fstat
      fcntl F_SETLK[W]
      stat the file and check that the inode is the same
       as the one you have open; if not go back and try again
  * You may delete the lockfile if you have locked it first

> To use fcntl properly, the lock file should be created when VM
> started and deleted when VM destroyed. But I'm not sure if that
> change is acceptable or not. And I noticed in another patch, you
> mentioned fcntl (SETLK) is not very portable. Does that mean we'd
> better not use fcntl + SETLK to implement lock?

Perhaps this locking should be moved up into the toolstack, or done
via helper callbacks.

> Second, in the lastest code, the suspend_evtchn lock is set to each
> VM. Is there any user case that two processes contend for the
> suspend event channel of the same VM?

If they do then they will have to be serialised.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel


 


Rackspace

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