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 06:14:05PM +0100, Ian Jackson wrote:
> Wei Liu writes ("Re: [PATCH v1 03/10] libxl: store a copy of vanilla domain 
> configuration when creating domain"):
> > On Fri, Jul 25, 2014 at 04:01:06PM +0100, Ian Jackson wrote:
> > > During that time various operations would block unreasonably.
> > 
> > That's a bit unfortunate. But what can we do to close that window?
> > I think no good will come out if I try to fiddle with domain state
> > during creation anyway, so locking like this may be acceptable?
> 
> No, because it might block a management daemon.  You're not allowed to
> hold a lock which libxl operations will block on while doing anything
> `slow' in the ao sense.  Conceivably in a sufficiently complicated
> system it might even result in deadlock.
> 
> I think the right answer is for those attempts to fiddle with the
> domain state to fail.
> 

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

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.

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

> > > Also, I think you mustn't use an fcntl lock across ao operation
> > > callback chains.  fcntl locks do not exclude other threads in the same
> > > process.
> > 
> > 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.

Wei.

> Ian.

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