Kexec Archive on lore.kernel.org
 help / color / mirror / Atom feed
* PATCH: bug in locate_hole()
@ 2014-03-04  0:34 Matthew Fleming
  2014-03-04  4:03 ` Simon Horman
  2014-03-05  2:52 ` Matthew Fleming
  0 siblings, 2 replies; 6+ messages in thread
From: Matthew Fleming @ 2014-03-04  0:34 UTC (permalink / raw)
  To: kexec

[-- Attachment #1: Type: text/plain, Size: 868 bytes --]

In upgrading to kexec-tools 2.0.5 I first got the error "Overlapping
memory segments at 0xbeff000"

Adding some debugging I found locate_hole was returning incorrect
values.  The below is from the debug I added:

XXXMDF: look for hole size 100000, cur range [52b3000, bffffff] size 6d4cfff
XXXMDF: look for hole memsz=100000, found beff000

Hmm, if we wanted 0x100000 bytes ending at 0xbffffff, that should be
0xbf00000, not 0xbef000.  Continuing to the second invocation:

XXXMDF: look for hole size 1000, cur range [52b3000, befefff] size 6c4bfff
XXXMDF: look for hole size 1000, cur range [bfff000, bffffff] size fff
XXXMDF: look for hole memsz=1000, found bffe000

Now we die with overlapping ranges, since the 0x100000 bytes at
0xbeff000 overlaps 0x1000 bytes at 0xbffe000.

The attached patch fixes the off-by-one that causes the later overlap.

Thanks,
matthew

[-- Attachment #2: kexec-locate-hole.diff --]
[-- Type: text/plain, Size: 644 bytes --]

--- kexec.c.orig	2014-03-03 16:08:53.289844106 -0800
+++ kexec.c	2014-03-03 16:09:04.960844107 -0800
@@ -272,17 +272,17 @@ unsigned long locate_hole(struct kexec_i
 		}
 		/* Is there enough space left so we can use it? */
 		size = end - start;
 		if (!hole_size || size >= hole_size - 1) {
 			if (hole_end > 0) {
 				hole_base = start;
 				break;
 			} else {
-				hole_base = _ALIGN_DOWN(end - hole_size,
+				hole_base = _ALIGN_DOWN(end - hole_size + 1,
 					hole_align);
 			}
 		}
 	}
 	free(mem_range);
 	if (hole_base == ULONG_MAX) {
 		fprintf(stderr, "Could not find a free area of memory of "
 			"0x%lx bytes...\n", hole_size);

[-- Attachment #3: Type: text/plain, Size: 143 bytes --]

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

^ permalink raw reply	[flat|nested] 6+ messages in thread
* Re: PATCH: bug in locate_hole()
  2014-03-04  0:34 PATCH: bug in locate_hole() Matthew Fleming
@ 2014-03-04  4:03 ` Simon Horman
  2014-03-04 14:55   ` Matthew Fleming
  2014-03-05  2:52 ` Matthew Fleming
  1 sibling, 1 reply; 6+ messages in thread
From: Simon Horman @ 2014-03-04  4:03 UTC (permalink / raw)
  To: Matthew Fleming; +Cc: kexec

Thanks Matthew.

Could you provide a signed-off-by line?

On Mon, Mar 03, 2014 at 04:34:35PM -0800, Matthew Fleming wrote:
> In upgrading to kexec-tools 2.0.5 I first got the error "Overlapping
> memory segments at 0xbeff000"
> 
> Adding some debugging I found locate_hole was returning incorrect
> values.  The below is from the debug I added:
> 
> XXXMDF: look for hole size 100000, cur range [52b3000, bffffff] size 6d4cfff
> XXXMDF: look for hole memsz=100000, found beff000
> 
> Hmm, if we wanted 0x100000 bytes ending at 0xbffffff, that should be
> 0xbf00000, not 0xbef000.  Continuing to the second invocation:
> 
> XXXMDF: look for hole size 1000, cur range [52b3000, befefff] size 6c4bfff
> XXXMDF: look for hole size 1000, cur range [bfff000, bffffff] size fff
> XXXMDF: look for hole memsz=1000, found bffe000
> 
> Now we die with overlapping ranges, since the 0x100000 bytes at
> 0xbeff000 overlaps 0x1000 bytes at 0xbffe000.
> 
> The attached patch fixes the off-by-one that causes the later overlap.
> 
> Thanks,
> matthew

> --- kexec.c.orig	2014-03-03 16:08:53.289844106 -0800
> +++ kexec.c	2014-03-03 16:09:04.960844107 -0800
> @@ -272,17 +272,17 @@ unsigned long locate_hole(struct kexec_i
>  		}
>  		/* Is there enough space left so we can use it? */
>  		size = end - start;
>  		if (!hole_size || size >= hole_size - 1) {
>  			if (hole_end > 0) {
>  				hole_base = start;
>  				break;
>  			} else {
> -				hole_base = _ALIGN_DOWN(end - hole_size,
> +				hole_base = _ALIGN_DOWN(end - hole_size + 1,
>  					hole_align);
>  			}
>  		}
>  	}
>  	free(mem_range);
>  	if (hole_base == ULONG_MAX) {
>  		fprintf(stderr, "Could not find a free area of memory of "
>  			"0x%lx bytes...\n", hole_size);

> _______________________________________________
> kexec mailing list
> kexec@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec


_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

^ permalink raw reply	[flat|nested] 6+ messages in thread
* Re: PATCH: bug in locate_hole()
  2014-03-04  4:03 ` Simon Horman
@ 2014-03-04 14:55   ` Matthew Fleming
  2014-03-05  1:24     ` Baoquan He
  0 siblings, 1 reply; 6+ messages in thread
From: Matthew Fleming @ 2014-03-04 14:55 UTC (permalink / raw)
  To: Simon Horman; +Cc: kexec

On Mon, Mar 3, 2014 at 8:03 PM, Simon Horman <horms@verge.net.au> wrote:
> Thanks Matthew.
>
> Could you provide a signed-off-by line?

I'm not sure what that would look like.  Do I sign off on my own patch?

Thanks,
matthew


> On Mon, Mar 03, 2014 at 04:34:35PM -0800, Matthew Fleming wrote:
>> In upgrading to kexec-tools 2.0.5 I first got the error "Overlapping
>> memory segments at 0xbeff000"
>>
>> Adding some debugging I found locate_hole was returning incorrect
>> values.  The below is from the debug I added:
>>
>> XXXMDF: look for hole size 100000, cur range [52b3000, bffffff] size 6d4cfff
>> XXXMDF: look for hole memsz=100000, found beff000
>>
>> Hmm, if we wanted 0x100000 bytes ending at 0xbffffff, that should be
>> 0xbf00000, not 0xbef000.  Continuing to the second invocation:
>>
>> XXXMDF: look for hole size 1000, cur range [52b3000, befefff] size 6c4bfff
>> XXXMDF: look for hole size 1000, cur range [bfff000, bffffff] size fff
>> XXXMDF: look for hole memsz=1000, found bffe000
>>
>> Now we die with overlapping ranges, since the 0x100000 bytes at
>> 0xbeff000 overlaps 0x1000 bytes at 0xbffe000.
>>
>> The attached patch fixes the off-by-one that causes the later overlap.
>>
>> Thanks,
>> matthew
>
>> --- kexec.c.orig      2014-03-03 16:08:53.289844106 -0800
>> +++ kexec.c   2014-03-03 16:09:04.960844107 -0800
>> @@ -272,17 +272,17 @@ unsigned long locate_hole(struct kexec_i
>>               }
>>               /* Is there enough space left so we can use it? */
>>               size = end - start;
>>               if (!hole_size || size >= hole_size - 1) {
>>                       if (hole_end > 0) {
>>                               hole_base = start;
>>                               break;
>>                       } else {
>> -                             hole_base = _ALIGN_DOWN(end - hole_size,
>> +                             hole_base = _ALIGN_DOWN(end - hole_size + 1,
>>                                       hole_align);
>>                       }
>>               }
>>       }
>>       free(mem_range);
>>       if (hole_base == ULONG_MAX) {
>>               fprintf(stderr, "Could not find a free area of memory of "
>>                       "0x%lx bytes...\n", hole_size);
>
>> _______________________________________________
>> kexec mailing list
>> kexec@lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/kexec
>

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

^ permalink raw reply	[flat|nested] 6+ messages in thread
* Re: PATCH: bug in locate_hole()
  2014-03-04 14:55   ` Matthew Fleming
@ 2014-03-05  1:24     ` Baoquan He
  0 siblings, 0 replies; 6+ messages in thread
From: Baoquan He @ 2014-03-05  1:24 UTC (permalink / raw)
  To: Matthew Fleming; +Cc: Simon Horman, kexec

On 03/04/14 at 06:55am, Matthew Fleming wrote:
> On Mon, Mar 3, 2014 at 8:03 PM, Simon Horman <horms@verge.net.au> wrote:
> > Thanks Matthew.
> >
> > Could you provide a signed-off-by line?
> 
> I'm not sure what that would look like.  Do I sign off on my own patch?
> 
> Thanks,
> matthew

It's a convention for submitting patch, you can refer to this doc:
https://www.kernel.org/doc/Documentation/SubmittingPatches

Abstract part of them and paste here:

12) Sign your work

To improve tracking of who did what, especially with patches that can
percolate to their final resting place in the kernel through several
layers of maintainers, we've introduced a "sign-off" procedure on
patches that are being emailed around.

The sign-off is a simple line at the end of the explanation for the
patch, which certifies that you wrote it or otherwise have the right to
pass it on as an open-source patch.  The rules are pretty simple: if you
can certify the below:


Baoquan
Thanks

> 
> 
> > On Mon, Mar 03, 2014 at 04:34:35PM -0800, Matthew Fleming wrote:
> >> In upgrading to kexec-tools 2.0.5 I first got the error "Overlapping
> >> memory segments at 0xbeff000"
> >>
> >> Adding some debugging I found locate_hole was returning incorrect
> >> values.  The below is from the debug I added:
> >>
> >> XXXMDF: look for hole size 100000, cur range [52b3000, bffffff] size 6d4cfff
> >> XXXMDF: look for hole memsz=100000, found beff000
> >>
> >> Hmm, if we wanted 0x100000 bytes ending at 0xbffffff, that should be
> >> 0xbf00000, not 0xbef000.  Continuing to the second invocation:
> >>
> >> XXXMDF: look for hole size 1000, cur range [52b3000, befefff] size 6c4bfff
> >> XXXMDF: look for hole size 1000, cur range [bfff000, bffffff] size fff
> >> XXXMDF: look for hole memsz=1000, found bffe000
> >>
> >> Now we die with overlapping ranges, since the 0x100000 bytes at
> >> 0xbeff000 overlaps 0x1000 bytes at 0xbffe000.
> >>
> >> The attached patch fixes the off-by-one that causes the later overlap.
> >>
> >> Thanks,
> >> matthew
> >
> >> --- kexec.c.orig      2014-03-03 16:08:53.289844106 -0800
> >> +++ kexec.c   2014-03-03 16:09:04.960844107 -0800
> >> @@ -272,17 +272,17 @@ unsigned long locate_hole(struct kexec_i
> >>               }
> >>               /* Is there enough space left so we can use it? */
> >>               size = end - start;
> >>               if (!hole_size || size >= hole_size - 1) {
> >>                       if (hole_end > 0) {
> >>                               hole_base = start;
> >>                               break;
> >>                       } else {
> >> -                             hole_base = _ALIGN_DOWN(end - hole_size,
> >> +                             hole_base = _ALIGN_DOWN(end - hole_size + 1,
> >>                                       hole_align);
> >>                       }
> >>               }
> >>       }
> >>       free(mem_range);
> >>       if (hole_base == ULONG_MAX) {
> >>               fprintf(stderr, "Could not find a free area of memory of "
> >>                       "0x%lx bytes...\n", hole_size);
> >
> >> _______________________________________________
> >> kexec mailing list
> >> kexec@lists.infradead.org
> >> http://lists.infradead.org/mailman/listinfo/kexec
> >
> 
> _______________________________________________
> kexec mailing list
> kexec@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

^ permalink raw reply	[flat|nested] 6+ messages in thread
* Re: PATCH: bug in locate_hole()
  2014-03-04  0:34 PATCH: bug in locate_hole() Matthew Fleming
  2014-03-04  4:03 ` Simon Horman
@ 2014-03-05  2:52 ` Matthew Fleming
  2014-03-06  2:17   ` Simon Horman
  1 sibling, 1 reply; 6+ messages in thread
From: Matthew Fleming @ 2014-03-05  2:52 UTC (permalink / raw)
  To: kexec

On Mon, Mar 3, 2014 at 4:34 PM, Matthew Fleming <mdf356@gmail.com> wrote:
> In upgrading to kexec-tools 2.0.5 I first got the error "Overlapping
> memory segments at 0xbeff000"
>
> Adding some debugging I found locate_hole was returning incorrect
> values.  The below is from the debug I added:
>
> XXXMDF: look for hole size 100000, cur range [52b3000, bffffff] size 6d4cfff
> XXXMDF: look for hole memsz=100000, found beff000
>
> Hmm, if we wanted 0x100000 bytes ending at 0xbffffff, that should be
> 0xbf00000, not 0xbef000.  Continuing to the second invocation:
>
> XXXMDF: look for hole size 1000, cur range [52b3000, befefff] size 6c4bfff
> XXXMDF: look for hole size 1000, cur range [bfff000, bffffff] size fff
> XXXMDF: look for hole memsz=1000, found bffe000
>
> Now we die with overlapping ranges, since the 0x100000 bytes at
> 0xbeff000 overlaps 0x1000 bytes at 0xbffe000.
>
> The attached patch fixes the off-by-one that causes the later overlap.

Fix an off-by-one in locate_hole() that can cause it to return a range
that was previously allocated.

Signed-off-by: Matthew Fleming <mdf356@gmail.com>

Cheers,
matthew

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

^ permalink raw reply	[flat|nested] 6+ messages in thread
* Re: PATCH: bug in locate_hole()
  2014-03-05  2:52 ` Matthew Fleming
@ 2014-03-06  2:17   ` Simon Horman
  0 siblings, 0 replies; 6+ messages in thread
From: Simon Horman @ 2014-03-06  2:17 UTC (permalink / raw)
  To: Matthew Fleming; +Cc: kexec

On Tue, Mar 04, 2014 at 06:52:17PM -0800, Matthew Fleming wrote:
> On Mon, Mar 3, 2014 at 4:34 PM, Matthew Fleming <mdf356@gmail.com> wrote:
> > In upgrading to kexec-tools 2.0.5 I first got the error "Overlapping
> > memory segments at 0xbeff000"
> >
> > Adding some debugging I found locate_hole was returning incorrect
> > values.  The below is from the debug I added:
> >
> > XXXMDF: look for hole size 100000, cur range [52b3000, bffffff] size 6d4cfff
> > XXXMDF: look for hole memsz=100000, found beff000
> >
> > Hmm, if we wanted 0x100000 bytes ending at 0xbffffff, that should be
> > 0xbf00000, not 0xbef000.  Continuing to the second invocation:
> >
> > XXXMDF: look for hole size 1000, cur range [52b3000, befefff] size 6c4bfff
> > XXXMDF: look for hole size 1000, cur range [bfff000, bffffff] size fff
> > XXXMDF: look for hole memsz=1000, found bffe000
> >
> > Now we die with overlapping ranges, since the 0x100000 bytes at
> > 0xbeff000 overlaps 0x1000 bytes at 0xbffe000.
> >
> > The attached patch fixes the off-by-one that causes the later overlap.
> 
> Fix an off-by-one in locate_hole() that can cause it to return a range
> that was previously allocated.
> 
> Signed-off-by: Matthew Fleming <mdf356@gmail.com>

Thanks. I have applied the following:


From: Matthew Fleming <mdf356@gmail.com>

Fix an off-by-one in locate_hole()

Fix an off-by-one in locate_hole() that can cause it to return a range
that was previously allocated.

In upgrading to kexec-tools 2.0.5 I first got the error "Overlapping
memory segments at 0xbeff000"

Adding some debugging I found locate_hole was returning incorrect
values.  The below is from the debug I added:

XXXMDF: look for hole size 100000, cur range [52b3000, bffffff] size 6d4cfff
XXXMDF: look for hole memsz=100000, found beff000

Hmm, if we wanted 0x100000 bytes ending at 0xbffffff, that should be
0xbf00000, not 0xbef000.  Continuing to the second invocation:

XXXMDF: look for hole size 1000, cur range [52b3000, befefff] size 6c4bfff
XXXMDF: look for hole size 1000, cur range [bfff000, bffffff] size fff
XXXMDF: look for hole memsz=1000, found bffe000

Now we die with overlapping ranges, since the 0x100000 bytes at
0xbeff000 overlaps 0x1000 bytes at 0xbffe000.

Signed-off-by: Matthew Fleming <mdf356@gmail.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
---
 kexec/kexec.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kexec/kexec.c b/kexec/kexec.c
index 703d524..382f86a 100644
--- a/kexec/kexec.c
+++ b/kexec/kexec.c
@@ -275,7 +275,7 @@ unsigned long locate_hole(struct kexec_info *info,
 				hole_base = start;
 				break;
 			} else {
-				hole_base = _ALIGN_DOWN(end - hole_size,
+				hole_base = _ALIGN_DOWN(end - hole_size + 1,
 					hole_align);
 			}
 		}
-- 
1.8.5.2


_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

^ permalink raw reply related	[flat|nested] 6+ messages in thread
end of thread, other threads:[~2014-03-06  2:18 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2014-03-04  0:34 PATCH: bug in locate_hole() Matthew Fleming
2014-03-04  4:03 ` Simon Horman
2014-03-04 14:55   ` Matthew Fleming
2014-03-05  1:24     ` Baoquan He
2014-03-05  2:52 ` Matthew Fleming
2014-03-06  2:17   ` Simon Horman

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox