gmane.linux.kernel.kexec

Kexec corrupts command line in x86-linux-setup.c setup_edd_info()

Dmitry Trikoz — 2012-05-24T17:26:51

Hi,
I've been chasing strange problem with kdump kernel. It was crashing on 
boot without any messages to the console.
Finally I found that kdump kernel command line was corrupt.
Digging down I found the problem in  setup_edd_info() and 
add_edd_entry(). It doesn't check for array size of
real_mode->eddbuf[] and real_mode->edd_mbr_sig_buffer[]
So when it overruns eddbuf[] it corrupts command_line that follows it.

Here is the fix:

--- a/kexec-tools/kexec/arch/i386/x86-linux-setup.c
+++ b/kexec-tools/kexec/arch/i386/x86-linux-setup.c
< at >< at > -275,9 +275,9 < at >< at > static int add_edd_entry(struct 
x86_linux_param_header *real_mode,
                                 "must not be NULL", __FUNCTION__);
                 return -1;
         }
-
-       edd_info = &real_mode->eddbuf[*current_edd];
-       memset(edd_info, 0, sizeof(struct edd_info));
+       if (*current_mbr >= EDD_MBR_SIG_MAX) {
+               return 0;
+       }

         /* extract the device number */
         if (sscanf(basename(sysfs_name), "int13_dev%h

Re: [v2 PATCH] ppc: move DEBUG code to --debug

Cong Wang — 2012-05-24T01:43:46

Thanks to both of you! :)

Re: [v2 PATCH] ppc: move DEBUG code to --debug

Simon Horman — 2012-05-24T00:31:29

Thanks!

Re: [v2 PATCH] ppc: move DEBUG code to --debug

Suzuki K. Poulose — 2012-05-23T12:50:12

It builds and works fine for me on PPC32. Sample output below.



Thanks
Suzuki



--- Sample output ---

# kexec -p --debug vmlinux.strip
0000000000000000-0000000080000000 : 0
get base memory ranges:1
usable memory rgns size:1 base:8000000 size:8000000
exclude_range sorted exclude_range[0] start:0, end:1617000
setup_memory_ranges memory_range[0] start:1617001, end:30000000
CRASH MEMORY RANGES
0000000000000000-0000000008000000
0000000010000000-0000000080000000
get_crash_notes_per_cpu: crash_notes addr = 305445c
Elf header: p_type = 4, p_offset = 0x305445c p_paddr = 0x305445c p_vaddr 
= 0x0 p_filesz = 0x400 p_memsz = 0x400
vmcoreinfo header: p_type = 4, p_offset = 0x15fa3bc p_paddr = 0x15fa3bc 
p_vaddr = 0x0 p_filesz = 0x1000 p_memsz = 0x1000
Elf header: p_type = 1, p_offset = 0x0 p_paddr = 0x0 p_vaddr = 
0xc0000000 p_filesz = 0x8000000 p_memsz = 0x8000000
Elf header: p_type = 1, p_offset = 0x10000000 p_paddr = 0x10000000 
p_vaddr = 0xffffffff p_filesz = 0x70000000 p_memsz = 0x70000000
Command line after add

Re: [PATCH v2 0/5] Export offsets of VMCS fields as note information for kdump

Eric Northup — 2012-05-22T20:53:47

On Mon, May 21, 2012 at 8:53 PM, Yanfei Zhang
<zhangyanfei< at >cn.fujitsu.com> wrote:
[...]
[...]

It's not risky: you just have to make sure that no one else is going
to use the VMCS on your CPU while you're running.  You can disable
preemption and then save the old VMCS pointer from the CPU (see the
VMPTRST instructions).  Load your temporary VMCS pointer, discover
the fields, then restore the original VMCS pointer.  Then re-enable
preemption and you're done.

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

[PATCH v2] kexec: simply pass LINUX_REBOOT_CMD_KEXEC to reboot

maximilian attems — 2012-05-22T16:59:47

While trying to port kexec cleanly to klibc,
came across this syscall usage for reboot(2).
Calling reboot directly simplifies the code.

Signed-off-by: maximilian attems <max-U9r9yeDMy7A< at >public.gmane.org>
---
 kexec/kexec-syscall.h |   18 ------------------
 kexec/kexec.c         |    3 ++-
 2 files changed, 2 insertions(+), 19 deletions(-)

v2: keep LINUX_REBOOT_CMD_KEXEC defines, thus no need of <linux/reboot.h>.
    (The packagers don't like linux header deps..)

The next TODO item is to add proper syscall kexec_load() to glibc.
Funnily here klibc has an head start! -maks

diff --git a/kexec/kexec-syscall.h b/kexec/kexec-syscall.h
index f4df45c..b56cb00 100644
--- a/kexec/kexec-syscall.h
+++ b/kexec/kexec-syscall.h
< at >< at > -5,18 +5,6 < at >< at >
 #include <sys/syscall.h>
 #include <unistd.h>
 
-#defineLINUX_REBOOT_MAGIC10xfee1dead
-#defineLINUX_REBOOT_MAGIC2672274793
-#defineLINUX_REBOOT_MAGIC2A85072278
-#defineLINUX_REBOOT_MAGIC2B369367448
-
-#defineLINUX_REBOOT_CMD_RESTART0x01234567
-#defineLINUX_REBOOT_CM

[PATCH] kexec: simply pass LINUX_REBOOT_CMD_KEXEC to reboot

maximilian attems — 2012-05-22T16:09:58

While trying to port kexec cleanly to klibc,
came across this syscall usage for reboot(2).
Calling reboot directly simplifies the code.

Signed-off-by: maximilian attems <max-U9r9yeDMy7A< at >public.gmane.org>
---
 kexec/kexec-syscall.h |   20 --------------------
 kexec/kexec.c         |    4 +++-
 2 files changed, 3 insertions(+), 21 deletions(-)

The next TODO item is to add proper syscall kexec_load() to glibc.
Funnily here klibc has an head start! -maks

diff --git a/kexec/kexec-syscall.h b/kexec/kexec-syscall.h
index f4df45c..415fbd7 100644
--- a/kexec/kexec-syscall.h
+++ b/kexec/kexec-syscall.h
< at >< at > -5,22 +5,6 < at >< at >
 #include <sys/syscall.h>
 #include <unistd.h>
 
-#defineLINUX_REBOOT_MAGIC10xfee1dead
-#defineLINUX_REBOOT_MAGIC2672274793
-#defineLINUX_REBOOT_MAGIC2A85072278
-#defineLINUX_REBOOT_MAGIC2B369367448
-
-#defineLINUX_REBOOT_CMD_RESTART0x01234567
-#defineLINUX_REBOOT_CMD_HALT0xCDEF0123
-#defineLINUX_REBOOT_CMD_CAD_ON0x89ABCDEF
-#defineLINUX_REBOOT_CMD_CAD_OFF0x00000000
-#defineLINUX_

Re: Handling spin table in kdump

McClintock Matthew-B29882 — 2012-05-22T15:34:35

I would think option 1 is acceptable. The crash kernel will never
attempt to use the memory outside of the crash kernel region therefore
it does not need to be reserved.

However, I thought we were able to boot SMP into the crash kernel on
our parts... not sure how that effects things (although the maxcpus=1
here is a perfectly acceptable and safer thing to do anyways)

-M

Re: [PATCH v2 0/5] Export offsets of VMCS fields as note information for kdump

Yanfei Zhang — 2012-05-22T03:53:27

于 2012年05月22日 02:58, Eric Northup 写道:

We have considered this way, but there are two issues:
1) vmx resource is unique for a single cpu, and it's risky to grab it forcibly
on the environment where kvm module is used, in particular on customer's environment.
To do this safely, kvm support is needed.

2) It highly costs to prepare each cpu to each customer environment to collect
vmcsinfo. After all, there are various environments on our customer's.

