Re: kexec_file overwrites reserved EFI ESRT memory
Hi Eric, On Fri, Nov 22, 2019 at 02:00:22PM -0600, Eric W. Biederman wrote: > > esrt: Unsupported ESRT version 2904149718861218184. > > > > (The image is rather large at 18MiB as it has a built-in initrd.) > When did x86_64 get support for ARCH_KEEP_MEMBLOCK? I can't find it > anywhere. No, is hasn't. I temporarily hacked that in to see if it'd change anything and it did. Sorry to not be more clear about that. > Fundamentally when deciding where to place a new kernel kexec (either > user space or the in kernel kexec_file implementation) needs to be able > to ask the question which memory ares are reserved. > What the buddy > allocator does is unimportant as kexec copies memory from all over > the place and places it in the destined memory addresses at the > time of the kexec operation. > So my question is why doesn't the ESRT reservation wind up in > /proc/iomem? My guess is that the focus was that some EFI structures need to be kept around accross the life cycle of *one* running kernel and memblock_reserve() was enough for that. Marking them so they survive kexecing another kernel might just never have cropped up thus far. Ard or Matt would know. > Are you dealing with an embedded port that is being clever? I'm not an expert but think it's rather the opposite: It's just a memory area provided by EFI containing some potentially interesting information about the EFI firmware structure itself. The aim is to aid firmware upgrades. This information needs to survive kexec so the user would be able to use that information (e.g. for upgrades) after a kexec. So apart from leaving that memory untouched, I guess it could also be copied over to a staging area by kexec explicitly to be preserved across the kexec. Or it could be blanked out in such a way that the esrt driver would not find it after kexec and just be unavailable, if it's decided that you should only use data about a firmware for upgrades that you really just used to boot. I guess a bigger question could be asked whether it would actually be useful and safe for esrt to be available after kexec. > Or is there some subtle breakage now that x86 has memblock support that > /proc/iomem is no longer being properly maintained? Uuuh, let me backpaddle very hard here: x86 has not gained memblock preserve support. That was just me mucking about. Sorry. -- Thanks, Michael ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: makedumpfile: ELF format issues (RE: makedumpfile: Fix divide by zero in print_report())
On Wed, Nov 13, 2019 at 07:36:01PM +, Kazuhito Hagio wrote: > I think I've fixed the ELF issues which I could reproduce: > - wrong statistics > - e_phnum overflow > > If you still see any problems with the latest makedumpfile, > please let me know. > > Thanks, > Kazu It's taken me a little while to get this stuff into our production systems, but things are looking much better so far. Since I pushed out the fixes, I've seen no new corrupted dumps. I'll keep an eye on things and let you know if anything new comes up. thanks! Dave ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH v4 0/4] makedumpfile/arm64: Add support for ARMv8.2 extensions
- Original Message - > > Hi Bhupesh, > > I recall seeing a reference to modification are needed for the crash CLI also > to support 5.4.0-rc with your kernel patches cited here. > > Where would I find that at ? I don?t see crash on Giblab. https://github.com/crash-utility/crash > > >>> > >>> > >>> Hi > >>> > >>> > >>> I was able to fork and clone your work area . > >>> > >>> I can see makedumpfile works now ! > >>> > >>> Fantastic ;; Thank you for your patience ! > >>> > >> ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
[PATCH] powerpc: Fix issue with missing registers in kdump
From: Corey Minyard
When powerpc saved the registers on an SMP system, it was doing so
correctly. But after the crash, the register information was blank.
The issue was that the data was still in the CPU caches on the
CPUs, but once the jump to the crash kernel was done, the data was
never flushed to main memory, so that data was lost.
Add a cache flush after the CPU register notes are saved to fix
the issue.
Signed-off-by: Corey Minyard
---
I found this problem on an older (3.10) kernel on a Freescale
T1042D4RDB system, and I couldn't find any discussion or change that
dealt with anything like this. It appears to still be an issue,
though I'm not sure and I'm not sure this is the right way to fix the
problem.
I've tried reproducing on end of tree, but I've run into a couple of
issues. The file
/proc/device-tree/soc@ffe00/fman@40/fman-firmware/fsl,firmware
will only return 4096 bytes at a time (apparently it didn't in 3.10),
but the kexec command tries to read it in one big read in
kexec/arch/ppc/fs2dt.c:
if (read(fd, dt, len) != len)
die("unrecoverable error: could not read \"%s\": %s\n",
pathname, strerror(errno));
I hacked around that and now it hangs before printing anything in the
new kernel. Since the above was broken, I doubt this has been tested
in a while, so no surprise, I guess.
So I can't test this out on a current kernel, and I'm not sure what to
do at this point. I have it fixed for our current use, but getting a
fix upstream would be good.
arch/powerpc/kernel/crash.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/arch/powerpc/kernel/crash.c b/arch/powerpc/kernel/crash.c
index d488311efab1..f6e345b8c33d 100644
--- a/arch/powerpc/kernel/crash.c
+++ b/arch/powerpc/kernel/crash.c
@@ -24,6 +24,7 @@
#include
#include
#include
+#include
/*
* The primary CPU waits a while for all secondary CPUs to enter. This is to
@@ -75,8 +76,21 @@ void crash_ipi_callback(struct pt_regs *regs)
hard_irq_disable();
if (!cpumask_test_cpu(cpu, _state_saved)) {
+ char *buf;
+
crash_save_cpu(regs, cpu);
cpumask_set_cpu(cpu, _state_saved);
+
+ /*
+* Flush the crash note region data, otherwise the
+* data gets left in the CPU cache and then
+* invalidated, so the crashing cpu will never see it
+* in the new kernel.
+*/
+ buf = (char *) per_cpu_ptr(crash_notes, cpu);
+ if (buf)
+ flush_dcache_range((unsigned long) buf,
+ (unsigned long) buf + sizeof(note_buf_t));
}
atomic_inc(_in_crash);
--
2.17.1
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH v4 0/4] makedumpfile/arm64: Add support for ARMv8.2 extensions
Hi Bhupesh, I recall seeing a reference to modification are needed for the crash CLI also to support 5.4.0-rc with your kernel patches cited here. Where would I find that at ? I don’t see crash on Giblab. >>> >>> >>> Hi >>> >>> >>> I was able to fork and clone your work area . >>> >>> I can see makedumpfile works now ! >>> >>> Fantastic ;; Thank you for your patience ! >>> >> ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH v4 0/4] makedumpfile/arm64: Add support for ARMv8.2 extensions
> On Nov 21, 2019, at 3:52 PM, John Donnelly wrote: > > > >> On Nov 21, 2019, at 1:20 PM, John Donnelly >> wrote: >> >> >> >>> On Nov 21, 2019, at 10:59 AM, John Donnelly >>> wrote: >>> >>> >>> On Nov 21, 2019, at 10:32 AM, Bhupesh Sharma wrote: > On Wed, Nov 20, 2019 at 10:03 PM John Donnelly > wrote: > > Hi, > > Recent test below > This is your makedumpfile pulled from sourceforge . Do you mean github? I don't remember pushing anything to sourceforge. Please share the exact branch name and the source URL for the makedumpfile you are using >>> >>> Hi, You are correct - GitHub -I used your url posted below ; I do >>> not see the arch/arm64.c changes in the zip version I downloaded . >>> >>> I am not a GUI/gitlab user. Can you please send a tarball copy of your >>> working makedumpfile CLI via email and I will verify it works. >>> >> >> >> Hi >> >> >> I was able to fork and clone your work area . >> >> I can see makedumpfile works now ! >> >> Fantastic ;; Thank you for your patience ! >> > > > > I did some basic unit tests. > > This patch for makedumpfile ONLY WORKS on 5.4.0-rc8 kernel. > > It does not work with a previous 4.18 kernel. > > Is this suppose to be backwards compatible ? > > Your makedumpfile ran on 4.18. kernel debug output : kdump: saving vmcore sadump: unsupported architecture phys_start phys_end virt_start virt_end LOAD[ 0] 9008 91f5 1008 11f5 LOAD[ 1] 9000 9200 80001000 80001200 LOAD[ 2] 928c e3e0 8000128c 800063e0 LOAD[ 3] ffe0 fffa 80007fe0 80007ffa LOAD[ 4]88000 10 8008 800f8000 LOAD[ 5] 88 bff703 80878000 80bf7703 LOAD[ 6] bff706 bff72b 80bf7706 80bf772b LOAD[ 7] bff72f bff803 80bf772f 80bf7803 LOAD[ 8] bff805 bff807 80bf7805 80bf7807 LOAD[ 9] bff80d bff827 80bf780d 80bf7827 LOAD[10] bff828 bff83d 80bf7828 80bf783d LOAD[11] bff887 bffc1a 80bf7887 80bf7c1a LOAD[12] bffc1c bffc1d 80bf7c1c 80bf7c1d LOAD[13] bffe21 bfffd1 80bf7e21 80bf7fd1 LOAD[14] bfffd4 bfffd5 80bf7fd4 80bf7fd5 LOAD[15] bfffe0 c0 80bf7fe0 80bf8000 Linux kdump VMCOREINFO : OSRELEASE=4.18.0-147.el8.aarch64. << 4.18. kernel PAGESIZE=65536 page_size: 65536 SYMBOL(init_uts_ns)=114657a8 SYMBOL(node_online_map)=1145d320 SYMBOL(swapper_pg_dir)=10fa SYMBOL(_stext)=10081000 SYMBOL(vmap_area_list)=114ea220 SYMBOL(mem_section)=80bf7be7c600 LENGTH(mem_section)=1024 SIZE(mem_section)=16 OFFSET(mem_section.section_mem_map)=0 SIZE(page)=64 SIZE(pglist_data)=6656 SIZE(zone)=1728 SIZE(free_area)=88 SIZE(list_head)=16 SIZE(nodemask_t)=8 OFFSET(page.flags)=0 OFFSET(page._refcount)=52 OFFSET(page.mapping)=24 OFFSET(page.lru)=8 OFFSET(page._mapcount)=48 OFFSET(page.private)=40 OFFSET(page.compound_dtor)=16 OFFSET(page.compound_order)=17 OFFSET(page.compound_head)=8 OFFSET(pglist_data.node_zones)=0 OFFSET(pglist_data.nr_zones)=5984 OFFSET(pglist_data.node_start_pfn)=5992 OFFSET(pglist_data.node_spanned_pages)=6008 OFFSET(pglist_data.node_id)=6016 OFFSET(zone.free_area)=192 OFFSET(zone.vm_stat)=1552 OFFSET(zone.spanned_pages)=96 OFFSET(free_area.free_list)=0 OFFSET(list_head.next)=0 OFFSET(list_head.prev)=8 OFFSET(vmap_area.va_start)=0 OFFSET(vmap_area.list)=48 LENGTH(zone.free_area)=14 SYMBOL(log_buf)=1149f670 SYMBOL(log_buf_len)=1149f668 SYMBOL(log_first_idx)=11cc574c SYMBOL(clear_idx)=11cc5758 SYMBOL(log_next_idx)=11cc5748 SIZE(printk_log)=16 OFFSET(printk_log.ts_nsec)=0 OFFSET(printk_log.len)=8 OFFSET(printk_log.text_len)=10 OFFSET(printk_log.dict_len)=12 LENGTH(free_area.free_list)=5 NUMBER(NR_FREE_PAGES)=0 NUMBER(PG_lru)=5 NUMBER(PG_private)=12 NUMBER(PG_swapcache)=9 NUMBER(PG_swapbacked)=18 NUMBER(PG_slab)=8 NUMBER(PG_hwpoison)=21 NUMBER(PG_head_mask)=32768 NUMBER(PAGE_BUDDY_MAPCOUNT_VALUE)=-129 NUMBER(HUGETLB_PAGE_DTOR)=2 NUMBER(PAGE_OFFLINE_MAPCOUNT_VALUE)=-257 NUMBER(VA_BITS)=48 NUMBER(MAX_PHYSMEM_BITS)=52 NUMBER(MAX_USER_VA_BITS)=52 NUMBER(kimage_voffset)=0xfffe8000 NUMBER(PHYS_OFFSET)=0x8000 KERNELOFFSET=0 CRASHTIME=1574425559 phys_base: 8000 (vmcoreinfo) max_mapnr: c0 There is enough
[PATCH 4.19 187/220] x86/kexec: Correct KEXEC_BACKUP_SRC_END off-by-one error
From: Bjorn Helgaas
[ Upstream commit 51fbf14f2528a8c6401290e37f1c893a2412f1d3 ]
The only use of KEXEC_BACKUP_SRC_END is as an argument to
walk_system_ram_res():
int crash_load_segments(struct kimage *image)
{
...
walk_system_ram_res(KEXEC_BACKUP_SRC_START, KEXEC_BACKUP_SRC_END,
image, determine_backup_region);
walk_system_ram_res() expects "start, end" arguments that are inclusive,
i.e., the range to be walked includes both the start and end addresses.
KEXEC_BACKUP_SRC_END was previously defined as (640 * 1024UL), which is the
first address *past* the desired 0-640KB range.
Define KEXEC_BACKUP_SRC_END as (640 * 1024UL - 1) so the KEXEC_BACKUP_SRC
region is [0-0x9], not [0-0xa].
Fixes: dd5f726076cc ("kexec: support for kexec on panic using new system call")
Signed-off-by: Bjorn Helgaas
Signed-off-by: Borislav Petkov
CC: "H. Peter Anvin"
CC: Andrew Morton
CC: Brijesh Singh
CC: Greg Kroah-Hartman
CC: Ingo Molnar
CC: Lianbo Jiang
CC: Takashi Iwai
CC: Thomas Gleixner
CC: Tom Lendacky
CC: Vivek Goyal
CC: baiyao...@cmss.chinamobile.com
CC: b...@redhat.com
CC: dan.j.willi...@intel.com
CC: dyo...@redhat.com
CC: kexec@lists.infradead.org
Link:
http://lkml.kernel.org/r/153805811578.1157.6948388946904655969.st...@bhelgaas-glaptop.roam.corp.google.com
Signed-off-by: Sasha Levin
---
arch/x86/include/asm/kexec.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/include/asm/kexec.h b/arch/x86/include/asm/kexec.h
index f327236f0fa71..5125fca472bb0 100644
--- a/arch/x86/include/asm/kexec.h
+++ b/arch/x86/include/asm/kexec.h
@@ -67,7 +67,7 @@ struct kimage;
/* Memory to backup during crash kdump */
#define KEXEC_BACKUP_SRC_START (0UL)
-#define KEXEC_BACKUP_SRC_END (640 * 1024UL) /* 640K */
+#define KEXEC_BACKUP_SRC_END (640 * 1024UL - 1) /* 640K */
/*
* CPU does not save ss and sp on stack if execution is already
--
2.20.1
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
[PATCH 4.19 138/220] kexec: Allocate decrypted control pages for kdump if SME is enabled
From: Lianbo Jiang
[ Upstream commit 9cf38d5559e813cccdba8b44c82cc46ba48d0896 ]
When SME is enabled in the first kernel, it needs to allocate decrypted
pages for kdump because when the kdump kernel boots, these pages need to
be accessed decrypted in the initial boot stage, before SME is enabled.
[ bp: clean up text. ]
Signed-off-by: Lianbo Jiang
Signed-off-by: Borislav Petkov
Reviewed-by: Tom Lendacky
Cc: kexec@lists.infradead.org
Cc: t...@linutronix.de
Cc: mi...@redhat.com
Cc: h...@zytor.com
Cc: a...@linux-foundation.org
Cc: dan.j.willi...@intel.com
Cc: bhelg...@google.com
Cc: baiyao...@cmss.chinamobile.com
Cc: ti...@suse.de
Cc: brijesh.si...@amd.com
Cc: dyo...@redhat.com
Cc: b...@redhat.com
Cc: jroe...@suse.de
Link: https://lkml.kernel.org/r/20180930031033.22110-3-liji...@redhat.com
Signed-off-by: Sasha Levin
---
kernel/kexec_core.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/kernel/kexec_core.c b/kernel/kexec_core.c
index f50b90d0d1c28..faeec8255e7e0 100644
--- a/kernel/kexec_core.c
+++ b/kernel/kexec_core.c
@@ -473,6 +473,10 @@ static struct page
*kimage_alloc_crash_control_pages(struct kimage *image,
}
}
+ /* Ensure that these pages are decrypted if SME is enabled. */
+ if (pages)
+ arch_kexec_post_alloc_pages(page_address(pages), 1 << order, 0);
+
return pages;
}
@@ -869,6 +873,7 @@ static int kimage_load_crash_segment(struct kimage *image,
result = -ENOMEM;
goto out;
}
+ arch_kexec_post_alloc_pages(page_address(page), 1, 0);
ptr = kmap(page);
ptr += maddr & ~PAGE_MASK;
mchunk = min_t(size_t, mbytes,
@@ -886,6 +891,7 @@ static int kimage_load_crash_segment(struct kimage *image,
result = copy_from_user(ptr, buf, uchunk);
kexec_flush_icache_page(page);
kunmap(page);
+ arch_kexec_pre_free_pages(page_address(page), 1);
if (result) {
result = -EFAULT;
goto out;
--
2.20.1
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
[PATCH 4.14 079/122] kexec: Allocate decrypted control pages for kdump if SME is enabled
From: Lianbo Jiang
[ Upstream commit 9cf38d5559e813cccdba8b44c82cc46ba48d0896 ]
When SME is enabled in the first kernel, it needs to allocate decrypted
pages for kdump because when the kdump kernel boots, these pages need to
be accessed decrypted in the initial boot stage, before SME is enabled.
[ bp: clean up text. ]
Signed-off-by: Lianbo Jiang
Signed-off-by: Borislav Petkov
Reviewed-by: Tom Lendacky
Cc: kexec@lists.infradead.org
Cc: t...@linutronix.de
Cc: mi...@redhat.com
Cc: h...@zytor.com
Cc: a...@linux-foundation.org
Cc: dan.j.willi...@intel.com
Cc: bhelg...@google.com
Cc: baiyao...@cmss.chinamobile.com
Cc: ti...@suse.de
Cc: brijesh.si...@amd.com
Cc: dyo...@redhat.com
Cc: b...@redhat.com
Cc: jroe...@suse.de
Link: https://lkml.kernel.org/r/20180930031033.22110-3-liji...@redhat.com
Signed-off-by: Sasha Levin
---
kernel/kexec_core.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/kernel/kexec_core.c b/kernel/kexec_core.c
index 8f15665ab6167..27cf24e285e0c 100644
--- a/kernel/kexec_core.c
+++ b/kernel/kexec_core.c
@@ -473,6 +473,10 @@ static struct page
*kimage_alloc_crash_control_pages(struct kimage *image,
}
}
+ /* Ensure that these pages are decrypted if SME is enabled. */
+ if (pages)
+ arch_kexec_post_alloc_pages(page_address(pages), 1 << order, 0);
+
return pages;
}
@@ -867,6 +871,7 @@ static int kimage_load_crash_segment(struct kimage *image,
result = -ENOMEM;
goto out;
}
+ arch_kexec_post_alloc_pages(page_address(page), 1, 0);
ptr = kmap(page);
ptr += maddr & ~PAGE_MASK;
mchunk = min_t(size_t, mbytes,
@@ -884,6 +889,7 @@ static int kimage_load_crash_segment(struct kimage *image,
result = copy_from_user(ptr, buf, uchunk);
kexec_flush_icache_page(page);
kunmap(page);
+ arch_kexec_pre_free_pages(page_address(page), 1);
if (result) {
result = -EFAULT;
goto out;
--
2.20.1
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
[PATCH 4.14 102/122] x86/kexec: Correct KEXEC_BACKUP_SRC_END off-by-one error
From: Bjorn Helgaas
[ Upstream commit 51fbf14f2528a8c6401290e37f1c893a2412f1d3 ]
The only use of KEXEC_BACKUP_SRC_END is as an argument to
walk_system_ram_res():
int crash_load_segments(struct kimage *image)
{
...
walk_system_ram_res(KEXEC_BACKUP_SRC_START, KEXEC_BACKUP_SRC_END,
image, determine_backup_region);
walk_system_ram_res() expects "start, end" arguments that are inclusive,
i.e., the range to be walked includes both the start and end addresses.
KEXEC_BACKUP_SRC_END was previously defined as (640 * 1024UL), which is the
first address *past* the desired 0-640KB range.
Define KEXEC_BACKUP_SRC_END as (640 * 1024UL - 1) so the KEXEC_BACKUP_SRC
region is [0-0x9], not [0-0xa].
Fixes: dd5f726076cc ("kexec: support for kexec on panic using new system call")
Signed-off-by: Bjorn Helgaas
Signed-off-by: Borislav Petkov
CC: "H. Peter Anvin"
CC: Andrew Morton
CC: Brijesh Singh
CC: Greg Kroah-Hartman
CC: Ingo Molnar
CC: Lianbo Jiang
CC: Takashi Iwai
CC: Thomas Gleixner
CC: Tom Lendacky
CC: Vivek Goyal
CC: baiyao...@cmss.chinamobile.com
CC: b...@redhat.com
CC: dan.j.willi...@intel.com
CC: dyo...@redhat.com
CC: kexec@lists.infradead.org
Link:
http://lkml.kernel.org/r/153805811578.1157.6948388946904655969.st...@bhelgaas-glaptop.roam.corp.google.com
Signed-off-by: Sasha Levin
---
arch/x86/include/asm/kexec.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/include/asm/kexec.h b/arch/x86/include/asm/kexec.h
index f327236f0fa71..5125fca472bb0 100644
--- a/arch/x86/include/asm/kexec.h
+++ b/arch/x86/include/asm/kexec.h
@@ -67,7 +67,7 @@ struct kimage;
/* Memory to backup during crash kdump */
#define KEXEC_BACKUP_SRC_START (0UL)
-#define KEXEC_BACKUP_SRC_END (640 * 1024UL) /* 640K */
+#define KEXEC_BACKUP_SRC_END (640 * 1024UL - 1) /* 640K */
/*
* CPU does not save ss and sp on stack if execution is already
--
2.20.1
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
[PATCH 4.9 211/222] x86/kexec: Correct KEXEC_BACKUP_SRC_END off-by-one error
From: Bjorn Helgaas
[ Upstream commit 51fbf14f2528a8c6401290e37f1c893a2412f1d3 ]
The only use of KEXEC_BACKUP_SRC_END is as an argument to
walk_system_ram_res():
int crash_load_segments(struct kimage *image)
{
...
walk_system_ram_res(KEXEC_BACKUP_SRC_START, KEXEC_BACKUP_SRC_END,
image, determine_backup_region);
walk_system_ram_res() expects "start, end" arguments that are inclusive,
i.e., the range to be walked includes both the start and end addresses.
KEXEC_BACKUP_SRC_END was previously defined as (640 * 1024UL), which is the
first address *past* the desired 0-640KB range.
Define KEXEC_BACKUP_SRC_END as (640 * 1024UL - 1) so the KEXEC_BACKUP_SRC
region is [0-0x9], not [0-0xa].
Fixes: dd5f726076cc ("kexec: support for kexec on panic using new system call")
Signed-off-by: Bjorn Helgaas
Signed-off-by: Borislav Petkov
CC: "H. Peter Anvin"
CC: Andrew Morton
CC: Brijesh Singh
CC: Greg Kroah-Hartman
CC: Ingo Molnar
CC: Lianbo Jiang
CC: Takashi Iwai
CC: Thomas Gleixner
CC: Tom Lendacky
CC: Vivek Goyal
CC: baiyao...@cmss.chinamobile.com
CC: b...@redhat.com
CC: dan.j.willi...@intel.com
CC: dyo...@redhat.com
CC: kexec@lists.infradead.org
Link:
http://lkml.kernel.org/r/153805811578.1157.6948388946904655969.st...@bhelgaas-glaptop.roam.corp.google.com
Signed-off-by: Sasha Levin
---
arch/x86/include/asm/kexec.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/include/asm/kexec.h b/arch/x86/include/asm/kexec.h
index 282630e4c6ea4..1624a7ffa95d8 100644
--- a/arch/x86/include/asm/kexec.h
+++ b/arch/x86/include/asm/kexec.h
@@ -66,7 +66,7 @@ struct kimage;
/* Memory to backup during crash kdump */
#define KEXEC_BACKUP_SRC_START (0UL)
-#define KEXEC_BACKUP_SRC_END (640 * 1024UL) /* 640K */
+#define KEXEC_BACKUP_SRC_END (640 * 1024UL - 1) /* 640K */
/*
* CPU does not save ss and sp on stack if execution is already
--
2.20.1
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
[PATCH 4.4 151/159] x86/kexec: Correct KEXEC_BACKUP_SRC_END off-by-one error
From: Bjorn Helgaas
[ Upstream commit 51fbf14f2528a8c6401290e37f1c893a2412f1d3 ]
The only use of KEXEC_BACKUP_SRC_END is as an argument to
walk_system_ram_res():
int crash_load_segments(struct kimage *image)
{
...
walk_system_ram_res(KEXEC_BACKUP_SRC_START, KEXEC_BACKUP_SRC_END,
image, determine_backup_region);
walk_system_ram_res() expects "start, end" arguments that are inclusive,
i.e., the range to be walked includes both the start and end addresses.
KEXEC_BACKUP_SRC_END was previously defined as (640 * 1024UL), which is the
first address *past* the desired 0-640KB range.
Define KEXEC_BACKUP_SRC_END as (640 * 1024UL - 1) so the KEXEC_BACKUP_SRC
region is [0-0x9], not [0-0xa].
Fixes: dd5f726076cc ("kexec: support for kexec on panic using new system call")
Signed-off-by: Bjorn Helgaas
Signed-off-by: Borislav Petkov
CC: "H. Peter Anvin"
CC: Andrew Morton
CC: Brijesh Singh
CC: Greg Kroah-Hartman
CC: Ingo Molnar
CC: Lianbo Jiang
CC: Takashi Iwai
CC: Thomas Gleixner
CC: Tom Lendacky
CC: Vivek Goyal
CC: baiyao...@cmss.chinamobile.com
CC: b...@redhat.com
CC: dan.j.willi...@intel.com
CC: dyo...@redhat.com
CC: kexec@lists.infradead.org
Link:
http://lkml.kernel.org/r/153805811578.1157.6948388946904655969.st...@bhelgaas-glaptop.roam.corp.google.com
Signed-off-by: Sasha Levin
---
arch/x86/include/asm/kexec.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/include/asm/kexec.h b/arch/x86/include/asm/kexec.h
index d2434c1cad055..414f9b52e58e6 100644
--- a/arch/x86/include/asm/kexec.h
+++ b/arch/x86/include/asm/kexec.h
@@ -66,7 +66,7 @@ struct kimage;
/* Memory to backup during crash kdump */
#define KEXEC_BACKUP_SRC_START (0UL)
-#define KEXEC_BACKUP_SRC_END (640 * 1024UL) /* 640K */
+#define KEXEC_BACKUP_SRC_END (640 * 1024UL - 1) /* 640K */
/*
* CPU does not save ss and sp on stack if execution is already
--
2.20.1
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
