Re: [Xen-devel] [Patch] Call sched_destroy_domain before cpupool_rm_domain.

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 07.11.13 at 10:09, Juergen Gross <juergen.gross@xxxxxxxxxxxxxx> wrote:
> On 07.11.2013 08:39, Jan Beulich wrote:
>>>>> On 05.11.13 at 06:59, Juergen Gross <juergen.gross@xxxxxxxxxxxxxx> wrote:
>>> On 04.11.2013 16:22, Nate Studer wrote:
>>>> On 11/4/2013 4:58 AM, Juergen Gross wrote:
>>>>> All other schedulers will just call xfree() for the domain specific data 
> (and
>>>>> may be update some statistic data, which is not critical).
>>>>
>>>> The credit and credit2 schedulers do a bit more than that in their 
> free_domdata
>>>> functions.
>>>
>>> Sorry, got not enough sleep on the weekend ;-)
>>>
>>> I checked only 4.1 and 4.2 trees. There only xfree of the domain data is
>>> done.
>>>
>>>>
>>>> The credit scheduler frees the node_affinity_cpumask contained in the 
>>>> domain
>>>> data and the credit2 scheduler deletes a list element contained in the 
> domain
>>>> data.  Since with this bug they are accessing structures that do not 
>>>> belong 
> to
>>>> them, bad things happen.
>>>
>>> So the patch would be subject to a 4.3 backport, I think.
>>
>> Hmm, I'm slightly confused: credit2's free_domdata has always been
>> doing more than just xfree() afaict, and hence backporting is either
>> necessary uniformly or (taking into account that it was made clear
>> that arinc doesn't work with CPU pools anyway so far) not at all.
>>
>> Please clarify.
> 
> Okay, I assumed only "production ready" features are to be taken into 
> account
> for a backport. And credit2 is clearly not in this state, or am I wrong?

You aren't, but is arinc production ready? I wouldn't think so
simply based on it not working with CPU pools. And then the
backporting question would become mute.

> A 4.3 backport should be considered in any case, as sedf and credit 
> schedulers
> behave differently in free_domdata, and both are "production ready". If you
> want to be safe for credit2 and/or arinc653 as well, backports to 4.2 and 
> 4.1
> will be required.
> 
> In any case a backport isn't very complex. :-)

Indeed. But I'd like backports to be on purpose as well as
consistent across trees (iow: applied to all maintained trees
where needed, and only there).

Jan


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