This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: [Xen-devel] What's the reason for padding the alloc_bitmap in page_a

To: Steven Rostedt <srostedt@xxxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: Re: [Xen-devel] What's the reason for padding the alloc_bitmap in page_alloc.c?
From: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
Date: Sat, 05 Aug 2006 10:05:45 +0100
Delivery-date: Sat, 05 Aug 2006 02:14:21 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <44D416A3.9040103@xxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: Aca4blWtlFcW0iRhEduqRAANk04WTA==
Thread-topic: [Xen-devel] What's the reason for padding the alloc_bitmap in page_alloc.c?
User-agent: Microsoft-Entourage/
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

<Prev in Thread] Current Thread [Next in Thread>