Our patch provides a module, so those who doesn't want this feature can just
stop it being auto-loaded when system starts up.

Thanks
Zhang Yanfei


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

Re: [PATCH v2 0/5] Export offsets of VMCS fields as note information for kdump

Yanfei Zhang — 2012-05-22T03:40:58

于 2012年05月21日 17:36, Avi Kivity 写道:

We never do this on customer's environment which maybe a host with many guests
running on it. We do this on another environment to reproduce the buggy
situation; or we do this in testing phase on development environment towards
production one on the customer's site.


Both are right.

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

Re: [PATCH v2 0/5] Export offsets of VMCS fields as note information for kdump

Eric Northup — 2012-05-21T18:58:51

On Wed, May 16, 2012 at 12:50 AM, zhangyanfei
<zhangyanfei-BthXqXjhjHXQFUHtdCDX3A< at >public.gmane.org> wrote:

Perhaps I'm wrong, but this solution seems much, much more dynamic
than it needs to be.

The VMCS offsets aren't going to change between different boots on the
same CPU, unless perhaps the microcode has been updated.

So you can have the VMCS offset dumping be a manually-loaded module.
Build a database mapping from (CPUID, microcode revision) -> (VMCSINFO).
There's no need for anything beyond the (CPUID, microcode revision) to
be put in the kdump, since your offline processing of a kdump can then
look up the rest.

