From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from kirsty.vergenet.net ([202.4.237.240]) by merlin.infradead.org with esmtp (Exim 4.80.1 #2 (Red Hat Linux)) id 1VOct9-0001Gc-0B for kexec@lists.infradead.org; Wed, 25 Sep 2013 00:23:32 +0000 Date: Wed, 25 Sep 2013 09:23:04 +0900 From: Simon Horman Subject: Re: [PATCH] [RFC] kexec: Fix off-by-one errors in locate_hole() Message-ID: <20130925002304.GE26081@verge.net.au> References: <1379924292-1712-1-git-send-email-geert@linux-m68k.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <1379924292-1712-1-git-send-email-geert@linux-m68k.org> List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "kexec" Errors-To: kexec-bounces+dwmw2=twosheds.infradead.org@lists.infradead.org To: Geert Uytterhoeven Cc: kexec@lists.infradead.org On Mon, Sep 23, 2013 at 10:18:12AM +0200, Geert Uytterhoeven wrote: > When calling locate_hole() with "hole_size" equal to the size of an > available memory block, it fails to use that memory block. > > "end" and "hole_max" point to the last byte within the range, hence > - "size = end - start" is one less than "hole_size", > - "hole_base + hole_size" is one more than "hole_max". > > Subtract one from "hole_size" when doing the comparison (adding 1 to "size" > could overflow in case of one big range covering the whole address space). > > Signed-off-by: Geert Uytterhoeven > --- > Question: > The code no longer handles the case where "hole_size" is zero. > Should this be rejected (like is done for a zero "hole_end" at the top > of the function), or accepted? Either way would be fine by me though I lean towards accepting it. > > kexec/kexec.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/kexec/kexec.c b/kexec/kexec.c > index 2b98ef0..eafd6c2 100644 > --- a/kexec/kexec.c > +++ b/kexec/kexec.c > @@ -270,7 +270,7 @@ unsigned long locate_hole(struct kexec_info *info, > } > /* Is there enough space left so we can use it? */ > size = end - start; > - if (size >= hole_size) { > + if (size >= hole_size - 1) { > if (hole_end > 0) { > hole_base = start; > break; > @@ -286,7 +286,7 @@ unsigned long locate_hole(struct kexec_info *info, > "0x%lx bytes...\n", hole_size); > return ULONG_MAX; > } > - if ((hole_base + hole_size) > hole_max) { > + if ((hole_base + hole_size - 1) > hole_max) { > fprintf(stderr, "Could not find a free area of memory below: " > "0x%lx...\n", hole_max); > return ULONG_MAX; > -- > 1.7.9.5 > _______________________________________________ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec