Now crashkernel=X will fail if there's not enough memory at low region
(below 896M) when trying to reserve large memory size. One can use
crashkernel=xM,high to reserve it at high region (>4G) but it is more
convinient to improve crashkernel=X to:
- First try to reserve X below 896M (for being c
The total memory size we get in kernel is usually slightly less than 2G with a
2G memory module machine. The main reason is bios/firmware reserve some area
it will not export all memory as usable to Linux.
2G memory X86 kvm guest test result of the total_mem value:
UEFI boot with ovmf: 0x7ef1
Now crashkernel=X will fail if there's not enough memory at low region
(below 896M) when trying to reserve large memory size. One can use
crashkernel=xM,high to reserve it at high region (>4G) but it is more
convinient to improve crashkernel=X to:
- First try to reserve X below 896M (for being
crashkernel=range:size syntax allows to reserve specified size for system
with total memory fall into the specified range. For example:
crashkernel=2G-3G:128M,3G-:256M reserves 128M for system with memory >=2G
and memory <3G, and reserves 256M for system with memory >= 3G
In the above case 256M as
Hi,
Here is a try to improve current crashkernel kernel parameter
Patch 1/3 adds an extra functionality so that one can use like
crashkernel=2G-:128M^12 to reserve 128M for 2G+ machine but also scale the
size based on system memory, that means 128M + (total_mem - 128M) >> 12
Patch 2/3 is a resen
The total memory size we get in kernel is usually slightly less than 2G with a
2G memory module machine. The main reason is bios/firmware reserve some area
it will not export all memory as usable to Linux.
2G memory X86 kvm guest test result of the total_mem value:
UEFI boot with ovmf: 0x7ef1
A useful use case for min_t and max_t is comparing two values with larger
type. For example comparing an u64 and an u32, usually we do not want to
truncate the u64, so we need use min_t or max_t with u64.
To simplify the usage introducing two more macros min_lt and max_lt,
'lt' means larger type.
Hi,
We found a min_t type casting issue in fs/proc/vmcore.c, it uses smaller
type in min_t so that during i386 PAE testing 64bit value was trucated
and then cause saving vmcore failure and BUG() for mmap case.
I introduced new macros min_lt and max_lt to select the larger data type
in x and y. Th
On i686 PAE enabled machine the contiguous physical area could be large
and it can cause triming down variables in below calculation in
read_vmcore() and mmap_vmcore():
tsz = min_t(size_t, m->offset + m->size - *fpos, buflen);
Then the real size passed down is not correct any more.
Suppos
Now there's two kexec load syscall, one is kexec_load another is
kexec_file_load, kexec_file_load has been splited as kernel/kexec_file.c.
In this patch I split kexec_load syscall code to kernel/kexec.c.
And add a new kconfig option KEXEC_CORE, so we can disable kexec_load
and use kexec_file_load
Previously Theodore Ts'o brought up an issue about kexec_load syscall bypassing
signature verification:
https://lkml.org/lkml/2015/6/14/280
Because we have two kexec load syscall, one kexec_load, another kexec_file_load,
the latter one was introduced by Vivek Goyal, it is mainly for supporting UEF
Split kexec_file syscall related code to another file kernel/kexec_file.c
so that the #ifdef CONFIG_KEXEC_FILE in kexec.c can be dropped.
Sharing variables and functions are moved to kernel/kexec_internal.h per
suggestion from Vivek and Petr.
Signed-off-by: Dave Young
---
kernel/Makefile
Now there's two kexec load syscall, one is kexec_load another is
kexec_file_load, kexec_file_load has been splited as kernel/kexec_file.c.
In this patch I split kexec_load syscall code to kernel/kexec.c.
And add a new kconfig option KEXEC_CORE, so we can disable kexec_load
and use kexec_file_load
Split kexec_file syscall related code to another file kernel/kexec_file.c
so that the #ifdef CONFIG_KEXEC_FILE in kexec.c can be dropped.
Sharing variables and functions are moved to kernel/kexec_internal.h per
suggestion from Vivek and Petr.
Signed-off-by: Dave Young
---
kernel/Makefile
in_crash_kexec is only useful for kdump, it will not be used without
CONFIG_KEXEC_CORE, thus remove the #else section
Signed-off-by: Dave Young
---
arch/x86/include/asm/kdebug.h | 3 ---
1 file changed, 3 deletions(-)
diff --git a/arch/x86/include/asm/kdebug.h b/arch/x86/include/asm/kdebug.h
in
Previously Theodore Ts'o brought up an issue about kexec_load syscall bypassing
signature verification:
https://lkml.org/lkml/2015/6/14/280
Because we have two kexec load syscall, one kexec_load, another kexec_file_load,
the latter one was introduced by Vivek Goyal, it is mainly for supporting UEF
Hi,
References: <20131125085630.417850...@dhcp-16-126.nay.redhat.com>
Content-Disposition: inline; filename=03-boot-service-fix.patch
Current code check boot service region with kernel text region by:
start+size >= __pa_symbol(_text)
The end of the above region should be start + size - 1 instead.
Hi,
References: <20131125085630.417850...@dhcp-16-126.nay.redhat.com>
Content-Disposition: inline; filename=06-export-efi-runtime-mapping.patch
kexec kernel will need exactly same mapping for
efi runtime memory ranges. Thus here export the
runtime ranges mapping to sysfs, kexec-tools
will assemble
Add two small functions:
efi_merge_regions and efi_map_regions, efi_enter_virtual_mode
calls them instead of embedding two long for loop.
v1->v2:
refresh; coding style fixes.
v2->v3:
Toshi Kani:
remove unused variable
Matt: check return value of krealloc.
v3->v4:
Boris: Stretch comment to 80 cols
Hi,
References: <20131125085630.417850...@dhcp-16-126.nay.redhat.com>
Content-Disposition: inline; filename=05-export-more-efi-sysfs-vars.patch
Export fw_vendor, runtime and config tables physical
addresses to /sys/firmware/efi/systab becaue kexec
kernel will need them.
>From EFI spec these 3 var
Hi,
References: <20131125085630.417850...@dhcp-16-126.nay.redhat.com>
Content-Disposition: inline; filename=02-efi-map-fixed-addr.patch
Kexec kernel will use saved runtime virtual mapping, so add a
new function efi_map_region_fixed for directly mapping a md
to md->virt.
The md is passed in from 1
Hi,
Sorry for the spam, the patch subject is not correct in previous
sending a while ago, send them again..
Here is the V4 for supporting kexec kernel efi runtime.
Per pervious discussion I pass the 1st kernel efi runtime mapping
via setup_data to 2nd kernel. Besides of the runtime mapping
info I
Hi,
References: <20131125085630.417850...@dhcp-16-126.nay.redhat.com>
Content-Disposition: inline; filename=04-efi-enter-virtual-mode-cleanup.patch
Add two small functions:
efi_merge_regions and efi_map_regions, efi_enter_virtual_mode
calls them instead of embedding two long for loop.
v1->v2:
ref
Hi,
References: <20131125085630.417850...@dhcp-16-126.nay.redhat.com>
Content-Disposition: inline; filename=12-x86-kdebugfs-use-ioremap.patch
__va does not work in case memmap=exactmap, so let's always use ioremap_cache.
Signed-off-by: Dave Young
---
arch/x86/kernel/kdebugfs.c | 35 ++
Hi,
References: <20131125085630.417850...@dhcp-16-126.nay.redhat.com>
Content-Disposition: inline;
filename=08-add-xloadflags-for-kexec-efi-runtime-feature.patch
Old kexec-tools can not load new kernel. The reason is previously kexec-tools
do not fill efi_info in x86 setup header thus efi init fa
Hi,
References: <20131125085630.417850...@dhcp-16-126.nay.redhat.com>
Content-Disposition: inline; filename=09-add-sysfs-boot-param.patch
kexec-tools use boot_params for getting the 1st kernel hardware_subarch,
the kexec kernel efi runtime support also need read the old efi_info from
boot_params.
Hi,
References: <20131125085630.417850...@dhcp-16-126.nay.redhat.com>
Content-Disposition: inline; filename=11-reserve-setup-data-late.patch
Kdump kernel using memmap=exactmap, move e820_reserve_setup_data after
parsing early params so they can be set reserved finally. Or kdump kernel
will warn ab
Hi,
References: <20131125085630.417850...@dhcp-16-126.nay.redhat.com>
Content-Disposition: inline; filename=01-remove-unused-var-in-map-region.patch
variables size and end is useless in this function, thus remove them.
Reported-by: Toshi Kani
Signed-off-by: Dave Young
Acked-by: Borislav Petkov
Hi,
References: <20131125085630.417850...@dhcp-16-126.nay.redhat.com>
Content-Disposition: inline; filename=07-use-efi-setup-data.patch
Add a new setup_data type SETUP_EFI for kexec use.
Passing the saved fw_vendor, runtime, config tables and
efi runtime mappings.
When entering virtual mode, dire
Hi,
References: <20131125085630.417850...@dhcp-16-126.nay.redhat.com>
Content-Disposition: inline; filename=10-print-efi-runtime-memmap.patch
For kexec/kdump kernel efi runtime mappings are saved, printing original whole
memmap ranges does not make sense anymore. So introduce a new function to onl
Kexec kernel will use saved runtime virtual mapping, so add a
new function efi_map_region_fixed for directly mapping a md
to md->virt.
The md is passed in from 1st kernel, the virtual addr is
saved in md->virt_addr.
Matt: coding style
reuse __map_region
Boris: Strenthen comment lines to 80
For kexec/kdump kernel efi runtime mappings are saved, printing original whole
memmap ranges does not make sense anymore. So introduce a new function to only
print runtime maps in case kexec/kdump kernel is used.
Signed-off-by: Dave Young
---
arch/x86/platform/efi/efi.c | 23 ++
Hi,
Here is the V4 for supporting kexec kernel efi runtime.
Per pervious discussion I pass the 1st kernel efi runtime mapping
via setup_data to 2nd kernel. Besides of the runtime mapping
info I also pass the fw_vendor, runtime, config table, smbios
physical address in setup_data. EFI spec mentione
Old kexec-tools can not load new kernel. The reason is previously kexec-tools
do not fill efi_info in x86 setup header thus efi init fail and switch
to noefi boot. In new kexec-tools it will by default fill efi_info and
pass other efi required infomation to 2nd kernel so kexec kernel efi
initializa
Add a new setup_data type SETUP_EFI for kexec use.
Passing the saved fw_vendor, runtime, config tables and
efi runtime mappings.
When entering virtual mode, directly mapping the efi
runtime ragions which we passed in previously. And skip
the step to call SetVirtualAddressMap.
Specially for HP z42
Export fw_vendor, runtime and config tables physical
addresses to /sys/firmware/efi/systab becaue kexec
kernel will need them.
>From EFI spec these 3 variables will be updated to
virtual address after entering virtual mode. But
kernel startup code will need the physical address.
changelog:
Greg:
Kdump kernel using memmap=exactmap, move e820_reserve_setup_data after
parsing early params so they can be set reserved finally. Or kdump kernel
will warn about ioremap a normal ram range.
Signed-off-by: Dave Young
---
arch/x86/kernel/setup.c |4 ++--
1 file changed, 2 insertions(+), 2 delet
Current code check boot service region with kernel text region by:
start+size >= __pa_symbol(_text)
The end of the above region should be start + size - 1 instead.
I see this problem in ovmf + Fedora 19 grub boot:
text start: 100 md start: 80 md size: 80
Signed-off-by: Dave Young
Ac
kexec kernel will need exactly same mapping for
efi runtime memory ranges. Thus here export the
runtime ranges mapping to sysfs, kexec-tools
will assemble them and pass to 2nd kernel via
setup_data.
Introducing a new directly /sys/firmware/efi/runtime-map
Just like /sys/firmware/memmap. Containing
kexec-tools use boot_params for getting the 1st kernel hardware_subarch,
the kexec kernel efi runtime support also need read the old efi_info from
boot_params. Currently it exists in debugfs which is not a good place for
such infomation. Per HPA, we should avoid of "sploit debugfs".
In this patch
__va does not work in case memmap=exactmap, so let's always use ioremap_cache.
Signed-off-by: Dave Young
---
arch/x86/kernel/kdebugfs.c | 35 +++
1 file changed, 11 insertions(+), 24 deletions(-)
--- efi.orig/arch/x86/kernel/kdebugfs.c
+++ efi/arch/x86/kernel/k
variables size and end is useless in this function, thus remove them.
Reported-by: Toshi Kani
Signed-off-by: Dave Young
Acked-by: Borislav Petkov
---
arch/x86/platform/efi/efi_64.c |6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
--- efi.orig/arch/x86/platform/efi/efi_64.c
+++ ef
Current code check boot service region with kernel text region by:
start+size >= __pa_symbol(_text)
The end of the above region should be start + size - 1 instead.
I see this problem in ovmf + Fedora 19 grub boot:
text start: 100 md start: 80 md size: 80
Signed-off-by: Dave Young
Ac
Add a new setup_data type SETUP_EFI for kexec use.
Passing the saved fw_vendor, runtime, config tables and
efi runtime mappings.
When entering virtual mode, directly mapping the efi
runtime ragions which we passed in previously. And skip
the step to call SetVirtualAddressMap.
Specially for HP z42
Hi,
Here is the V2 for supporting kexec kernel efi runtime.
Per pervious discussion I pass the 1st kernel efi runtime mapping
via setup_data to 2nd kernel. Besides of the runtime mapping
info I also pass the fw_vendor, runtime, config table, smbios
physical address in setup_data. EFI spec mentione
Add two small functions:
efi_merge_regions and efi_map_regions, efi_enter_virtual_mode
calls them instead of embedding two long for loop.
v1->v2:
refresh; coding style fixes.
Signed-off-by: Dave Young
---
arch/x86/platform/efi/efi.c | 107 +---
1 file ch
Export fw_vendor, runtime and config tables physical
addresses to /sys/firmware/efi/systab becaue kexec
kernel will need them.
>From EFI spec these 3 variables will be updated to
virtual address after entering virtual mode. But
kernel startup code will need the physical address.
Signed-off-by: Da
kexec kernel will need exactly same mapping for
efi runtime memory ranges. Thus here export the
runtime ranges mapping to sysfs, kexec-tools
will assemble them and pass to 2nd kernel via
setup_data.
Introducing a new directly /sys/firmware/efi/efi-runtime-map
Just like /sys/firmware/memmap. Contai
Old kexec-tools can not load new kernel. The reason is previously kexec-tools
do not fill efi_info in x86 setup header thus efi init fail and switch
to noefi boot. In new kexec-tools it will by default fill efi_info and
pass other efi required infomation to 2nd kernel so kexec kernel efi
initializa
Kexec kernel will use saved runtime virtual mapping, so add a
new function efi_remap_region to remapping it directly without
calculate the virt addr from efi_va.
The md is passed in from 1st kernel, the virtual addr is
saved in md->virt_addr.
Signed-off-by: Dave Young
---
arch/x86/include/asm/e
Add two small functions:
efi_merge_regions and efi_map_regions, efi_enter_virtual_mode
calls them instead of embedding two long for loop.
Signed-off-by: Dave Young
---
arch/x86/platform/efi/efi.c | 83 +++-
1 file changed, 52 insertions(+), 31 deletions(
kexec kernel will need exactly same mapping for
efi runtime memory ranges. Thus here export the
runtime ranges mapping to sysfs, kexec-tools
will assemble them and pass to 2nd kernel via
setup_data.
Introducing a new directly /sys/firmware/efi/efi-runtime-map
Just like /sys/firmware/memmap. Contai
Kexec kernel will use saved runtime virtual mapping, so add a
new function efi_remap_region to remapping it directly without
calculate the virt addr from efi_va.
The md is passed in from 1st kernel, the virtual addr is
saved in md->virt_addr.
Signed-off-by: Dave Young
---
arch/x86/include/asm/e
Export fw_vendor, runtime and config tables physical
addresses to /sys/firmware/efi/systab becaue kexec
kernel will need them.
>From EFI spec these 3 variables will be updated to
virtual address after entering virtual mode. But
kernel startup code will need the physical address.
Signed-off-by: Da
Add a new setup_data type SETUP_EFI for kexec use.
Passing the saved fw_vendor, runtime, config tables and
efi runtime mappings.
When entering virtual mode, directly mapping the efi
runtime ragions which we passed in previously. And skip
the step to call SetVirtualAddressMap.
Specially for HP z42
Hi,
Here is the 1st version for supporting kexec kernel efi runtime.
Per pervious discussion I pass the 1st kernel efi runtime mapping
via setup_data to 2nd kernel. Besides of the runtime mapping
info I also pass the fw_vendor, runtime, config table, smbios
physical address in setup_data. EFI spec
Make it obvious to see what attribute is using bogus permissions.
Signed-off-by: Dave Young
Acked-by: Felipe Balbi
---
drivers/base/core.c |6 --
1 file changed, 4 insertions(+), 2 deletions(-)
--- linux-2.6.orig/drivers/base/core.c
+++ linux-2.6/drivers/base/core.c
@@ -572,9 +572,11
lockdep is complaining about below, I see it often in kvm guests,
False postive?
[ 600.383445] ==
[ 600.383447] [ INFO: possible circular locking dependency detected ]
[ 600.383452] 3.9.0-rc5+ #71 Not tainted
[ 600.383454] ---
In ehea.h the minimal entries is 2^7 - 1:
#define EHEA_MIN_ENTRIES_QP 127
Thus change the module param description accordinglly
Signed-off-by: Dave Young
---
drivers/net/ethernet/ibm/ehea/ehea_main.c |8
1 file changed, 4 insertions(+), 4 deletions(-)
--- linux-2.6.orig/drivers/n
bash-4.1$ make -C cpu-hotplug run_tests
make: Entering directory
`/home/dave/git/linux-2.6/tools/testing/selftests/cpu-hotplug'
./on-off-test.sh
make: execvp: ./on-off-test.sh: Permission denied
make: *** [run_tests] Error 127
make: Leaving directory
`/home/dave/git/linux-2.6/tools/te
bash-4.1$ make -C memory-hotplug run_tests
make: Entering directory
`/home/dave/git/linux-2.6/tools/testing/selftests/memory-hotplug'
./on-off-test.sh
make: execvp: ./on-off-test.sh: Permission denied
make: *** [run_tests] Error 127
make: Leaving directory
`/home/dave/git/linux-2.6/to
Hi, Andrew:
Here is several fixes for selftests.
For `make run_tests` the target command will cause make fail if it exit
with non zero codes. So I change the makefile as below:
run_tests: all
- /bin/sh ./run_vmtests
+ @/bin/sh ./run_vmtests || echo "vmtests: [FAIL]"
Also fixed the kc
make run_tests need the target is run_tests instead of run-tests
Also gcc output should be kcmp_test. Fix these two issues.
Signed-off-by: Dave Young
---
tools/testing/selftests/kcmp/Makefile |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- linux-2.6.orig/tools/testing/selftests
bash-4.1$ make -C vm run_tests
make: Entering directory `/home/dave/git/linux-2.6/tools/testing/selftests/vm'
/bin/sh ./run_vmtests
./run_vmtests: line 24: /proc/sys/vm/nr_hugepages: Permission denied
Please run this test as root
make: *** [run_tests] Error 1
make: Leaving directory `
For old glibc there's no the syscall number this tests will cause
make run_tests fail.
Add a macro to define the number. This should be ok because it will be
built in latest kernel source.
Signed-off-by: Dave Young
---
tools/testing/selftests/kcmp/kcmp_test.c |3 +++
1 file changed, 3 insert
In case kcmp_test exit non zero value it will cause make error.
Better way is just print the test failure status.
Signed-off-by: Dave Young
---
tools/testing/selftests/kcmp/Makefile |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- linux-2.6.orig/tools/testing/selftests/kcmp/Makefile
In case breakpoint test exit non zero value it will cause make error.
Better way is just print the test failure status.
Signed-off-by: Dave Young
---
tools/testing/selftests/breakpoints/Makefile |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- linux-2.6.orig/tools/testing/selftests/
Original behavior:
bash-4.1$ make -C mqueue run_tests
make: Entering directory
`/home/dave/git/linux-2.6/tools/testing/selftests/mqueue'
./mq_open_tests /test1
Not running as root, but almost all tests require root in order to modify
system settings. Exiting.
make: *** [run_tests] Err
68 matches
Mail list logo
