Re: [Xen-devel] [PATCH v1 03/10] libxl: store a copy of vanilla domain configuration when creating domain

[Wei Liu <wei.liu2@xxxxxxxxxx>]

On Fri, Jul 25, 2014 at 07:31:38PM +0100, Ian Jackson wrote:
> Wei Liu writes ("Re: [PATCH v1 03/10] libxl: store a copy of vanilla domain 
> configuration when creating domain"):
> > OK, how about we do this.
> > 1. keep a copy of vanilla config in memory instead of writing it to disk
> >    at the beginning
> > 2. write the most update-to-date version when domain creation finishes
> 
> I think that's correct.
> 
> > That way, any operations that try to fiddle with domain state,
> > especially those who require reading / writing JSON config, can fail at
> > the point when they try to access JSON config file.
> 
> Right.
> 
> > However this approach has a downside -- we try to maintain invariant
> > that every device in xenstore has an entry in JSON config -- this seems
> > to break that invariant. On the flip side, I think we can loosen this a
> > bit, because even if we write JSON config at the beginning, the stored
> > entry doesn't contain device identifier so that we're impossible to
> > maitain that invariant anyway (that is, there's an entry in JSON but we
> > cannot associate it with an entry in xenstore).
> 
> Yes, I think the invariant needs to be relaxed so that we also permit
> a domain which has no JSON at all.  Such a domain cannot have devices
> added or removed.  It is in the process of being created or destroyed.
> 

Ack. This sounds plausible.

> > > > Then we need both mutex and file lock? Mutex to protect against threads
> > > > in the same process while file lock protect against other processes.
> > > 
> > > I think the answer is that you have to not retain the lock for so
> > > long.
> > 
> > I don't follow. As you said fcntl lock has no effect on threads, so "not
> > retain the lock for so long" is irrelevant to protect races among
> > threads.
> 
> If the application makes multiple threads which call into libxl to do
> different things (things which might need to be serialised), these
> different threads will not benefit from any interlocking due to the
> fcntl lock.
> 
> I was going to say that this doesn't matter so long as all those
> threads are all within the scope of a single acquision of the libxl
> ctx lock.  But of course that's wrong because the two threads might be
> using different ctxs.
> 
> In summary I think you should be using flock which doesn't have these
> problems, but which instead requires using the carefd machinery to
> avoid unrelated processes inheriting the fd and hence the lock.
> 

I actually looked at flock(2) this afternoon but deemed it is not as
portable as fcntl so I didn't propose it. flock on NFS file probably
won't work (I bet we won't have the chance to put user data store on NFS
though). And somee other UNIX systems might actually implement flock with
fcntl. The latter is more concerning.

If you don't think the above issues are critical I can try to replace
fcntl with flock.

Wei.

> Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel