Re: [Xen-devel] [PATCH] libxl: Documentation about the domain configuration on disk

[Ian Jackson <ian.jackson@xxxxxxxxxx>]

Anthony PERARD writes ("Re: [PATCH] libxl: Documentation about the domain 
configuration on disk"):
> I think there is already a race, and `xl destroy` can leak QEMU. I've
> called `xl create` with a sleep before spawn_local_dm, and during the
> sleep, I call `xl destroy` with a sleep after it had an oportunity to
> kill QEMU.  So we have:
> 
> 1 domain creation xc_domain_create
> 2 domain destruction doesn't kill qemu, it's not there yet.
> 3 domain creation spawn qemu
> 4 domain creation creates libxl-json

I think the ordering of 3 vs 4 is a violation of my `thing' rules.
This has gone unnoticed because we haven't been treating qemu itself
as a `thing'.

If we did treat qemu itself as a Thing, it would be necessary to hold
the libxl-json lock while forking it.  But fork is slow.

> > Maybe qemu's existence is `primary non-qmp state' and in fact domain
> > destruction is not allowed to destroy it without holding the
> > libxl-json lock.  But I bet that rule is not honoured right now.
> 
> I think it's fine for domain destruction to kill QEMU without any lock.
> Any threads communicating via QMP should receive an error.

If qemu's existence is `primary qmp state' then the rules in my other
mail imply holding the qmp lock for it while spawning it.  I think
that would be doable ?

> > Comments, anyone ?
> 
> That slow lock idea looks fine otherwise, we could call it
> "libxl-qmp-lock" for now and have it mandatory when adding/removing
> things via QMP. If a slow lock is needed for other thing than QMP, we
> can change the meaning.

I don't mind calling it the `libxl qmp lock' in code or documentation,
but the actual filename needs to not to be `libxl-qmp-lock' because we
cannot easily change it later.  And there would be obvious advantages
to making the name the same everywhere.

Anyway, I hope the above observations make sense to you.  Let me know
what you think.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel