Re: [Patch] Call sched_destroy_domain before cpupool_rm_domain.

[Juergen Gross <juergen.gross@ts.fujitsu.com>]

On 04.11.2013 10:26, Dario Faggioli wrote:
> On lun, 2013-11-04 at 07:30 +0100, Juergen Gross wrote:
>> On 04.11.2013 04:03, Nathan Studer wrote:
>>> From: Nathan Studer <nate.studer@dornerworks.com>
>>>
>>> The domain destruction code, removes a domain from its cpupool
>>> before attempting to destroy its scheduler information.  Since
>>> the scheduler framework uses the domain's cpupool information
>>> to decide on which scheduler ops to use, this results in the
>>> the wrong scheduler's destroy domain function being called
>>> when the cpupool scheduler and the initial scheduler are
>>> different.
>>>
>>> Correct this by destroying the domain's scheduling information
>>> before removing it from the pool.
>>>
>>> Signed-off-by: Nathan Studer <nate.studer@dornerworks.com>
>>
>> Reviewed-by: Juergen Gross <juergen.gross@ts.fujitsu.com>
>>
> I think this is a candidate for backports too, isn't it?
>
> Nathan, what was happening without this patch? Are you able to quickly
> figure out what previous Xen versions suffers from the same bug?

In theory this bug is present since 4.1.

OTOH it will be hit only with arinc653 scheduler in a cpupool other than
Pool-0. And I don't see how this is being supported by arinc653 today (pick_cpu
will always return 0).

All other schedulers will just call xfree() for the domain specific data (and
may be update some statistic data, which is not critical).


Juergen

-- 
Juergen Gross                 Principal Developer Operating Systems
PBG PDG ES&S SWE OS6                   Telephone: +49 (0) 89 62060 2932
Fujitsu                                   e-mail: juergen.gross@ts.fujitsu.com
Mies-van-der-Rohe-Str. 8                Internet: ts.fujitsu.com
D-80807 Muenchen                 Company details: ts.fujitsu.com/imprint.html