From: David Hopwood <david.nospam.hopwood@blueyonder.co.uk>
To: xen-devel@lists.sourceforge.net
Subject: Re: [PATCH] Trivial fix for latent bug in page_alloc.c
Date: Wed, 19 Jan 2005 16:45:50 +0000 [thread overview]
Message-ID: <41EE8EBE.2080900@blueyonder.co.uk> (raw)
In-Reply-To: <1106106821.20879.14.camel@localhost.localdomain>
Rusty Russell wrote:
> Was reading through page_alloc.c, and the "find smallest order" loop
> assumes MIN_ORDER is 0. Easiest fix is to get rid of "MIN_ORDER" and
> hence NR_ORDERS, and simplify code.
>
> Rusty.
>
> --- xen/common/page_alloc.c.~1~ 2005-01-11 15:35:54.000000000 +1100
> +++ xen/common/page_alloc.c 2005-01-19 14:51:47.000000000 +1100
> @@ -203,10 +203,8 @@
> #define NR_ZONES 2
>
> /* Up to 2^10 pages can be allocated at once. */
> -#define MIN_ORDER 0
> #define MAX_ORDER 10
> -#define NR_ORDERS (MAX_ORDER - MIN_ORDER + 1)
> -static struct list_head heap[NR_ZONES][NR_ORDERS];
> +static struct list_head heap[NR_ZONES][MAX_ORDER];
This patch is broken because it replaces NR_ORDERS with MAX_ORDER,
not with MAX_ORDER+1.
#define MAX_ORDER 10
static struct list_head heap[NR_ZONES][MAX_ORDER+1];
> static unsigned long avail[NR_ZONES];
>
> @@ -220,7 +218,7 @@
> memset(avail, 0, sizeof(avail));
>
> for ( i = 0; i < NR_ZONES; i++ )
> - for ( j = 0; j < NR_ORDERS; j++ )
> + for ( j = 0; j < MAX_ORDER; j++ )
for ( j = 0; j <= MAX_ORDER; j++ )
> INIT_LIST_HEAD(&heap[i][j]);
>
> /* Pages that are free now go to the domain sub-allocator. */
> @@ -251,17 +249,18 @@
> int i;
> struct pfn_info *pg;
>
> - if ( unlikely(order < MIN_ORDER) || unlikely(order > MAX_ORDER) )
> + ASSERT(order >= 0);
> + if ( unlikely(order >= MAX_ORDER) )
> return NULL;
Why is it valid to change 'return NULL' to a failed ASSERT?
Also changing > to >= is wrong.
if ( unlikely(order < 0) || unlikely(order > MAX_ORDER) )
return NULL;
> spin_lock(&heap_lock);
>
> /* Find smallest order which can satisfy the request. */
> - for ( i = order; i < NR_ORDERS; i++ )
> + for ( i = order; i < MAX_ORDER; i++ )
for ( i = order; i <= MAX_ORDER; i++ )
> if ( !list_empty(&heap[zone][i]) )
> break;
>
> - if ( i == NR_ORDERS )
> + if ( i == MAX_ORDER )
if ( i > MAX_ORDER)
> goto no_memory;
>
> pg = list_entry(heap[zone][i].next, struct pfn_info, list);
--
David Hopwood <david.nospam.hopwood@blueyonder.co.uk>
-------------------------------------------------------
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
next prev parent reply other threads:[~2005-01-19 16:45 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-01-19 3:53 [PATCH] Trivial fix for latent bug in page_alloc.c Rusty Russell
2005-01-19 7:51 ` Keir Fraser
2005-01-19 16:45 ` David Hopwood [this message]
2005-02-02 4:12 ` Rusty Russell
2005-02-02 23:31 ` David Hopwood
2005-02-08 2:32 ` Rusty Russell
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=41EE8EBE.2080900@blueyonder.co.uk \
--to=david.nospam.hopwood@blueyonder.co.uk \
--cc=xen-devel@lists.sourceforge.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.