It means you don't have to interact with the vmx module at all, and
no extra modules or code have to be loaded on the millions of Linux
machines that won't need the functionality.

Re: [PATCH v2 0/5] Export offsets of VMCS fields as note information for kdump

Avi Kivity — 2012-05-21T09:36:10

That sounds like a bad idea. Can you explain in what situation it makes
sense for a guest to stop the host (and all other guests running on it)
rather than just restarting the failed services (on the host or other
guests)?


The sadump tool generates a core file with the OS image, right? Can it
not attach the offsets to a note, just like you propose for kdump?

Re: [PATCH v2 0/5] Export offsets of VMCS fields as note information for kdump

Yanfei Zhang — 2012-05-21T09:08:06

于 2012年05月21日 16:34, Avi Kivity 写道:

Yes, a guest bug cannot cause a host panic. When heartbeat stops in guest
machine, we could trigger the host dump mechanism to work. This is because
we want to get the status of both host and guest machine at the same time
when heartbeat stops in guest machine. Then we can look for bug reasons
from both host machine's and guest machine's views.

Hmm, you mean we could get VMCS offsets in sadump itself?
But I think if we just export VMCS offsets in kernel, we could use the current
existing dump tools with no or just very tiny change. I think this could be
a more general mechanism than making changes in all kinds of dump tools.

Thanks
Zhang Yanfei

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

Re: [PATCH v2 0/5] Export offsets of VMCS fields as note information for kdump

Avi Kivity — 2012-05-21T08:34:16

How can a guest bug cause a host panic?


If the guest caused the problem, there would be no panic; therefore
there was a host bug.


Seems to me the VMCS offsets are OS independent.

Re: [PATCH v2 0/5] Export offsets of VMCS fields as note information for kdump

Avi Kivity — 2012-05-20T17:43:54

Do you mean, that a heartbeat failure in the guest lead to host panic?

My expectation is that a problem in the guest will cause the guest to
panic and perhaps produce a dump; the host will remain up.


Shouldn't sadump then expose the VMCS offsets? Perhaps bundling them
into its dump file?

[PATCH] Use HOSTCC for build utilities

Baruch Even — 2012-05-20T00:00:05

Subject: [PATCH] Use HOSTCC for build utilities

bin-to-hex is used during the build and needs to be compiled with the host
compiler to be able to run during the build.

Signed-off-by: Baruch Even <baruch-6P1Dz+XQpLLYtjvyW6yDsg< at >public.gmane.org>
---
 util/Makefile |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/util/Makefile b/util/Makefile
index 948ee63..82c7407 100644
--- a/util/Makefile
+++ b/util/Makefile
< at >< at > -4,8 +4,8 < at >< at > $(BIN_TO_HEX): $(srcdir)/util/bin-to-hex.c
 < at >$(MKDIR) -p $(< at >D)
 $(LINK.o) $(CFLAGS) -o $< at > $^

-$(BIN_TO_HEX): CC=$(BUILD_CC)
-$(BIN_TO_HEX): CFLAGS=$(BUILD_CFLAGS)
+$(BIN_TO_HEX): CC=$(HOSTCC)
+$(BIN_TO_HEX): CFLAGS=$(HOST_CFLAGS)
 $(BIN_TO_HEX): LDFLAGS=

 dist += util/Makefile util/bin-to-hex.c

