* 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