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

Re: [Xen-devel] [PATCH 17/19] libxl: do not leak spawned middle children



On Fri, 2012-06-08 at 18:34 +0100, Ian Jackson wrote:
> libxl__spawn_spawn would, when libxl__spawn_detach was called, make
> the spawn become idle immediately.  However it still has a child
> process which needs to be waited for: the `detachable' spawned
> child.
> 
> This is wrong because the ultimate in-libxl caller may return to the
> application, with a child process still forked but not reaped libxl
> contrary to the documented behaviour of libxl.
> 
> Instead, replace libxl__spawn_detach with libxl__spawn_initiate_detach
> which is asynchronous.  The detachable spawned children are abolished;
> instead, we defer calling back to the in-libxl user until the middle
> child has been reaped.
> 
> Also, remove erroneous comment suggesting that `death' callback
> parameter to libxl__ev_child_fork may be NULL.  It may not, and there
> are no callers which pass NULL.
> 
> Signed-off-by: Ian Jackson <ian.jackson@xxxxxxxxxxxxx>

Acked-by: Ian Campbell <ian.campbell@xxxxxxxxxx>

(couple of tiny queries below)

[...]
> diff --git a/tools/libxl/libxl_exec.c b/tools/libxl/libxl_exec.c
> index cfa379c..bb85682 100644
> --- a/tools/libxl/libxl_exec.c
> +++ b/tools/libxl/libxl_exec.c
> @@ -238,15 +238,16 @@ err:
>  /*
>   * Full set of possible states of a libxl__spawn_state and its _detachable:
>   *
> - *               ss->        ss->        ss->    | ssd->       ssd->
> - *               timeout     xswatch     ssd     |  mid         ss
> - *  - Undefined   undef       undef       no     |  -           -
> - *  - Idle        Idle        Idle        no     |  -           -
> - *  - Active      Active      Active      yes    |  Active      yes
> - *  - Partial     Active/Idle Active/Idle maybe  |  Active/Idle yes  (if 
> exists)
> - *  - Detached    -           -           -      |  Active      no
> + *                   detaching failed  mid     timeout      xswatch
> + *  - Undefined         undef   undef   -        undef        undef
> + *  - Idle              any     any     Idle     Idle         Idle
> + *  - Attached OK       0       0       Active   Active       Active
> + *  - Attached Failed   0       1       Active   Idle         Idle
> + *  - Detaching         1       maybe   Active   Idle         Idle
> + *  - Partial           any     any     Idle     Active/Idle  Active/Idle
>   *
> - * When in state Detached, the middle process has been sent a SIGKILL.
> + * When in states Detaching or Attached Failed, the middle process has
> + * been sent a SIGKILL.
>   */
> 
>  /* Event callbacks. */
> @@ -257,19 +258,18 @@ static void spawn_timeout(libxl__egc *egc, 
> libxl__ev_time *ev,
>  static void spawn_middle_death(libxl__egc *egc, libxl__ev_child *childw,
>                                 pid_t pid, int status);
> 
> -/* Precondition: Partial.  Results: Detached. */
> +/* Precondition: Partial.  Results: Idle. */
>  static void spawn_cleanup(libxl__gc *gc, libxl__spawn_state *ss);
> 
> -/* Precondition: Partial; caller has logged failure reason.
> - * Results: Caller notified of failure;
> - *  after return, ss may be completely invalid as caller may reuse it */
> -static void spawn_failed(libxl__egc *egc, libxl__spawn_state *ss);
> +/* Precondition: Attached or Detaching; caller has logged failure reason.
> + * Results: Detaching, or Attached Failing */

Is it Failing or Failed? You use Failed elsewhere.

[...]
> @@ -998,8 +997,8 @@ _hidden int libxl__device_pci_destroy_all(libxl__gc *gc, 
> uint32_t domid);
>   *
>   * Higher-level double-fork and separate detach eg as for device models
>   *
> - * Each libxl__spawn_state is in one of the conventional states
> - *    Undefined, Idle, Active
> + * Each libxl__spawn_state is in one of these states
> + *    Undefined, Idle, Attached, Detaching

"Attached OK" and "Attached Failed" as described above aren't really
full states, just sub-states?

Ian.


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