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

[Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>]

Chun Yan Liu writes ("Re: [Xen-devel][PATCH]improve suspend_evtchn lock 
processing"):
> >>> 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

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