Re: [Xen-devel] [RFC] linux: add p[mug]d_clear_full() accessors

[Jeremy Fitzhardinge <jeremy@xxxxxxxx>]

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