* Re: 2.6.19-rc1: kexec broken on x86_64
2006-10-05 13:56 ` Magnus Damm
@ 2006-10-05 14:24 ` Vivek Goyal
2006-10-05 15:17 ` Eric W. Biederman
2006-10-05 14:33 ` Eric W. Biederman
2006-10-05 16:33 ` Vivek Goyal
2 siblings, 1 reply; 8+ messages in thread
From: Vivek Goyal @ 2006-10-05 14:24 UTC (permalink / raw)
To: Magnus Damm
Cc: Linux Kernel Mailing List, fastboot, Eric W. Biederman, Horms,
Magnus Damm, Andi Kleen
On Thu, Oct 05, 2006 at 10:56:51PM +0900, Magnus Damm wrote:
> Hi Vivek,
>
> On 10/5/06, Vivek Goyal <vgoyal@in.ibm.com> wrote:
> >On Thu, Oct 05, 2006 at 07:28:35PM +0900, Magnus Damm wrote:
> >> Kexec is broken on x86_64 under 2.6.19-rc1.
> >>
> >> Or rather - kexec works ok under 2.6.19-rc1, but something related to
> >> the vmlinux format has probably changed and kexec-tools fails to load
> >> a vmlinux from 2.6.19-rc1.
> >>
> >> Loading bzImage works as usual, but vmlinux does not load properly.
> >>
> >> The kexec binary fails with the following message:
> >>
> >> Overlapping memory segments at 0x351000
> >> sort_segments failed
> >> / #
> >>
> >
> >Hi Magnus,
> >
> >Can you please post the readelf -l output of the vmlinux you are trying
> >to load. That's will give some indication if the segments are really
> >overlapping in vmlinux or is it some processing bug at kexec-tools part.
>
> Elf file type is EXEC (Executable file)
> Entry point 0x100100
> There are 4 program headers, starting at offset 64
>
> Program Headers:
> Type Offset VirtAddr PhysAddr
> FileSiz MemSiz Flags Align
> LOAD 0x0000000000100000 0xffffffff80100000 0x0000000000100000
> 0x00000000001a4888 0x00000000001a4888 R E 100000
> LOAD 0x00000000002a5000 0xffffffff802a5000 0x00000000002a5000
> 0x000000000008e086 0x00000000000c1504 RWE 100000
> LOAD 0x0000000000400000 0xffffffffff600000 0x00000000002fd000
> 0x0000000000000c08 0x0000000000000c08 RWE 100000
> NOTE 0x0000000000000000 0x0000000000000000 0x0000000000000000
> 0x0000000000000000 0x0000000000000000 R 8
>
> Section to Segment mapping:
> Segment Sections...
> 00 .text __ex_table .rodata .pci_fixup __ksymtab __ksymtab_gpl
> __ksymtab_unused __ksymtab_strings __param
> 01 .data .data.cacheline_aligned .data.read_mostly
> .data.init_task .data.page_aligned .init.text .init.data .init.setup
> .initcall.init .con_initcall.init .altinstructions
> .altinstr_replacement .exit.text .init.ramfs .bss
> 02 .vsyscall_0 .xtime_lock .vxtime .vgetcpu_mode .sys_tz
> .sysctl_vsyscall .xtime .jiffies .vsyscall_1 .vsyscall_2 .vsyscall_3
> 03
>
Ok. So second and third program header are overlapping in physical
address space and that's why kexec-tools is cribbing.
Looking at these headers, it looks like program header 02 which contains
will overwrite some of the data of program header 01 and I think that's
wrong. Will look more into it.
Thanks
Vivek
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: 2.6.19-rc1: kexec broken on x86_64
2006-10-05 14:24 ` Vivek Goyal
@ 2006-10-05 15:17 ` Eric W. Biederman
0 siblings, 0 replies; 8+ messages in thread
From: Eric W. Biederman @ 2006-10-05 15:17 UTC (permalink / raw)
To: vgoyal
Cc: Magnus Damm, Linux Kernel Mailing List, fastboot,
Eric W. Biederman, Horms, Magnus Damm, Andi Kleen
Vivek Goyal <vgoyal@in.ibm.com> writes:
> On Thu, Oct 05, 2006 at 10:56:51PM +0900, Magnus Damm wrote:
>> Hi Vivek,
>>
>> On 10/5/06, Vivek Goyal <vgoyal@in.ibm.com> wrote:
>> >On Thu, Oct 05, 2006 at 07:28:35PM +0900, Magnus Damm wrote:
>> >> Kexec is broken on x86_64 under 2.6.19-rc1.
>> >>
>> >> Or rather - kexec works ok under 2.6.19-rc1, but something related to
>> >> the vmlinux format has probably changed and kexec-tools fails to load
>> >> a vmlinux from 2.6.19-rc1.
>> >>
>> >> Loading bzImage works as usual, but vmlinux does not load properly.
>> >>
>> >> The kexec binary fails with the following message:
>> >>
>> >> Overlapping memory segments at 0x351000
>> >> sort_segments failed
>> >> / #
>> >>
>> >
>> >Hi Magnus,
>> >
>> >Can you please post the readelf -l output of the vmlinux you are trying
>> >to load. That's will give some indication if the segments are really
>> >overlapping in vmlinux or is it some processing bug at kexec-tools part.
>>
>> Elf file type is EXEC (Executable file)
>> Entry point 0x100100
>> There are 4 program headers, starting at offset 64
>>
>> Program Headers:
>> Type Offset VirtAddr PhysAddr
>> FileSiz MemSiz Flags Align
>> LOAD 0x0000000000100000 0xffffffff80100000 0x0000000000100000
>> 0x00000000001a4888 0x00000000001a4888 R E 100000
>> LOAD 0x00000000002a5000 0xffffffff802a5000 0x00000000002a5000
>> 0x000000000008e086 0x00000000000c1504 RWE 100000
>> LOAD 0x0000000000400000 0xffffffffff600000 0x00000000002fd000
>> 0x0000000000000c08 0x0000000000000c08 RWE 100000
>> NOTE 0x0000000000000000 0x0000000000000000 0x0000000000000000
>> 0x0000000000000000 0x0000000000000000 R 8
>>
>> Section to Segment mapping:
>> Segment Sections...
>> 00 .text __ex_table .rodata .pci_fixup __ksymtab __ksymtab_gpl
>> __ksymtab_unused __ksymtab_strings __param
>> 01 .data .data.cacheline_aligned .data.read_mostly
>> .data.init_task .data.page_aligned .init.text .init.data .init.setup
>> .initcall.init .con_initcall.init .altinstructions
>> .altinstr_replacement .exit.text .init.ramfs .bss
>> 02 .vsyscall_0 .xtime_lock .vxtime .vgetcpu_mode .sys_tz
>> .sysctl_vsyscall .xtime .jiffies .vsyscall_1 .vsyscall_2 .vsyscall_3
>> 03
>>
>
> Ok. So second and third program header are overlapping in physical
> address space and that's why kexec-tools is cribbing.
>
> Looking at these headers, it looks like program header 02 which contains
> will overwrite some of the data of program header 01 and I think that's
> wrong. Will look more into it.
Ack. I forgot to check the lengths...
That last segment (which I presume is the vdso) is quite short.
Eric
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: 2.6.19-rc1: kexec broken on x86_64
2006-10-05 13:56 ` Magnus Damm
2006-10-05 14:24 ` Vivek Goyal
@ 2006-10-05 14:33 ` Eric W. Biederman
2006-10-05 16:33 ` Vivek Goyal
2 siblings, 0 replies; 8+ messages in thread
From: Eric W. Biederman @ 2006-10-05 14:33 UTC (permalink / raw)
To: Magnus Damm
Cc: vgoyal, Linux Kernel Mailing List, fastboot, Horms, Magnus Damm
"Magnus Damm" <magnus.damm@gmail.com> writes:
> Hi Vivek,
>
> On 10/5/06, Vivek Goyal <vgoyal@in.ibm.com> wrote:
>> On Thu, Oct 05, 2006 at 07:28:35PM +0900, Magnus Damm wrote:
>> > Kexec is broken on x86_64 under 2.6.19-rc1.
>> >
>> > Or rather - kexec works ok under 2.6.19-rc1, but something related to
>> > the vmlinux format has probably changed and kexec-tools fails to load
>> > a vmlinux from 2.6.19-rc1.
>> >
>> > Loading bzImage works as usual, but vmlinux does not load properly.
>> >
>> > The kexec binary fails with the following message:
>> >
>> > Overlapping memory segments at 0x351000
>> > sort_segments failed
>> > / #
>> >
>>
>> Hi Magnus,
>>
>> Can you please post the readelf -l output of the vmlinux you are trying
>> to load. That's will give some indication if the segments are really
>> overlapping in vmlinux or is it some processing bug at kexec-tools part.
>
> Elf file type is EXEC (Executable file)
> Entry point 0x100100
> There are 4 program headers, starting at offset 64
>
> Program Headers:
> Type Offset VirtAddr PhysAddr
> FileSiz MemSiz Flags Align
> LOAD 0x0000000000100000 0xffffffff80100000 0x0000000000100000
> 0x00000000001a4888 0x00000000001a4888 R E 100000
> LOAD 0x00000000002a5000 0xffffffff802a5000 0x00000000002a5000
> 0x000000000008e086 0x00000000000c1504 RWE 100000
> LOAD 0x0000000000400000 0xffffffffff600000 0x00000000002fd000
> 0x0000000000000c08 0x0000000000000c08 RWE 100000
> NOTE 0x0000000000000000 0x0000000000000000 0x0000000000000000
> 0x0000000000000000 0x0000000000000000 R 8
>
> Section to Segment mapping:
> Segment Sections...
> 00 .text __ex_table .rodata .pci_fixup __ksymtab __ksymtab_gpl
> __ksymtab_unused __ksymtab_strings __param
> 01 .data .data.cacheline_aligned .data.read_mostly
> .data.init_task .data.page_aligned .init.text .init.data .init.setup
> .initcall.init .con_initcall.init .altinstructions
> .altinstr_replacement .exit.text .init.ramfs .bss
> 02 .vsyscall_0 .xtime_lock .vxtime .vgetcpu_mode .sys_tz
> .sysctl_vsyscall .xtime .jiffies .vsyscall_1 .vsyscall_2 .vsyscall_3
> 03
>
> Thanks,
Ok. There does not appear anything here that is not page aligned. So
it looks like something is triggering a kexec-tools bug.
Eric
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: 2.6.19-rc1: kexec broken on x86_64
2006-10-05 13:56 ` Magnus Damm
2006-10-05 14:24 ` Vivek Goyal
2006-10-05 14:33 ` Eric W. Biederman
@ 2006-10-05 16:33 ` Vivek Goyal
2006-10-06 2:28 ` Magnus Damm
2 siblings, 1 reply; 8+ messages in thread
From: Vivek Goyal @ 2006-10-05 16:33 UTC (permalink / raw)
To: Magnus Damm
Cc: Linux Kernel Mailing List, fastboot, Eric W. Biederman, Horms,
Magnus Damm, Andi Kleen, Ian.Campbell
On Thu, Oct 05, 2006 at 10:56:51PM +0900, Magnus Damm wrote:
> Hi Vivek,
>
> On 10/5/06, Vivek Goyal <vgoyal@in.ibm.com> wrote:
> >On Thu, Oct 05, 2006 at 07:28:35PM +0900, Magnus Damm wrote:
> >> Kexec is broken on x86_64 under 2.6.19-rc1.
> >>
> >> Or rather - kexec works ok under 2.6.19-rc1, but something related to
> >> the vmlinux format has probably changed and kexec-tools fails to load
> >> a vmlinux from 2.6.19-rc1.
> >>
> >> Loading bzImage works as usual, but vmlinux does not load properly.
> >>
> >> The kexec binary fails with the following message:
> >>
> >> Overlapping memory segments at 0x351000
> >> sort_segments failed
> >> / #
> >>
> >
> >Hi Magnus,
> >
> >Can you please post the readelf -l output of the vmlinux you are trying
> >to load. That's will give some indication if the segments are really
> >overlapping in vmlinux or is it some processing bug at kexec-tools part.
>
> Elf file type is EXEC (Executable file)
> Entry point 0x100100
> There are 4 program headers, starting at offset 64
>
> Program Headers:
> Type Offset VirtAddr PhysAddr
> FileSiz MemSiz Flags Align
> LOAD 0x0000000000100000 0xffffffff80100000 0x0000000000100000
> 0x00000000001a4888 0x00000000001a4888 R E 100000
> LOAD 0x00000000002a5000 0xffffffff802a5000 0x00000000002a5000
> 0x000000000008e086 0x00000000000c1504 RWE 100000
> LOAD 0x0000000000400000 0xffffffffff600000 0x00000000002fd000
> 0x0000000000000c08 0x0000000000000c08 RWE 100000
> NOTE 0x0000000000000000 0x0000000000000000 0x0000000000000000
> 0x0000000000000000 0x0000000000000000 R 8
>
> Section to Segment mapping:
> Segment Sections...
> 00 .text __ex_table .rodata .pci_fixup __ksymtab __ksymtab_gpl
> __ksymtab_unused __ksymtab_strings __param
> 01 .data .data.cacheline_aligned .data.read_mostly
> .data.init_task .data.page_aligned .init.text .init.data .init.setup
> .initcall.init .con_initcall.init .altinstructions
> .altinstr_replacement .exit.text .init.ramfs .bss
> 02 .vsyscall_0 .xtime_lock .vxtime .vgetcpu_mode .sys_tz
> .sysctl_vsyscall .xtime .jiffies .vsyscall_1 .vsyscall_2 .vsyscall_3
> 03
>
Hi Magnus,
I think this got introduced because of Ian Cambell's patch for creating
PT_NOTE headers. Can you please try attached patch. I think it should
fix the issue.
Thanks
Vivek
o A recent change to vmlinux.ld.S file broke kexec as now resulting vmlinux
program headers are overlapping in physical address space.
o Now all the vsyscall related sections are placed after data and after
that mostly init data sections are placed. To avoid physical overlap
among phdrs, there are three possible solutions.
- Place vsyscall sections also in data phdrs instead of user
- move vsyscal sections after init data in bss.
- create another phdrs say data.init and move all the sections
after vsyscall into this new phdr.
o This patch implements the third solution.
Signed-off-by: Vivek Goyal <vgoyal@in.ibm.com>
---
arch/x86_64/kernel/vmlinux.lds.S | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff -puN arch/x86_64/kernel/vmlinux.lds.S~x86_64-physical-addr-space-overlap-in-phdrs-fix arch/x86_64/kernel/vmlinux.lds.S
--- linux-2.6.19-rc1-1M/arch/x86_64/kernel/vmlinux.lds.S~x86_64-physical-addr-space-overlap-in-phdrs-fix 2006-10-05 12:15:00.000000000 -0400
+++ linux-2.6.19-rc1-1M-root/arch/x86_64/kernel/vmlinux.lds.S 2006-10-05 12:15:00.000000000 -0400
@@ -17,6 +17,7 @@ PHDRS {
text PT_LOAD FLAGS(5); /* R_E */
data PT_LOAD FLAGS(7); /* RWE */
user PT_LOAD FLAGS(7); /* RWE */
+ data.init PT_LOAD FLAGS(7); /* RWE */
note PT_NOTE FLAGS(4); /* R__ */
}
SECTIONS
@@ -131,7 +132,7 @@ SECTIONS
. = ALIGN(8192); /* init_task */
.data.init_task : AT(ADDR(.data.init_task) - LOAD_OFFSET) {
*(.data.init_task)
- } :data
+ }:data.init
. = ALIGN(4096);
.data.page_aligned : AT(ADDR(.data.page_aligned) - LOAD_OFFSET) {
_
^ permalink raw reply [flat|nested] 8+ messages in thread* Re: 2.6.19-rc1: kexec broken on x86_64
2006-10-05 16:33 ` Vivek Goyal
@ 2006-10-06 2:28 ` Magnus Damm
0 siblings, 0 replies; 8+ messages in thread
From: Magnus Damm @ 2006-10-06 2:28 UTC (permalink / raw)
To: vgoyal
Cc: Magnus Damm, Linux Kernel Mailing List, fastboot,
Eric W. Biederman, Horms, Andi Kleen, Ian.Campbell
On Thu, 2006-10-05 at 12:33 -0400, Vivek Goyal wrote:
> On Thu, Oct 05, 2006 at 10:56:51PM +0900, Magnus Damm wrote:
> > Hi Vivek,
> >
> > On 10/5/06, Vivek Goyal <vgoyal@in.ibm.com> wrote:
> > >On Thu, Oct 05, 2006 at 07:28:35PM +0900, Magnus Damm wrote:
> > >> Kexec is broken on x86_64 under 2.6.19-rc1.
> > >>
> > >> Or rather - kexec works ok under 2.6.19-rc1, but something related to
> > >> the vmlinux format has probably changed and kexec-tools fails to load
> > >> a vmlinux from 2.6.19-rc1.
> > >>
> > >> Loading bzImage works as usual, but vmlinux does not load properly.
> > >>
> > >> The kexec binary fails with the following message:
> > >>
> > >> Overlapping memory segments at 0x351000
> > >> sort_segments failed
> > >> / #
> > >>
> > >
> > >Hi Magnus,
> > >
> > >Can you please post the readelf -l output of the vmlinux you are trying
> > >to load. That's will give some indication if the segments are really
> > >overlapping in vmlinux or is it some processing bug at kexec-tools part.
> >
> > Elf file type is EXEC (Executable file)
> > Entry point 0x100100
> > There are 4 program headers, starting at offset 64
> >
> > Program Headers:
> > Type Offset VirtAddr PhysAddr
> > FileSiz MemSiz Flags Align
> > LOAD 0x0000000000100000 0xffffffff80100000 0x0000000000100000
> > 0x00000000001a4888 0x00000000001a4888 R E 100000
> > LOAD 0x00000000002a5000 0xffffffff802a5000 0x00000000002a5000
> > 0x000000000008e086 0x00000000000c1504 RWE 100000
> > LOAD 0x0000000000400000 0xffffffffff600000 0x00000000002fd000
> > 0x0000000000000c08 0x0000000000000c08 RWE 100000
> > NOTE 0x0000000000000000 0x0000000000000000 0x0000000000000000
> > 0x0000000000000000 0x0000000000000000 R 8
> >
> > Section to Segment mapping:
> > Segment Sections...
> > 00 .text __ex_table .rodata .pci_fixup __ksymtab __ksymtab_gpl
> > __ksymtab_unused __ksymtab_strings __param
> > 01 .data .data.cacheline_aligned .data.read_mostly
> > .data.init_task .data.page_aligned .init.text .init.data .init.setup
> > .initcall.init .con_initcall.init .altinstructions
> > .altinstr_replacement .exit.text .init.ramfs .bss
> > 02 .vsyscall_0 .xtime_lock .vxtime .vgetcpu_mode .sys_tz
> > .sysctl_vsyscall .xtime .jiffies .vsyscall_1 .vsyscall_2 .vsyscall_3
> > 03
> >
>
> Hi Magnus,
>
> I think this got introduced because of Ian Cambell's patch for creating
> PT_NOTE headers. Can you please try attached patch. I think it should
> fix the issue.
You are right, the patch solves the problem. It is now possible to use
kexec on x86_64 to reboot into a vmlinux built from 2.6.19-rc1 + your
patch.
Nice work, thanks!
/ magnus
^ permalink raw reply [flat|nested] 8+ messages in thread