xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: Juergen Gross <juergen.gross@ts.fujitsu.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: George Dunlap <george.dunlap@eu.citrix.com>,
	Dario Faggioli <dario.faggioli@citrix.com>,
	Keir Fraser <keir@xen.org>,
	Nate Studer <nate.studer@dornerworks.com>,
	xen-devel@lists.xen.org
Subject: Re: [Patch] Call sched_destroy_domain before cpupool_rm_domain.
Date: Thu, 07 Nov 2013 10:43:42 +0100	[thread overview]
Message-ID: <527B60CE.9000907@ts.fujitsu.com> (raw)
In-Reply-To: <527B6D5E0200007800100849@nat28.tlf.novell.com>

On 07.11.2013 10:37, Jan Beulich wrote:
>>>> On 07.11.13 at 10:09, Juergen Gross <juergen.gross@ts.fujitsu.com> wrote:
>> On 07.11.2013 08:39, Jan Beulich wrote:
>>>>>> On 05.11.13 at 06:59, Juergen Gross <juergen.gross@ts.fujitsu.com> 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.

No, it doesn't. The following statement should have made that clear:

>> 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 have credit as default scheduler and use sedf in a cpupool, destroying
a domain in the cpupool with sedf will use the credit free_domdata routine,
leading to an error in 4.3 when calling free_cpumask_var().


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

  reply	other threads:[~2013-11-07  9:43 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-11-04  3:03 [Patch] Call sched_destroy_domain before cpupool_rm_domain Nathan Studer
2013-11-04  6:30 ` Juergen Gross
2013-11-04  9:26   ` Dario Faggioli
2013-11-04  9:58     ` Juergen Gross
2013-11-04 15:22       ` Nate Studer
2013-11-05  5:59         ` Juergen Gross
2013-11-07  7:39           ` Jan Beulich
2013-11-07  9:09             ` Juergen Gross
2013-11-07  9:37               ` Jan Beulich
2013-11-07  9:43                 ` Juergen Gross [this message]
2013-11-04  9:33   ` Andrew Cooper
2013-11-05 21:09     ` Keir Fraser
2013-11-04 15:10 ` George Dunlap

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=527B60CE.9000907@ts.fujitsu.com \
    --to=juergen.gross@ts.fujitsu.com \
    --cc=JBeulich@suse.com \
    --cc=dario.faggioli@citrix.com \
    --cc=george.dunlap@eu.citrix.com \
    --cc=keir@xen.org \
    --cc=nate.studer@dornerworks.com \
    --cc=xen-devel@lists.xen.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).