Re: [Xen-devel] What's the reason for padding the alloc_bitmap in page_alloc.c?

[Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>]

On 5/8/06 4:55 am, "Steven Rostedt" <srostedt@xxxxxxxxxx> wrote:

> I see the code in init_boot_allocator that added an extra longword to
> the size of alloc_bitmap.  Is there really a chance for overrun in
> map_alloc or map_free as the comment suggests?  I would think that
> allocating or freeing more than we have would be considered a bug.  I
> don't know the history of that padding but I wonder if it is from
> another overflow that is fixable.  Doing bitmap_size = (max_page + 7)/8
> should be enough.

There are plenty of places that can look one page (bit) beyond the end of
the map:
 1. Map_alloc and map_free set end_idx/offset as first_page + nr_pages. This
clearly references the first page *after* the range of interest. What if
that range ends on max_page-1?
 2. Free_heap_pages checks neighbouring pages of the freed range for
potential opportunities to merge to a higher-order buddy list. What if the
last page of the range being freed is max_page-1?

However, I think the bitmap allocation could be made a bit tighter. Perhaps:
   bitmap_size = round_pgup(max_page/8 + 1);
This rounds down to bytes, but then adds an extra byte so that we can always
go one off the end of the bitmap (really it's just a simplification of
(max_page + 1 + 7) / 8). How does that sound?

NB. Going off the start of the bitmap is never a problem, since page 0 is
never available for allocation. :-)

 -- Keir



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