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:09:06 +0100 Message-ID: <527B58B2.2050105@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> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <527B51AE020000780010075B@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 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? 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. :-) 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