WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

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

To: Chun Yan Liu <cyliu@xxxxxxxxxx>
Subject: Re: [Xen-devel][PATCH]improve suspend_evtchn lock processing
From: Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>
Date: Thu, 3 Mar 2011 17:02:18 +0000
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Thu, 03 Mar 2011 09:03:18 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <4D6BBB52020000660001D5F2@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <4D6BBB52020000660001D5F2@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
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

<Prev in Thread] Current Thread [Next in Thread>
  • Re: [Xen-devel][PATCH]improve suspend_evtchn lock processing, Ian Jackson <=