From mboxrd@z Thu Jan 1 00:00:00 1970 From: Juergen Gross Subject: Re: [Patch] Call sched_destroy_domain before cpupool_rm_domain. Date: Thu, 07 Nov 2013 10:43:42 +0100 Message-ID: <527B60CE.9000907@ts.fujitsu.com> References: <1383534234-3933-1-git-send-email-nate.studer@dornerworks.com> <52773EF2.8000308@ts.fujitsu.com> <1383557167.9207.35.camel@Solace> <52776FBC.50800@ts.fujitsu.com> <5277BBB6.5050604@dornerworks.com> <52788932.1030209@ts.fujitsu.com> <527B51AE020000780010075B@nat28.tlf.novell.com> <527B58B2.2050105@ts.fujitsu.com> <527B6D5E0200007800100849@nat28.tlf.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <527B6D5E0200007800100849@nat28.tlf.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Jan Beulich Cc: George Dunlap , Dario Faggioli , Keir Fraser , Nate Studer , xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org On 07.11.2013 10:37, Jan Beulich wrote: >>>> On 07.11.13 at 10:09, Juergen Gross wrote: >> On 07.11.2013 08:39, Jan Beulich wrote: >>>>>> On 05.11.13 at 06:59, Juergen Gross 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