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



On Mon, Feb 24, 2014 at 3:56 PM, Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx> wrote:
> 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
> libxl_postfork_child_noexec).
>
> 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.

Right.  Having chatted f2f with Ian, and looked through the old and
new code, I'm reasonably convinced that only the broken case can
actually be affected.

So:

Release-acked-by: George Dunlap <george.dunlap@xxxxxxxxxxxxx>

We're also going to do an RC6 -- please do a smoke-test if you get a
chance.  (I'll send out a separate e-mail to the list as well.)

 -George

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


 


Rackspace

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