[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Xen-devel] free_domheap_pages() leaking xenheap pages?


  • To: Xen Developers <xen-devel@xxxxxxxxxxxxxxxxxxx>
  • From: Daniel Stodden <stodden@xxxxxxxxxx>
  • Date: Tue, 23 Jan 2007 17:25:02 +0100
  • Delivery-date: Tue, 23 Jan 2007 08:26:05 -0800
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>

hi.

maybe someone can help me out with the xenheap page allocator in
combination with shared pages?

the following is from page_alloc.c:

void free_domheap_pages(struct page_info *pg, unsigned int order)
{
    int            i, drop_dom_ref;
    struct domain *d = page_get_owner(pg);

    ASSERT(!in_irq());

    if ( unlikely(IS_XEN_HEAP_FRAME(pg)) )
    {
        /* NB. May recursively lock from relinquish_memory(). */
        spin_lock_recursive(&d->page_alloc_lock);

        for ( i = 0; i < (1 << order); i++ )
            list_del(&pg[i].list);

        d->xenheap_pages -= 1 << order;
        drop_dom_ref = (d->xenheap_pages == 0);

        spin_unlock_recursive(&d->page_alloc_lock);
        [XXX]
    }
    else [..]


i would have expected something ultimately turning into a

        free_heap_pages( MEMZONE_XEN, pg, order )

to occur at point [XXX].

the page range remains unlisted upon return, and if there's any later
point in the domain life cycle where these pages would ever return to
the xen heap, i'm unable to find it.

background: i'm writing code supposed to communicate with dom0 via a
number of shared pages. pseudocode:
 
my_init( something )
{
        something->pg = alloc_xenheap_page();
        share_xen_page_with_privileged_guests( virt_to_page(pg), ... );
}

my_uninit( something )
{
        put_page_and_type( something->pg );
}

is the latter put_page_and_type() correct? i'm asking because it seems
obvious, while xenoprof appears to do similar things with xen_heap, but
in a much stranger fashion when it comes to freeing those pages.

regards,
daniel


-- 
Daniel Stodden
LRR     -      Lehrstuhl fÃr Rechnertechnik und Rechnerorganisation
Institut fÃr Informatik der TU MÃnchen             D-85748 Garching
http://www.lrr.in.tum.de/~stodden         mailto:stodden@xxxxxxxxxx
PGP Fingerprint: F5A4 1575 4C56 E26A 0B33  3D80 457E 82AE B0D8 735B

Attachment: signature.asc
Description: This is a digitally signed message part

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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.