crash in page_list_* macro

crash in page_list_* macro

[Dan Magenheimer]

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

Re: crash in page_list_* macro

[Keir Fraser]

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

Re: crash in page_list_* macro

[Jan Beulich]

>>> 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

RE: crash in page_list_* macro

[Dan Magenheimer]

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