Your Mailbox Is Almost Full

Cerda, Weston — 2012-05-18T07:33:42

Your Mailbox Is Almost Full "CLICK HERE<https://docs.google.com/spreadsheet/viewform?formkey=dE1tZWZNRzVyalFmbG9JOUNERzF5enc6MQ>" Update Your MailBox And Increase Your Account. Thanks System Administrator.

Re: [v2 PATCH] ppc: move DEBUG code to --debug

Simon Horman — 2012-05-18T02:59:32

Thank, I don't have any ppc32 (or 64) hardware to test on,
but I did use a cross-compiler to check that it builds.


Applied

Re: makedumpfile memory usage grows with system memory size

HATAYAMA Daisuke — 2012-05-17T00:21:06

From: Atsushi Kumagai <kumagai-atsushi-biTfD1RFvDe45+QrQBaojngSJqDPrsil< at >public.gmane.org>
Subject: Re: makedumpfile memory usage grows with system memory size
Date: Wed, 16 May 2012 17:02:30 +0900

A quick look into the other part of the union---inuse, objects,
froze---to which _mapcount belongs, they appears to be used in SLUB
allocator. The page with PG_slab appears to use the other part to
_mapcount. This means that to decide whether to use _mapcount, it's
necessary to first investigate how SLUB allocator works.

I'll wait for your patch on memory consumption and feedback to
it. I'll also look into possibility of filtering free memory in
constant space on recent kernels.

Thanks.
HATAYAMA, Daisuke

Re: makedumpfile memory usage grows with system memory size

Atsushi Kumagai — 2012-05-16T08:02:30

Hello HATAYAMA-san,

On Mon, 14 May 2012 14:44:28 +0900 (JST)
HATAYAMA Daisuke <d.hatayama-+CUm20s59erQFUHtdCDX3A< at >public.gmane.org> wrote:


Thank you for your investigation, it's very helpful !


I think it's better way to use _mapcount. 
But we don't certainly decide to use _mapcount and even if we decide to use it,
we still have problems to use it.
For example, the upstream kernel(v3.4-rc7) has _mapcount in union, we need
a information to judge whether the found data is _mapcount or not. 
So, more investigation is needed and I think it's too early to send the request
to upstream kernel.

I plan to finish working to reduce memory consumption by the end of June, 
and I will continue to discuss performance issues.
Therefore, the request will be delayed until July or August.


Thanks
Atsushi Kumagai

[PATCH v2 5/5] Documentation: Add ABI entry for sysfs file vmcsinfo and vmcsinfo_maxsize

zhangyanfei — 2012-05-16T07:57:35

We create two new sysfs files, vmcsinfo and vmcsinfo_maxsize. And
here we add an Documentation/ABI entry for them.

Signed-off-by: zhangyanfei <zhangyanfei-BthXqXjhjHXQFUHtdCDX3A< at >public.gmane.org>
---
 Documentation/ABI/testing/sysfs-kernel-vmcsinfo |   16 ++++++++++++++++
 1 files changed, 16 insertions(+), 0 deletions(-)
 create mode 100644 Documentation/ABI/testing/sysfs-kernel-vmcsinfo

diff --git a/Documentation/ABI/testing/sysfs-kernel-vmcsinfo b/Documentation/ABI/testing/sysfs-kernel-vmcsinfo
new file mode 100644
index 0000000..adbf866
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-kernel-vmcsinfo
< at >< at > -0,0 +1,16 < at >< at >
+What:/sys/kernel/vmcsinfo
+Date:April 2012
+KernelVersion:3.4.0
+Contact:Zhang Yanfei <zhangyanfei-BthXqXjhjHXQFUHtdCDX3A< at >public.gmane.org>
+Description
+Shows physical address of VMCSINFO. VMCSINFO contains
+the VMCS revision identifier and encoded offsets of fields
+in VMCS data on Intel processors equipped with the VT
+extensions.
+
+What:/sys/kernel/vmcsinfo_maxsize