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: Jan Beulich <jbeulich@xxxxxxxxxx>
Subject: Re: [Xen-devel] [RFC] linux: add p[mug]d_clear_full() accessors
From: Jeremy Fitzhardinge <jeremy@xxxxxxxx>
Date: Wed, 21 May 2008 10:02:25 +0100
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Wed, 21 May 2008 02:03:17 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <4833E1A1.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/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> <4833E1A1.76E4.0078.0@xxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Thunderbird 2.0.0.14 (X11/20080501)
Jan Beulich wrote:
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.

Well, yes, it would be helpful for free_pages_check to test whether PG_owner_priv_1 is set on a page you're attempting to free, since that would definitely be a bug. But its also a bug which would turn up fairly quickly anyway, since Xen would complain about any subsequent users of that page. Regardless, its not actually a bug that has turned up, since the lifespan of pagetable pages is pretty well controlled, and there's only a couple of places where they get allocated and freed.

So, not a big issue either way, I think.

   J

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