was removed. That cause this incorrect kexec behavior.
Now add that code block back.
Reported-by: Matthew Whitehead mwhit...@redhat.com
Reported-by: Dave Young dyo...@redhat.com
Tested-by: WANG Chao chaow...@redhat.com
Signed-off-by: Baoquan He b...@redhat.com
---
arch/x86/kernel/reboot.c | 15
On 11/05/13 at 03:28pm, Vivek Goyal wrote:
On Tue, Nov 05, 2013 at 05:16:07PM +0800, Baoquan He wrote:
Currently system always reboot after below message when execute kexec -e.
[0.572119] smpboot: Booting Node 0, Processors # 1 OK
So is it same problem were we reboot on non
On 11/05/13 at 03:28pm, Vivek Goyal wrote:
On Tue, Nov 05, 2013 at 05:16:07PM +0800, Baoquan He wrote:
Currently system always reboot after below message when execute kexec -e.
[0.572119] smpboot: Booting Node 0, Processors # 1 OK
So is it same problem were we reboot on non
Hi,
Reccently people reported kexec didn't work correctly. After check, it's
a regression. Since a code block which migrate current thread to cpu0
when executing kexec -e, this can be reproduced by setting affinity to
CPUn(n!=0). You can find this patch in this link:
);
+ }
}
if (dmar_dev_scope_init() 0) {
Looks good to me, thanks!
Acked-by: Baoquan He b...@redhat.com
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info
On 11/20/13 at 12:50pm, Vivek Goyal wrote:
This patch adds support for loading a kexec on panic (kdump) kernel usning
new system call.
Signed-off-by: Vivek Goyal vgo...@redhat.com
---
arch/x86/include/asm/crash.h |9 +
arch/x86/include/asm/kexec.h | 17 +
On 11/20/13 at 12:50pm, Vivek Goyal wrote:
This is loader specific code which can load bzImage and set it up for
64bit entry. This does not take care of 32bit entry or real mode entry
yet.
Signed-off-by: Vivek Goyal vgo...@redhat.com
---
arch/x86/include/asm/kexec-bzimage.h | 12 +
On 11/20/13 at 12:50pm, Vivek Goyal wrote:
diff --git a/arch/x86/kernel/machine_kexec_64.c
b/arch/x86/kernel/machine_kexec_64.c
index 4eabc16..fb41b73 100644
--- a/arch/x86/kernel/machine_kexec_64.c
+++ b/arch/x86/kernel/machine_kexec_64.c
@@ -22,6 +22,13 @@
#include asm/mmu_context.h
Tested kdump and kexec using --use-kexec2-syscall on kenrel 3.13.0-rc2+,
they work very well.
On 11/20/13 at 12:50pm, Vivek Goyal wrote:
Current proposed secureboot implementation disables kexec/kdump because
it can allow unsigned kernel to run on a secureboot platform. Intial
idea was to
On 11/08/13 at 10:14am, Vivek Goyal wrote:
On Tue, Nov 05, 2013 at 05:16:07PM +0800, Baoquan He wrote:
Hi Bao,
This patch fixes the issue for me too. I noticed that we have generic
function migrate_to_reboot_cpu() to achieve what we want and rest of
the reboot paths are using it. So how
On 11/10/13 at 05:44pm, Baoquan He wrote:
On 11/08/13 at 10:14am, Vivek Goyal wrote:
On Tue, Nov 05, 2013 at 05:16:07PM +0800, Baoquan He wrote:
Hi Bao,
This patch fixes the issue for me too. I noticed that we have generic
function migrate_to_reboot_cpu() to achieve what we want
Hi Bill,
I have tested this prototype patch on hp z420, it works very well.
Looking forward to your formal patch set. I can help test and review.
Baoquan
Thanks
On 11/18/13 at 11:30pm, Sumner, William wrote:
Thank you for testing this RFC patch. It is great to have confirmation that
the
On 12/02/13 at 10:44am, Vivek Goyal wrote:
On Fri, Nov 29, 2013 at 11:10:48AM +0800, Baoquan He wrote:
[..]
+void *arch_kexec_kernel_image_load(struct kimage *image, char *kernel,
+ unsigned long kernel_len, char *initrd,
+ unsigned long initrd_len
On 11/20/13 at 12:50pm, Vivek Goyal wrote:
This patch adds support for loading a kexec on panic (kdump) kernel usning
new system call.
+int load_crashdump_segments(struct kimage *image)
+{
+ unsigned long src_start, src_sz;
+ unsigned long elf_addr, elf_sz;
+ int ret;
+
+
On 12/02/13 at 10:30am, Vivek Goyal wrote:
On Thu, Nov 28, 2013 at 07:28:16PM +0800, Baoquan He wrote:
[..]
+int crash_copy_backup_region(struct kimage *image)
+{
Why need this func be called, backup region has been added into crash
segment by kexec_add_buffer, and then buffer
On 11/20/13 at 12:50pm, Vivek Goyal wrote:
+ * that kexec_mutex is held.
+ */
I think kexec_add_buffer is guaranteed to be called before allocating
control pages, why not updating image-control_page after each time
kexec_add_buffer is called. Then when control page is needed, effective
address
On 12/04/13 at 09:56am, Baoquan He wrote:
On 11/20/13 at 12:50pm, Vivek Goyal wrote:
+ * that kexec_mutex is held.
+ */
I think kexec_add_buffer is guaranteed to be called before allocating
control pages, why not updating image-control_page after each time
kexec_add_buffer is called
On 02/19/14 at 05:04pm, Jon Mason wrote:
On Tue, Feb 18, 2014 at 11:18 PM, WANG Chao chaow...@redhat.com wrote:
Hi, All
arch/x86/kernel/pci-calgary.c is the only user of saved_max_pfn today:
int __init detect_calgary(void)
{
[..]
specified_table_size =
Hi,
I am reviewing this patchset, and found there's a cpu0 hotplug feature
posted by intel which we can borrow an idea from. In that implementation,
CPU0 is waken up by nmi not INIT to avoid the realmode bootstrap code
execution. I tried it by below patch which includes one line of change.
By
On 10/29/13 at 10:21pm, Baoquan He wrote:
Hi,
I am reviewing this patchset, and found there's a cpu0 hotplug feature
Forget to attach the link of patch for cpu0 hotplug.
http://lwn.net/Articles/475018/
In this patchset, BSP is also called CPU0.
posted by intel which we can borrow an idea
On 10/30/13 at 09:44am, HATAYAMA Daisuke wrote:
(2013/10/29 23:21), Baoquan He wrote:
Hi,
I am reviewing this patchset, and found there's a cpu0 hotplug feature
posted by intel which we can borrow an idea from. In that implementation,
CPU0 is waken up by nmi not INIT to avoid the realmode
On 09/06/2013 07:09 PM, Artem Savkov wrote:
On Fri, Sep 06, 2013 at 03:26:18PM +0800, Baoquan He wrote:
[ 30.438555] [ cut here ]
[ 30.443385] kernel BUG at include/linux/pagemap.h:343!
Seems to be the same one I reported here:
http://www.spinics.net/lists/kernel
Hi,
Patch is great and works on my HP-z420.
There are several small concerns, please see inline comments.
On 08/21/13 at 04:15pm, Takao Indoh wrote:
This patch quiesces devices before disabling IOMMU on boot to stop
ongoing DMA. In intel_iommu_init(), check context entries and if there
is
it always happened one day.
So maybe when it happened again, I will test your patch separately.
Baoquan
Thanks
On 08/31/2013 11:25 AM, Hillf Danton wrote:
On Fri, Aug 30, 2013 at 8:18 PM, Cong Wang xiyou.wangc...@gmail.com wrote:
Cc'ing netdev
On Fri, Aug 30, 2013 at 4:20 PM, Baoquan He baoquan
Hi Tianhong,
I applied your patch and execute below cmd.
Then keyboard inputting problems happened,
I can't enter user/password correctly, then reboot again, it's OK now.
The original bug still can't be reproduced.
make SUBDIRS=net/bridge/netfilter/
cp /net/bridge/netfilter/ebtables.ko
On 09/02/2013 05:04 PM, Ding Tianhong wrote:
On 2013/9/2 16:24, Baoquan He wrote:
Hi Tianhong,
I applied your patch and execute below cmd.
Then keyboard inputting problems happened,
I can't enter user/password correctly, then reboot again, it's OK now.
Thanks for your work, I don't
On 05/20/14 at 12:57am, Rafael J. Wysocki wrote:
On Monday, May 05, 2014 12:48:25 PM Baoquan He wrote:
This variable was defined and assigned in x86, is used to indicate
whether LAPIC exists in MADT. Now introduce it into ia64 to help
make correct judgment when get information for acpi
added to Copy-Translations patch to initialize the iovad
struct as recommended by Baoquan He [b...@redhat.com]
init_iova_domain(domain-iovad, DMA_32BIT_PFN);
v1-v2:
The following series implements a fix for:
A kdump problem about DMA that has been discussed for a long time
On 04/21/14 at 10:51pm, Rafael J. Wysocki wrote:
On Tuesday, April 15, 2014 07:55:54 AM Baoquan He wrote:
In smp with multi cpus, when enter into kdump kernel with only 1 cpu,
a warning message is printed out:
acpi LNXCPU:0a: BIOS reported wrong ACPI id 0 for the processor
get apic processor
id from x86_cpu_to_apicid.
Signed-off-by: Baoquan He b...@redhat.com
---
drivers/acpi/acpi_processor.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/acpi/acpi_processor.c b/drivers/acpi/acpi_processor.c
index c29c2c3..33f934d 100644
--- a/drivers
, Baoquan He wrote:
In acpi_processor_get_info(), acpi processor info is initialized including
id, namely cpu index. Currently, if on UP system running SMP kerenl with
no LAPIC in MADT, cpu0_initialized is checked if acpi processor id is
initialized.
However this check maybe is not correct for kdump
On 04/30/14 at 10:13pm, Rafael J. Wysocki wrote:
On Wednesday, April 30, 2014 02:03:03 PM Baoquan He wrote:
Hi Rafael,
Hi,
Thanks for previous review for v1. Later on I thought acpi_lapic is
more suitable for checking whether LAPIC in MADT is available, and it can
hanlde both the UP
in MADT is available, let's get apic processor
id from x86_cpu_to_apicid.
Signed-off-by: Baoquan He b...@redhat.com
---
drivers/acpi/acpi_processor.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/acpi/acpi_processor.c b/drivers/acpi/acpi_processor.c
index b06f5f5..bf0cce9
This variable was defined and assigned in x86, is used to indicate
whether LAPIC exists in MADT. Now introduce it into ia64 to help
make correct judgment when get information for acpi processor later.
Signed-off-by: Baoquan He b...@redhat.com
---
arch/ia64/include/asm/acpi.h | 1 +
arch/ia64
and adding debugging code.
acpi LNXCPU:0a: BIOS reported wrong ACPI id 0 for the processor.
For x86_64, the UP test is taken by adding disableapic nr_cpus=1 into
cmdline of grub. The test for kdump is the same as above ia64.
Thanks
Baoquan
On 05/05/14 at 12:48pm, Baoquan He wrote
On 05/05/14 at 01:14pm, Baoquan He wrote:
Hi Rafael,
Thanks for previous comments and suggestions.
I added the acpi_lapic in ia64. However I didn't find ia64 machine to
test it. Could you or anyone please help test this 2 patches?
I don't know how to test UP system running SMP kernel
Hi,
The kernel is 3.14.0+ which is pulled just now.
[ 18.402695] systemd[1]: Set hostname to
hp-sl4545g7-01.rhts.eng.bos.redhat.com.
[ 18.408456] random: systemd urandom read with 70 bits of entropy
available
[ 18md[1]: Expecting device
Hi Bill,
Could you rebase on latest linus's kernel tree, since there are several
changes in intel-iommu.c. This patch can't be applied because of below
commits. I think patch need be reabsed on latest linus's tree before
post, people will apply your patch without conflict.
commit
On 04/11/14 at 05:50pm, Petr Tesarik wrote:
To allow filtering of huge pages, makedumpfile must be able to
identify them in the dump. This can be done by checking the
appropriate page flag, so communicate its value to makedumpfile
through the VMCOREINFO interface.
There's only one small
On 04/21/14 at 10:51pm, Rafael J. Wysocki wrote:
On Tuesday, April 15, 2014 07:55:54 AM Baoquan He wrote:
In smp with multi cpus, when enter into kdump kernel with only 1 cpu,
a warning message is printed out:
acpi LNXCPU:0a: BIOS reported wrong ACPI id 0 for the processor
is not stored in x86_cpu_to_apicid,
then we can say this is UP system running SMP kernel with no LAPIC in MADT
Signed-off-by: Baoquan He b...@redhat.com
---
drivers/acpi/acpi_processor.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/acpi/acpi_processor.c b/drivers
, 2014-04-09 at 15:49 -0700, Davidlohr Bueso wrote:
On Wed, 2014-04-09 at 10:39 +0800, Baoquan He wrote:
Hi,
The kernel is 3.14.0+ which is pulled just now.
Cc'ing more people.
While the hpsa driver appears to be involved in some way, I'm sure if
this is a related issue
This patch works for me.
Tested-by: Baoquan He b...@redhat.com
Thanks
Baoquan
On 04/10/14 at 05:17pm, scame...@beardog.cce.hp.com wrote:
Without this, you'll see a null pointer dereference in
hpsa_enter_performant_mode().
Signed-off-by: Stephen M. Cameron scame...@beardog.cce.hp.com
-04-09 at 10:39 +0800, Baoquan He wrote:
Hi,
The kernel is 3.14.0+ which is pulled just now.
Cc'ing more people.
While the hpsa driver appears to be involved in some way, I'm sure if
this is a related issue, but as of today's pull I'm getting another
problem that causes my DL980
-by: Baoquan He b...@redhat.com
---
fs/proc/kcore.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/fs/proc/kcore.c b/fs/proc/kcore.c
index 39e6ef3..bf5127c 100644
--- a/fs/proc/kcore.c
+++ b/fs/proc/kcore.c
@@ -610,8 +610,10 @@ static void __init proc_kcore_text_init(void)
struct
to vmalloc range. If yes, just skip adding the modules
range.
Signed-off-by: Baoquan He b...@redhat.com
---
fs/proc/kcore.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/fs/proc/kcore.c b/fs/proc/kcore.c
index 39e6ef3..bf5127c 100644
--- a/fs/proc/kcore.c
+++ b/fs/proc/kcore.c
On 07/15/14 at 03:16pm, Andrew Morton wrote:
On Sun, 13 Jul 2014 09:05:46 +0800 Baoquan He b...@redhat.com wrote:
On some ARCHs modules range is eauql to vmalloc range. E.g on i686
#define MODULES_VADDR VMALLOC_START
#define MODULES_END VMALLOC_END
This will cause 2 duplicate
I have reviewed and tested this patchset. Without it the DMAR error
always occured as below. With this patchset, no error is reported and
kdump can work successfully.
This patchset is awesome, it get to the root of the problem when enable
intel-iommu in kdump and fix it. And from code no harm
On 12/19/13 at 07:49pm, Bill Sumner wrote:
+static int copy_page_addr(u64 page_addr, u32 shift, u32 bus, u32 devfn,
+ u64 pte, struct dmar_domain *domain,
+ void *parms)
+{
+ struct copy_page_addr_parms *ppap = parms;
+
+ u64
On 12/20/13 at 02:04pm, Baoquan He wrote:
On 12/19/13 at 07:49pm, Bill Sumner wrote:
+static int copy_page_addr(u64 page_addr, u32 shift, u32 bus, u32 devfn,
+ u64 pte, struct dmar_domain *domain,
+ void *parms)
+{
+ struct
adding
the modules range. If and only if modules range is not completely
included in vmalloc range just add it since the part out of vmalloc
range need be accessible.
Signed-off-by: Baoquan He b...@redhat.com
---
fs/proc/kcore.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git
On 08/26/14 at 07:38pm, Baoquan He wrote:
On some ARCHs modules range is eauql to vmalloc range. E.g on i686
#define MODULES_VADDR VMALLOC_START
#define MODULES_END VMALLOC_END
This will cause 2 duplicate program segments in /proc/kcore, and no
any flag to indicate both of them
the modules
range.
Signed-off-by: Baoquan He b...@redhat.com
---
fs/proc/kcore.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/fs/proc/kcore.c b/fs/proc/kcore.c
index 6df8d07..69cb67b 100644
--- a/fs/proc/kcore.c
+++ b/fs/proc/kcore.c
@@ -610,8 +610,11 @@ static void __init
On 07/15/14 at 03:16pm, Andrew Morton wrote:
On Sun, 13 Jul 2014 09:05:46 +0800 Baoquan He b...@redhat.com wrote:
On some ARCHs modules range is eauql to vmalloc range. E.g on i686
#define MODULES_VADDR VMALLOC_START
#define MODULES_END VMALLOC_END
This will cause 2 duplicate
-by: Baoquan He b...@redhat.com
---
include/linux/kexec.h | 1 +
kernel/kexec.c| 9 +
2 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/include/linux/kexec.h b/include/linux/kexec.h
index 4b2a0e1..9d957b7 100644
--- a/include/linux/kexec.h
+++ b/include/linux/kexec.h
it consistent with other places of check.
Signed-off-by: Baoquan He b...@redhat.com
---
arch/x86/kernel/crash.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/arch/x86/kernel/crash.c b/arch/x86/kernel/crash.c
index 0553a34..c9e83f9 100644
--- a/arch/x86/kernel/crash.c
On 08/12/14 at 05:00pm, Vivek Goyal wrote:
On Tue, Aug 12, 2014 at 01:29:27PM +0800, Baoquan He wrote:
In locate_mem_hole functions, a memory hole is located and added as
kexec_segment. But from the name of locate_mem_hole, it should only
take responsibility of searching a available memory
be recognised because it's marked as
anonymous page for now. However hugetlbfs huge pages and normal
huge pages can only be differentiated by compound_page_dtor,
hugetlbfs set free_huge_page as compound_page_dtor. So it makes
sense to export compound_page_dtor to VMCOREINFO.
Ack it.
Acked-by: Baoquan
To Eric and Andrew.
On 07/24/14 at 05:05pm, Baoquan He wrote:
On 07/11/14 at 10:34am, Atsushi Kumagai wrote:
PG_head_mask was added into VMCOREINFO to filter huge pages in
commit:b3acc56bfe1(kexec: save PG_head_mask in VMCOREINFO), but
makedumpfile still need another symbol to filter
This is a cleanup. In function parse_crashkernel_suffix, the
parameter crash_base is not used. So here remove it.
Signed-off-by: Baoquan He b...@redhat.com
---
kernel/kexec.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/kernel/kexec.c b/kernel/kexec.c
index 0b49a0a
On 10/14/14 at 08:49am, Vivek Goyal wrote:
On Mon, Oct 13, 2014 at 01:22:42PM -0400, Vivek Goyal wrote:
On Mon, Oct 13, 2014 at 08:43:00AM -0700, H. Peter Anvin wrote:
On 10/13/2014 08:19 AM, Vivek Goyal wrote:
This really shouldn't have happened this way on x86-64. It has to
the physical memory mappng
to a larger region if we want to randomize anywhere in physical space?
Thanks
Baoquan
On October 14, 2014 8:37:01 PM PDT, Baoquan He b...@redhat.com wrote:
On 10/14/14 at 08:49am, Vivek Goyal wrote:
On Mon, Oct 13, 2014 at 01:22:42PM -0400, Vivek Goyal wrote:
On Mon
On 10/16/14 at 07:55am, Baoquan He wrote:
On 10/15/14 at 01:32pm, H. Peter Anvin wrote:
I don't see why we can't randomize anywhere in physical space. We already
handle the kernel above 4 GB and it wouldn't be hard to do the equivalent
for the decompress/relocation code, using a #PF
Hi Zhenhua,
I tested your latest patch on 3.18.0-rc1+, there are still some dmar
errors. I remember it worked well with Bill's original patchset.
0console [earlya[0.00] allocate tes of page_cg 'a ong[
0.00] tsc: Fast TSC calibration using PIT
0031] Calibrating delay loop (skipped),
On 10/22/14 at 10:22am, Li, Zhen-Hua wrote:
Hi Baoquan,
I tested it on 3.17, it does not have these faults. There are little
differences between this version and Bill's last version.
I will test it on 3.18.0-rc1+ on my system and let you know the result.
And could you send me the
need this to calculate MODULES_VADDR. Since introduing kaslr, the
MODULES_VADDR is not fixed.
Baoquan He (3):
kaslr: check user's config too when handle relocations
kaslr: check if the random addr is available
export the kernel image size KERNEL_IMAGE_SIZE
Dave Young (1):
kaslr setup_data
-off-by: Baoquan He b...@redhat.com
---
arch/x86/boot/compressed/misc.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/x86/boot/compressed/misc.c b/arch/x86/boot/compressed/misc.c
index 7780a5b..d2a0eaa 100644
--- a/arch/x86/boot/compressed/misc.c
+++ b/arch/x86/boot/compressed
. So just set max mem avoid entries 32, hopefully
it will be enough. This can be increased later when people report
they are using more setup data entries.
Signed-off-by: Dave Young dyo...@redhat.com
Signed-off-by: Baoquan He b...@redhat.com
---
arch/x86/boot/compressed/aslr.c | 29
Now kaslr makes kernel image size changable, not the fixed size 512M.
So KERNEL_IMAGE_SIZE need be exported to VMCOREINFO, otherwise makedumfile
will crash.
Signed-off-by: Baoquan He b...@redhat.com
---
kernel/kexec.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/kernel/kexec.c b/kernel
. This is not correct.
So in this patch, check user's config too in the 2nd part, namely in
handle_relocations().
Signed-off-by: Baoquan He b...@redhat.com
---
arch/x86/boot/compressed/aslr.c | 2 ++
arch/x86/boot/compressed/misc.c | 12
2 files changed, 14 insertions(+)
diff --git a/arch/x86/boot
On 09/05/14 at 10:16am, Kees Cook wrote:
On Fri, Sep 5, 2014 at 7:08 AM, Baoquan He b...@redhat.com wrote:
diff --git a/arch/x86/boot/compressed/misc.c
b/arch/x86/boot/compressed/misc.c
index 7780a5b..d2a0eaa 100644
--- a/arch/x86/boot/compressed/misc.c
+++ b/arch/x86/boot/compressed
On 09/05/14 at 10:32am, Kees Cook wrote:
On Fri, Sep 05, 2014 at 10:08:16PM +0800, Baoquan He wrote:
From: Dave Young dyo...@redhat.com
X86 will pass setup_data region while necessary, these regions could be
overwitten by kernel due to kaslr.
Thus iterate and add setup regions
On 09/05/14 at 10:11am, Kees Cook wrote:
On Fri, Sep 5, 2014 at 7:08 AM, Baoquan He b...@redhat.com wrote:
kaslr's action is splitted into 2 parts. The 1st is getting available memory
slots and randomly choose the kernel relocation address. After decompression
of kernel to the chosen place
, it works well. So
do you like this it? If yes I will repost it.
From 13471bd838c52a0e143c2aee81e3863cfff585bd Mon Sep 17 00:00:00 2001
From: Baoquan He b...@redhat.com
Date: Mon, 25 Aug 2014 14:57:43 +0800
Subject: [PATCH] kaslr: check if kernel location is changed
Signed-off-by: Baoquan He b
Vivek suggested opening code function __kexec_add_segment(),
that way we have to retreive ksegment pointer once and it is easy to
read. So just do it in this patch and remove __kexec_add_segment()
since no one use it anymore.
Signed-off-by: Baoquan He b...@redhat.com
---
include/linux/kexec.h | 1
This is a cleanup. In function parse_crashkernel_suffix, the
parameter crash_base is not used. So here remove it.
Signed-off-by: Baoquan He b...@redhat.com
---
kernel/kexec.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/kernel/kexec.c b/kernel/kexec.c
index 63bc3cd
it consistent with other places of check.
Signed-off-by: Baoquan He b...@redhat.com
Acked-by: Vivek Goyal vgo...@redhat.com
---
arch/x86/kernel/crash.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/arch/x86/kernel/crash.c b/arch/x86/kernel/crash.c
index a618fcd
This change makes the Makefile of kexec purgatory be consistent with
others in linux src tree, and makes it look generic and simple.
Signed-off-by: Baoquan He b...@redhat.com
---
arch/x86/purgatory/Makefile | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/x86/purgatory
choose_kernel_location() when x86_64. If and only if in x86_64
and kernel location is changed, we say a kaslr random kernel
location is chosen, then the relocation handling need be done.
Signed-off-by: Baoquan He b...@redhat.com
---
arch/x86/boot/compressed/misc.c | 26 ++
1 file changed, 22
Now kaslr makes kernel image size changable, not the fixed size 512M.
So KERNEL_IMAGE_SIZE need be exported to VMCOREINFO, otherwise makedumfile
will crash.
Signed-off-by: Baoquan He b...@redhat.com
Acked-by: Kees Cook keesc...@chromium.org
Acked-by: Vivek Goyal vgo...@redhat.com
---
kernel
On 09/12/14 at 08:04am, Vivek Goyal wrote:
On Fri, Sep 12, 2014 at 02:20:31PM +0800, Baoquan He wrote:
Function handle_relocations() is used to do the relocations handling
for i686 and kaslr of x86_64. For 32 bit the relocation handling is
mandotary to perform. For x86_64 only when kaslr
a kaslr random kernel
location is chosen, then the relocation handling is needed.
Signed-off-by: Baoquan He b...@redhat.com
---
arch/x86/boot/compressed/misc.c | 26 ++
1 file changed, 22 insertions(+), 4 deletions(-)
diff --git a/arch/x86/boot/compressed/misc.c b/arch/x86
On 09/30/14 at 02:21pm, H. Peter Anvin wrote:
On 09/30/2014 12:08 AM, Baoquan He wrote:
Function handle_relocations() is used to do the relocations handling
for i686 and kaslr of x86_64. For 32 bit the relocation handling is
mandotary to perform. For x86_64 only when kaslr is enabled
a kaslr random kernel
location is chosen, then the relocation handling is needed.
Signed-off-by: Baoquan He b...@redhat.com
Acked-by: Vivek Goyal vgo...@redhat.com
Acked-by: Kees Cook keesc...@chromium.org
Tested-by: Thomas D. whi...@whissi.de
Cc: sta...@vger.kernel.org
---
arch/x86/boot
Now kaslr makes kernel image size changable, not the fixed size 512M.
So KERNEL_IMAGE_SIZE need be exported to VMCOREINFO, otherwise makedumfile
will crash.
Signed-off-by: Baoquan He b...@redhat.com
Acked-by: Kees Cook keesc...@chromium.org
Acked-by: Vivek Goyal vgo...@redhat.com
---
kernel
On 10/27/14 at 03:29pm, Li, ZhenHua wrote:
Hi Baoquan,
I failed in testing this patchset for 3.18.0-rc1, this upstream
3.18.0-rc1 kernel cannot boot on my system, have not found out the
reason.
Could you please test this patchset on 3.17.0 to see whether it has
these faults?
Thanks
On 10/15/14 at 11:37am, Baoquan He wrote:
On 10/14/14 at 08:49am, Vivek Goyal wrote:
On Mon, Oct 13, 2014 at 01:22:42PM -0400, Vivek Goyal wrote:
Agreed. On x86_64, we should be able to randomize virtual address space
and physical address space independently. And in that case whole
well. So
do you like this it? If yes I will repost it.
From 13471bd838c52a0e143c2aee81e3863cfff585bd Mon Sep 17 00:00:00 2001
From: Baoquan He b...@redhat.com
Date: Mon, 25 Aug 2014 14:57:43 +0800
Subject: [PATCH] kaslr: check if kernel location is changed
Signed-off-by: Baoquan He b
On 09/09/14 at 03:28pm, Vivek Goyal wrote:
On Tue, Sep 09, 2014 at 08:53:29AM -0700, Kees Cook wrote:
I still think this needs a test for the 32-bit case, since IUIC, it
requires relocations unconditionally.
[ CC hpa ]
Bao, for modifications in this area, I would recommend CC hpa too.
Sorry, CC this patchset to Andrew.
On 09/09/14 at 07:36pm, Baoquan He wrote:
In locate_mem_hole functions, a memory hole is located and added as
kexec_segment. But from the name of locate_mem_hole, it should only
take responsibility of searching a available memory hole to contain
data
On 09/09/14 at 03:41pm, Vivek Goyal wrote:
On Sat, Sep 06, 2014 at 06:16:57AM +0800, Baoquan He wrote:
[CC hpa ]
Hi Kees,
Yes, process_e820_entry() can make sure the choice+output_len
CONFIG_RANDOMIZE_BASE_MAX_OFFSET, but that can't stop other bootloaders
to put kernel in region
On 09/10/14 at 10:30am, Vivek Goyal wrote:
On Wed, Sep 10, 2014 at 03:21:15PM +0800, Baoquan He wrote:
In fact, I think below checking will be clearer and works too.
static void handle_relocations(void *output, unsigned long output_len)
{
...
#if CONFIG_X86_64
On 09/10/14 at 11:04am, Vivek Goyal wrote:
On Wed, Sep 10, 2014 at 10:53:34PM +0800, Baoquan He wrote:
On 09/10/14 at 10:30am, Vivek Goyal wrote:
In case of kdump we will have to pass nokaslr, as we don't want kernel
to move as it could stomp over other things we have loaded
On 09/10/14 at 11:05am, Vivek Goyal wrote:
On Wed, Sep 10, 2014 at 07:41:38AM -0700, Kees Cook wrote:
On Wed, Sep 10, 2014 at 7:30 AM, Vivek Goyal vgo...@redhat.com wrote:
So I would suggest that test and repost the other patch with proper
changelog
and that might be sufficient for
On 09/10/14 at 07:41am, Kees Cook wrote:
On Wed, Sep 10, 2014 at 7:30 AM, Vivek Goyal vgo...@redhat.com wrote:
So I would suggest that test and repost the other patch with proper
changelog
and that might be sufficient for now. Only other thing we will need is
Kees's patch for avoiding
On 11/13/14 at 05:06pm, Li, ZhenHua wrote:
Minfei,
Thanks for your testing.
On my system, I got error messages:
[8.019096] usb usb2: New USB device strings: Mfr=3, Product=2,
SerialNumber=1
[8.019617] dmar: DRHD: handling fault status reg 102
[8.019621] dmar: DMAR:[DMA Read]
On 11/28/2014 07:29 PM, Joerg Roedel wrote:
Hi,
here is a patch-set to fix failed kdump kernel boots when
the systems was booted with crashkernel=X,high. On those
systems the kernel allocates only 72MiB of low-memory for
DMA buffers, which showed to be too low on some systems.
The
On 11/13/14 at 11:30am, HATAYAMA Daisuke wrote:
Currently, VMCOREINFO note information reports the virtual address of
phys_base that is assigned to symbol phys_base. But this doesn't make
sense because to refer to phys_base, it's necessary to get the value
of phys_base itself we are now about
code.
I guess for_each_kimage_entry just does the work that kimage-destination
is expected to do.
So in this patch just make a cleanup to remove it.
Signed-off-by: Baoquan He b...@redhat.com
---
include/linux/kexec.h | 2 --
kernel/kexec.c| 4
2 files changed, 6 deletions(-)
diff
On 12/12/14 at 05:11pm, Joerg Roedel wrote:
On Fri, Dec 12, 2014 at 10:25:31AM +0800, Li, ZhenHua wrote:
Sorry I have no plan yet.
Could you send me your logs on your AMD system?
On 12/10/2014 04:46 PM, Baoquan He wrote:
This issue happens on AMD iommu too, do you have any plans
1 - 100 of 3124 matches
Mail list logo
