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

Re: [Xen-devel] [PATCH] cpupools: retry cpupool-destroy if domain in cpupool is dying



On Wed, May 7, 2014 at 8:52 AM, Juergen Gross
<juergen.gross@xxxxxxxxxxxxxx> wrote:
> When a cpupool is destroyed just after the last domain has been stopped the
> domain might already be removed from the cpupool without having decremented
> the domain count of the cpupool. This will result in rejection of the
> cpupool-destroy operation.

I'm a bit confused.  What's the sched_move_domain() for, then?  If
we're going to handle "dying domains" by doing a retry, could we just
get rid of it?

 -George

> It is easy to detect this situation and to return EAGAIN in this case which
> is already handled in libxc by doing a retry.
>
> Signed-off-by: Juergen Gross <juergen.gross@xxxxxxxxxxxxxx>
> ---
>  xen/common/cpupool.c |    2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/xen/common/cpupool.c b/xen/common/cpupool.c
> index 4a0e569..ac833f0 100644
> --- a/xen/common/cpupool.c
> +++ b/xen/common/cpupool.c
> @@ -348,6 +348,8 @@ static int cpupool_unassign_cpu(struct cpupool *c, 
> unsigned int cpu)
>              cpupool0->n_dom++;
>          }
>          rcu_read_unlock(&domlist_read_lock);
> +        if ( (c->n_dom > 0) && !ret )
> +            ret = -EAGAIN;
>          if ( ret )
>              goto out;
>      }
> --
> 1.7.10.4
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxx
> http://lists.xen.org/xen-devel

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