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

["Chun Yan Liu" <cyliu@xxxxxxxxxx>]

>>> Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx> 02/25/11 12:09 PM >>>
>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
There is risk while deleting the lock file. Unlink only deletes the file path from its directoy but not the real file source. If another process also opened the file, the file source would not be deleted until all references to the file released. There might be problem:
A create lock file
A open lock file
A fcntl/flock                 get the lock
B open lock file
A release lock             release the lock
A unlink lock file
B fcntl/flock                get the lock
C create lock file         a new file
C open lock file
C fcntl/flock                get the lock on the new file
Then there will be two processes get the lock successfully.
Considering this, I think it's not safe to unlink the lock file here. The lock file should be deleted somewhere else, like: delete when the domain is shutdown. That's really a mess.

>> 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.
Uhh. I am just curious since I cannot think of a user case that will need the per-domain suspend_evtchn_lock.
E.g, for two concurrent 'xc save', the later one will just fail in the upper tool layer.
The first 'xc save xxx' will change the domain name to be migrating-xxx, the later 'xc save xxx'
will fail since it could not find a domain named xxx then.

Thanks,
Chunyan

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