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] [RFC] linux: add p[mug]d_clear_full() accessors

To: "Jeremy Fitzhardinge" <jeremy@xxxxxxxx>
Subject: Re: [Xen-devel] [RFC] linux: add p[mug]d_clear_full() accessors
From: "Jan Beulich" <jbeulich@xxxxxxxxxx>
Date: Wed, 21 May 2008 07:47:29 +0100
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Tue, 20 May 2008 23:47:26 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <48332E7B.7000407@xxxxxxxx>
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/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <4832FF91.76E4.0078.0@xxxxxxxxxx> <4832EB8F.8010405@xxxxxxxx> <48331043.76E4.0078.0@xxxxxxxxxx> <48332E7B.7000407@xxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
>> One question though - in our 2.6.23 merge (where pv-ops-Xen's
>> PG_pinned appeared as an alias of PG_owner_priv_1, and where
>> PG_arch_1 got assigned a meaning for native x86, so PG_pinned
>> for the traditional patches needed to change anyway) I intentionally
>> didn't follow pv-ops for our patches, since PG_pinned is among the
>> flags bad_page() checks for (in the XenSource tree, and I think this
>> should really also be done in upstream Linux), and hence re-using
>> the bit here would change behavior for other parts of the kernel.
>
>I don't think so.  So long as its clear by the time you free the page, 
>it doesn't matter how it gets used in the meantime (after all, you 
>should never free a pinned pagetable page).

But isn't that one of the purposes of those page flags checks - checking
whether e.g. a page may validly get freed (free_pages_check())? All
of bad_page(), free_pages_check(), and prep_new_page() currently
add PG_pinned into the set of flags cleared/checked, and I continue to
think that that is the right thing to do.

Jan


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