[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH 1/3] libxl: Fix libxl_postfork_child_noexec deadlock etc.

George Dunlap writes ("Re: [PATCH 1/3] libxl: Fix libxl_postfork_child_noexec 
deadlock etc."):
> So it looks like this path gets called from a number of other places in xl:
> libxl_postfork_child_noexec() is called by xl.c:postfork().

In the old code the deadlock only happens when
ctx->sigchld_user_registered (for the ctx passed to

Because xl uses .chldowner = libxl_sigchld_owner_libxl rather than
libxl_sigchld_owner_libxl_always, sigchld_user_registered is only true
when libxl actually has a child process.

In the single-threaded synchronous model used by xl for its
long_running operations (ie always passing ao_how==0), libxl only has
children _during_ the libxl call, when libxl calls back to the
application with a progress callback.

That's what happens in the pygrub case: xl needs to restart the
console viewer.

> postfork() is called in xl_cmdimpl.c by autoconnect_vncviewer(), 
> autoconnect_console(), and do_daemonize().

osstest doesn't use `xl create -c' so they weren't tested anyway.
But it also works just fine in the non-pygrub case.

Likewise `xl create -V' (autoconnect_vncviewer) works too.

> do_daemonize() is called during "xl create", and "xl devd".

These work without the bugfix.

> Was this deadlock not triggered for those, or was it triggered and 
> nobody noticed?

Mostly, the former.


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.