WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] [PATCH] Avoid panic when adjusting sedf parameters

To: Jan Beulich <JBeulich@xxxxxxxx>
Subject: Re: [Xen-devel] [PATCH] Avoid panic when adjusting sedf parameters
From: Juergen Gross <juergen.gross@xxxxxxxxxxxxxx>
Date: Thu, 17 Nov 2011 15:41:11 +0100
Cc: Keir Fraser <keir.xen@xxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Thu, 17 Nov 2011 06:44:00 -0800
Dkim-signature: v=1; a=rsa-sha256; c=simple/simple; d=ts.fujitsu.com; i=juergen.gross@xxxxxxxxxxxxxx; q=dns/txt; s=s1536b; t=1321540872; x=1353076872; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=LBVrF5MzzN/qmo3KhGYhXbZtJw5kE4CUJCvTBYrnSdM=; b=XK5B9Gtu184OWGMVhQzA5I9QKp21MkboD638KC9kOAX401N+pXlK9VZO SSAQ3k4+MoKSppClJkoghBdswtO4L2eRuH+n+6ybWBtFbk7emhCFiAHu+ eqpXaGB0mvf3nt3LgCGHpHySnFbKi/JUBKP0zau3btC5/323Y1Dkzv2BY TsTKuIuUanoNgkLX+IVD0hEiv0s7c+9fJI+et7u6K8thZia1Gwfm+94Il GgZwzAibINQaCuR4NEBDKKZtE5jJh;
Domainkey-signature: s=s1536a; d=ts.fujitsu.com; c=nofws; q=dns; h=X-SBRSScore:X-IronPort-AV:Received:X-IronPort-AV: Received:Received:Message-ID:Date:From:Organization: User-Agent:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=Y9rp3T7s6CyMDZisF48T5m+AXH6JwijiedAt5+1t6tJJ+F4QWx4cz59C F2LrddWVuF96X8GZvRmWR6P7DK6/X2zkxLwB85Z8ia2gPdFzppSh5vuEA alvAVahS+TsmLEAL8zaMVEkZuN4jfQKG30SMfP7nLezkEmov0YKHz0LAh 4kVrH+vpvKRYysGxCsTkWpXynFEATc87E13n/5NbqOkYbMMXhqCmVAkJB OG+5VEb2/urElt+2DLQRRkIXR5AVh;
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <4EC528FD0200007800061983@xxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Organization: Fujitsu Technology Solutions
References: <CAEAC230.25135%keir.xen@xxxxxxxxx> <4EC51489.4090609@xxxxxxxxxxxxxx> <4EC528FD0200007800061983@xxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20111010 Iceowl/1.0b2 Icedove/3.1.15
On 11/17/2011 03:32 PM, Jan Beulich wrote:
On 17.11.11 at 15:04, Juergen Gross<juergen.gross@xxxxxxxxxxxxxx>  wrote:
On 11/17/2011 02:52 PM, Keir Fraser wrote:
On 17/11/2011 13:30, "Jan Beulich"<JBeulich@xxxxxxxx>   wrote:

which would now associate the else with the wrong (inner) if. One
possible solution that comes to mind would be

#define for_each_domain_in_cpupool(_d,_c) \
      for_each_domain_in_cpupool (_d) \
          if ((_d)->cpupool != (_c)) \
              continue; \
          else

but I think I had seen a more clever solution to this problem, but cannot
remember/locate it right now.
Given the gcc ({}) construction, you could do a double-loop:
   for ( (_d) = rcu_dereference(domain_list);     \
         (_d) != NULL;                            \
         ({ while ((_d) = rcu_dereference((_d)->next_in_list != NULL)
               if ((_d)->cpupool == (_c)) break;
            (_d); }) )

A bit ugly. ;-) And I still worry about cpupool locking...
What about:

static inline struct domain *next_domain_in_cpupool(
      struct domain *d, struct cpupool *c)
{
      for (d = rcu_dereference(d->next_in_list); d&&  d->cpupool != c;
           d = rcu_dereference(d->next_in_list));
      return d;
}

#define for_each_domain_in_cpupool(_d,_c)       \
   for ( (_d) = rcu_dereference(domain_list);     \
         (_d) != NULL;                            \
         (_d) = next_domain_in_cpupool((_d), (_c)))
Same problem as with Keir's variant - you'd enter the loop body for
the first domain on the list regardless of its cpupool. But with a
first_domain_in_cpupool() counterpart this might be usable. Or, as
said in the other reply, putting a more complex construct in the
middle clause.

I think adding first_domain_in_cpupool() is a good way to go.
Sending out adjusted patch with appropriate locking added in
cpupool_unassign_cpu() soon.


Juergen

--
Juergen Gross                 Principal Developer Operating Systems
PDG ES&S SWE OS6                       Telephone: +49 (0) 89 3222 2967
Fujitsu Technology Solutions              e-mail: juergen.gross@xxxxxxxxxxxxxx
Domagkstr. 28                           Internet: ts.fujitsu.com
D-80807 Muenchen                 Company details: ts.fujitsu.com/imprint.html


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel