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] page ref/type count overflows

To: Jan Beulich <jbeulich@xxxxxxxxxx>, Gianluca Guida <gianluca.guida@xxxxxxxxxxxxx>, Tim Deegan <Tim.Deegan@xxxxxxxxxxxxx>
Subject: Re: [Xen-devel] page ref/type count overflows
From: Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
Date: Thu, 29 Jan 2009 08:45:32 +0000
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Thu, 29 Jan 2009 00:46:12 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <4981782A.76E4.0078.0@xxxxxxxxxx>
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>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcmB7fHBBUFMT038T0eSkfKvoWkfOg==
Thread-topic: [Xen-devel] page ref/type count overflows
User-agent: Microsoft-Entourage/12.10.0.080409
On 29/01/2009 08:34, "Jan Beulich" <jbeulich@xxxxxxxxxx> wrote:

>>>> Keir Fraser <keir.fraser@xxxxxxxxxxxxx> 27.01.09 11:24 >>>
>> On 27/01/2009 10:16, "Jan Beulich" <jbeulich@xxxxxxxxxx> wrote:
>>> And shouldn't shadow's count field also be widened to BITS_PER_LONG-6?
>> 
>> Would be nice. Hopefully either Tim or Gianluca will see to that.
> 
> Actually, I'd like to go a step further: Is there any reason why struct
> shadow_page_info must be separate from struct page_info (rather than
> sharing the definition, requiring some re-ordering of its elements)?

Not really, apart from wanting to keep shadow stuff in one place in a
private header file, I suppose. Would it risk turning page_info's definition
into crazy union soup? If it could be done as something like:
 unsigned long count_info
 union {
  struct { page_info stuff }; // anonymous
  struct { sh_page_info stuff }; // anonymous
 } // anonymous
That would be nicer than what we currently have, I'd agree. And the more
stuff we can pull out of the anonymous union (e.g., perhaps a list_head?)
then the better, of course.

 -- Keir



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