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

[Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>]

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.

> > > 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.

Ian.

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