I can''t make heads nor tails (pun intended) of how to use the new page_list_* macros. I have created a page_list but at some point when I try to do a page_list_remove_head() on the list (which, yes, had been initialized -- statically), the list has been corrupted (causing a bad pointer dereference). Is the memory where the list header is stored overloaded and sometimes overwritten for other purposes? Note all pages on my page_list have been gotten via pi=alloc_domheap_pages(0,0,0). Next I use va=page_to_virt(pi), use the page for awhile, use pi=virt_to_page(va) and put it on the page_list, then later when I page_list_remove_head(my_page_list), the list pointers are apparently corrupt. Any ideas? Thanks, Dan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 12/02/2009 03:42, "Dan Magenheimer" <dan.magenheimer@oracle.com> wrote:> Is the memory where the list header is stored overloaded and > sometimes overwritten for other purposes? Note all pages > on my page_list have been gotten via pi=alloc_domheap_pages(0,0,0). > Next I use va=page_to_virt(pi), use the page for awhile, > use pi=virt_to_page(va) and put it on the page_list, then > later when I page_list_remove_head(my_page_list), the > list pointers are apparently corrupt.So long as you allocate anonymous domheap memory, or xenheap memory, the page_list fields should belong to you. The list structure is pretty simple and I can''t see anything wrong with the macros. An empty list is noted by NULL head/tail pointers, otherwise point at head/tail pages within which next/prev pointers are 32-bit MFNs. The head and tail pages do not point at the page_list_head but instead contain ~0 sentinel next/prev link values. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
>>> Dan Magenheimer <dan.magenheimer@oracle.com> 12.02.09 04:42 >>> >Is the memory where the list header is stored overloaded and >sometimes overwritten for other purposes? Note all pagesThe list headers are not overloaded in any way. The list entries do have an overlay union field, used only by shadow code (so your code would need to make use of it explicitly, which I doubt). So according to your description of how you use the page I can''t see any potential for corruption. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Thanks for the replies. It seems it''s not a good idea to put a page into a page_list when it''s already there (among thousands of other list entries). :-} :-} That resulted in all sorts of interesting symptoms! Took me all day to track down my problem, but I think I nailed it. Dan> > Is the memory where the list header is stored overloaded and > > sometimes overwritten for other purposes? Note all pages > > on my page_list have been gotten via pi=alloc_domheap_pages(0,0,0). > > Next I use va=page_to_virt(pi), use the page for awhile, > > use pi=virt_to_page(va) and put it on the page_list, then > > later when I page_list_remove_head(my_page_list), the > > list pointers are apparently corrupt. > > So long as you allocate anonymous domheap memory, or xenheap > memory, the > page_list fields should belong to you. The list structure is > pretty simple > and I can''t see anything wrong with the macros. An empty list > is noted by > NULL head/tail pointers, otherwise point at head/tail pages > within which > next/prev pointers are 32-bit MFNs. The head and tail pages > do not point at > the page_list_head but instead contain ~0 sentinel next/prev > link values. > > -- Keir> >>> Dan Magenheimer <dan.magenheimer@oracle.com> 12.02.09 04:42 >>> > >Is the memory where the list header is stored overloaded and > >sometimes overwritten for other purposes? Note all pages > > The list headers are not overloaded in any way. The list > entries do have > an overlay union field, used only by shadow code (so your code would > need to make use of it explicitly, which I doubt). > > So according to your description of how you use the page I > can''t see any > potential for corruption. > > Jan_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel