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

>>> Ian Jackson  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@lists.xensource.com
http://lists.xensource.com/xen-devel

Chun Yan Liu writes ("Re: [Xen-devel][PATCH]improve suspend_evtchn lock
processing"):
> >>> Ian Jackson <Ian.Jackson@eu.citrix.com> 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
But A''s behaviour here contravenes my specification, which is that you
may only delete the file with the lock held (and, implicitly, doing so
releases the lock).
> 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.
I think two saves simultaneously is caller error which ought to be
spotted.  But not in 4.1.

Ian.

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