Re: [PATCH 4.14 023/159] mm/sparsemem: Allocate mem_section at runtime for CONFIG_SPARSEMEM_EXTREME=y

On 01/25/18 at 06:50pm, Kirill A. Shutemov wrote: > On Wed, Jan 17, 2018 at 01:24:54PM +0800, Baoquan He wrote: > > Hi Kirill, > > > > I setup qemu 2.9.0 to test 5-level on kexec/kdump support. While both > > kexec and kdump reset to BIOS immediately after triggering.

Re: Kdump kernel start failed with intel_iommu=on

On 01/23/18 at 06:20pm, Weilong Chen wrote: > Hi, > > We came across this problem: > Second kernel hang with intel_iommu=on > > We can reproduce the problem by the following steps: > 1. start the kernel with intel_iommu=on > 2. ifconfig eth6 up;ifconfig eth8 up.(eth6 is Intel Corporation 82599ES

Re: [PATCH v6 5/5] kaslr: add kaslr_mem=nn[KMG]!ss[KMG] to avoid memory regions

On 01/16/18 at 11:34am, Luiz Capitulino wrote: > On Tue, 16 Jan 2018 08:43:20 +0800 > Baoquan He <b...@redhat.com> wrote: > > > On 01/15/18 at 08:49pm, Chao Fan wrote: > > > Hi Luiz, > > > > > > I don't know if this patch is OK for you. > >

Re: [PATCH 4.14 023/159] mm/sparsemem: Allocate mem_section at runtime for CONFIG_SPARSEMEM_EXTREME=y

Hi Kirill, I setup qemu 2.9.0 to test 5-level on kexec/kdump support. While both kexec and kdump reset to BIOS immediately after triggering. I saw your patch adding 5-level paging support for kexec. Wonder if your test succeeded to jump into kexec/kdump kernel, and what else I need to make it. By

Re: [RESEND PATCH 1/3] x86/apic: Set up through LAPIC on boot CPU's LINT0 if ioapic is disabled

CC Eric On 01/05/18 at 12:37pm, Baoquan He wrote: > Kdump kernel will become very slow if 'noapic' is specified in kernel > command line. Normal kernel doesn't have this issue. > > This is because the legacy irq mode is disabled in crashed kernel before > jump jump to kdump kern

Re: [RESEND PATCH 3/3] x86/apic: Clean up the names of legacy irq mode setting related functions

CC Eric On 01/05/18 at 12:39pm, Baoquan He wrote: > X86 MP spec defines 3 different interrupt modes: > 1) PIC Mode—bypasses all APIC components and forces the system to > operate in single-processor mode. > 2) Virtual Wire Mode—uses an APIC as a virtual wire, b

Re: [RESEND PATCH 2/3] x86/apic/kexec: Enable legacy irq mode before jump to kexec/kdump kernel

CC Eric On 01/05/18 at 12:38pm, Baoquan He wrote: > In commit > > commit 522e66464467 ("x86/apic: Disable I/O APIC before shutdown of the local > APIC"). > > lapic_shutdown() invocation is moved after disable_IO_APIC(). In fact > in disable_IO_APIC(),

Re: [RESEND PATCH 2/3] x86/apic/kexec: Enable legacy irq mode before jump to kexec/kdump kernel

On 01/17/18 at 05:47pm, Dou Liyang wrote: > Hi Baoquan, > > At 01/05/2018 12:38 PM, Baoquan He wrote: > > In commit > > > > commit 522e66464467 ("x86/apic: Disable I/O APIC before shutdown of the > > local APIC"). > > > > lapic_shutdown

Re: [RESEND PATCH 3/3] x86/apic: Clean up the names of legacy irq mode setting related functions

On 01/19/18 at 02:42pm, Dou Liyang wrote: > Hi Baoquan, > > At 01/05/2018 12:39 PM, Baoquan He wrote: > [...] > > /* > > - * Not an __init, needed by kexec/kdump code. > > - * For safety IO-APIC and Local APIC need be cleared before this. > > + * In leg

[PATCH v2 1/2] x86/apic/kexec: Enable legacy irq mode before jump to kexec/kdump kernel

cy_irq_mode before kexec/kdump jumping. Signed-off-by: Baoquan He <b...@redhat.com> --- arch/x86/include/asm/io_apic.h | 3 ++- arch/x86/kernel/apic/io_apic.c | 12 arch/x86/kernel/crash.c| 2 +- arch/x86/kernel/machine_kexec_32.c | 15 +-- arc

[PATCH v2 0/2] x86/apic/kexec: Legacy irq setting fixs in kdump kernel

This is v2 post. In v2, no code change, just improve change log of patch 1 and 2. And drop the old patch 3 in v1, a clean up patch. The current x86_io_apic_ops.disable() hook is still needed by irq remapping. Baoquan He (2): x86/apic/kexec: Enable legacy irq mode before jump to kexec/kdump

[PATCH v2 2/2] x86/apic: Set up through-local-APIC on boot CPU's LINT0 if 'noapic' specified

if 'noapic' specified. Do it now. Signed-off-by: Baoquan He <b...@redhat.com> --- arch/x86/kernel/apic/apic.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/x86/kernel/apic/apic.c b/arch/x86/kernel/apic/apic.c index 25ddf02598d2..3fc259b4dd2d 100644 --- a/arch/x86/ke

Re: KASLR may break some kernel features (was Re: [PATCH v5 1/4] kaslr: add immovable_mem=nn[KMG]@ss[KMG] to specify extracting memory)

On 01/12/18 at 01:52pm, Luiz Capitulino wrote: > On Fri, 12 Jan 2018 10:47:53 +0800 > Chao Fan <fanc.f...@cn.fujitsu.com> wrote: > > > On Fri, Jan 12, 2018 at 10:31:52AM +0800, Baoquan He wrote: > > >On 01/11/18 at 10:04am, Kees Cook wrote: > > >> On T

Re: KASLR may break some kernel features (was Re: [PATCH v5 1/4] kaslr: add immovable_mem=nn[KMG]@ss[KMG] to specify extracting memory)

On 01/11/18 at 10:04am, Kees Cook wrote: > On Thu, Jan 11, 2018 at 1:00 AM, Baoquan He <b...@redhat.com> wrote: > > Hi Luiz, > > > > On 01/04/18 at 11:21am, Luiz Capitulino wrote: > >> Having a generic kaslr parameter to control where the kernel is extracted &

Re: [RESEND PATCH 0/3] x86/apic/kexec: Enable legacy irq mode before jump to kexec/kdump kernel

On 01/11/18 at 01:05pm, Eric W. Biederman wrote: > Baoquan He <b...@redhat.com> writes: > > > Hi all, > > > > PING! > > > > (Add Fenghua and Eric to this thread) > > > > On 01/05/18 at 11:42am, Baoquan He wrote: > >> On kvm

Re: KASLR may break some kernel features (was Re: [PATCH v5 1/4] kaslr: add immovable_mem=nn[KMG]@ss[KMG] to specify extracting memory)

Hi Kees, On 01/11/18 at 10:04am, Kees Cook wrote: > On Thu, Jan 11, 2018 at 1:00 AM, Baoquan He <b...@redhat.com> wrote: > > Hi Luiz, > > > > On 01/04/18 at 11:21am, Luiz Capitulino wrote: > >> Having a generic kaslr parameter to control where the kern

Re: [PATCH 2/2] mm/sparse.c: Add nr_present_sections to change the mem_map allocation

On 02/01/18 at 05:49am, Dave Hansen wrote: > On 02/01/2018 02:16 AM, Kirill A. Shutemov wrote: > > On Thu, Feb 01, 2018 at 03:19:56PM +0800, Baoquan He wrote: > >> In sparse_init(), we allocate usemap_map and map_map which are pointer > >> array with the size of

Re: [PATCH 1/2] mm/sparsemem: Defer the ms->section_mem_map clearing a little later

On 02/01/18 at 06:15am, Dave Hansen wrote: > On 01/31/2018 11:19 PM, Baoquan He wrote: > > for_each_present_section_nr(0, pnum) { > > + struct mem_section *ms; > > + ms = __nr_to_section(pnum); > > usemap = usemap_map[pnum];

Re: [PATCH 2/2] mm/sparse.c: Add nr_present_sections to change the mem_map allocation

On 02/01/18 at 06:23am, Dave Hansen wrote: > On 02/01/2018 06:19 AM, Baoquan He wrote: > > > > I suppose these functions changed here are only called during system > > bootup, namely in paging_init(). Hot-add memory goes in a different > > path, __add_section(

Re: [PATCH] x86/kexec: Make kexec work in 5-level paging mode

vious CR4 value. This way the code is > ready for boot-time switching between paging modes. > > Fixes: 77ef56e4f0fb ("x86: Enable 5-level paging support via > CONFIG_X86_5LEVEL=y") > Signed-off-by: Kirill A. Shutemov <kirill.shute...@linux.intel.com> > Reported

Re: [PATCH] x86/kexec: Make kexec work in 5-level paging mode

On 01/29/18 at 07:19pm, Baoquan He wrote: > On 01/29/18 at 02:08pm, Kirill A. Shutemov wrote: > > I've missed that we need to change relocate_kernel() to set CR4.LA57 > > flag if the kernel has 5-level paging enabled. > > > > I avoided to use ifdef CONFIG_X86_5LEVEL h

[PATCH 1/2] mm/sparsemem: Defer the ms->section_mem_map clearing a little later

This will make sure number of sections marked as present won't be changed in sparse_init(), so that for_each_present_section_nr() can iterate each of them. This is preparation for later fix. Signed-off-by: Baoquan He <b...@redhat.com> --- mm/sparse-vmemmap.c | 1 - mm/sparse.c

[PATCH 2/2] mm/sparse.c: Add nr_present_sections to change the mem_map allocation

much memory on most of systems. Anytime, we should avoid to define array or allocate memory with the size of NR_MEM_SECTIONS. Signed-off-by: Baoquan He <b...@redhat.com> --- mm/sparse-vmemmap.c | 8 +--- mm/sparse.c | 39 +-- 2 files chang

[PATCH 0/2] Optimize the code of mem_map allocation in

, though it's a temporary allocation. Baoquan He (2): mm/sparsemem: Defer the ms->section_mem_map clearing a little later mm/sparse.c: Add nr_present_sections to change the mem_map allocation mm/sparse-vmemmap.c | 9 + mm/sparse.c |

Re: [PATCH 4.14 023/159] mm/sparsemem: Allocate mem_section at runtime for CONFIG_SPARSEMEM_EXTREME=y

On 02/08/18 at 09:14am, Dou Liyang wrote: > Hi Baoquan, > > At 02/07/2018 08:45 PM, Baoquan He wrote: > > On 02/07/18 at 08:34pm, Dou Liyang wrote: > > > > > > > > > At 02/07/2018 08:27 PM, Baoquan He wrote: > > > > On 02/07

Re: [PATCH v3 2/5] x86/apic: Fix restoring boot irq mode in reboot and kexec/kdump

On 02/11/18 at 09:08pm, Eric W. Biederman wrote: > Baoquan He <b...@redhat.com> writes: > > > This is a regression fix. > > > > Before, to fix erratum AVR31, commit 522e66464467 ("x86/apic: Disable > > I/O APIC before shutdown of the local APIC&q

Re: [PATCH v3 0/5] x86/apic: Fix restoring boot irq mode in reboot and kexec/kdump

On 02/11/18 at 11:11pm, Eric W. Biederman wrote: > Dou Liyang writes: > > > Hi all, > > > > One thing confused me. > > > > The disconnect_bsp_APIC() may restore the interrupt delivery mode into > > virtual wire mode. it uses the vector F as the spurious interrput, But,

Re: [PATCH v3 2/5] x86/apic: Fix restoring boot irq mode in reboot and kexec/kdump

On 02/13/18 at 10:43am, Dou Liyang wrote: > Hi Baoquan, > > At 02/12/2018 11:08 AM, Eric W. Biederman wrote: > > Baoquan He <b...@redhat.com> writes: > > > > > This is a regression fix. > > > > > > Before, to fix erratum AVR31, commit

Re: [PATCH v3 2/5] x86/apic: Fix restoring boot irq mode in reboot and kexec/kdump

Hi Eric, On 02/11/18 at 09:08pm, Eric W. Biederman wrote: > Baoquan He <b...@redhat.com> writes: > > > This is a regression fix. > > > > Before, to fix erratum AVR31, commit 522e66464467 ("x86/apic: Disable > > I/O APIC before shutdown of the local APIC&q

[PATCH v4 0/5] x86/apic: Fix restoring boot irq mode in reboot and kexec/kdump

is not right. Correct it. Add Fixes tag and Cc to stable. v2->v3: Change as Eric suggested: Rerrange patches and change code and messy function/variable naming. Change patch subject and log to make it more understandable. Baoquan He (5): x86/apic: Split out restore_bo

[PATCH v4 2/5] x86/apic: Fix restoring boot irq mode in reboot and kexec/kdump

ittle different then reboot and kexec/kdump. It doesn't call lapic_shutdown() before jump, so is not impacted by commit 522e66464467. Here in order to keep it the same as the old code, replace the old disable_IO_APIC() with clear_IO_APIC() and restore_boot_irq_mode(). Signed-off-by: Baoquan He <

[PATCH v4 5/5] x86/apic: Set up through-local-APIC on boot CPU if 'noapic' specified

ugh we fix the regression introduced by criminal commit 522e664644, for safety and clarity, better set up through-local-APIC explicitly, but not rely on the default boot irq mode. Do it now. Signed-off-by: Baoquan He <b...@redhat.com> --- arch/x86/kernel/apic/apic.c | 2 +- 1 file changed, 1 insertio

[PATCH v4 4/5] x86/apic: Rename variable/function related to x86_io_apic_ops

to x86_apic_ops since it doesn't only handle IO_APIC, also LAPIC. And also rename its member variables and the related hooks. Signed-off-by: Baoquan He <b...@redhat.com> --- arch/x86/include/asm/io_apic.h | 6 +++--- arch/x86/include/asm/x86_init.h | 8 arch/x86/kernel/apic/io_apic.

[PATCH v4 3/5] x86/apic: Remove useless disable_IO_APIC

No one uses it anymore. Signed-off-by: Baoquan He <b...@redhat.com> --- arch/x86/include/asm/io_apic.h | 1 - arch/x86/kernel/apic/io_apic.c | 13 - arch/x86/kernel/machine_kexec_32.c | 5 ++--- arch/x86/kernel/machine_kexec_64.c | 5 ++--- 4 files changed, 4 inse

[PATCH v4 1/5] x86/apic: Split out restore_boot_irq_mode from disable_IO_APIC

This is a preparation patch. Split out the code which restores boot irq mode from disable_IO_APIC() and wrap into a new function restore_boot_irq_mode(). No functional change. Signed-off-by: Baoquan He <b...@redhat.com> --- arch/x86/include/asm/io_apic.h | 1 + arch/x86/kernel/apic/io_apic

Re: [PATCH v3 2/5] x86/apic: Fix restoring boot irq mode in reboot and kexec/kdump

On 02/13/18 at 11:44am, Eric W. Biederman wrote: > Baoquan He <b...@redhat.com> writes: > > > Hi Eric, > > > > On 02/11/18 at 09:08pm, Eric W. Biederman wrote: > >> Baoquan He <b...@redhat.com> writes: > >> > >> > This is a

[PATCH v5 2/6] x86/apic: Replace disable_IO_APIC for KEXEC_JUMP

functional change. Signed-off-by: Baoquan He <b...@redhat.com> --- v4->v5: Make this patch to replace disable_IO_APIC() with clear_IO_APIC and restore_boot_irq_mode() for KEXEC_JUMP path only. This makes patch easier to review according to Eric's suggestion.. arch/x86/include/as

[PATCH v5 4/6] x86/apic: Remove useless disable_IO_APIC

No one uses it anymore. Signed-off-by: Baoquan He <b...@redhat.com> --- arch/x86/include/asm/io_apic.h | 1 - arch/x86/kernel/apic/io_apic.c | 13 - arch/x86/kernel/machine_kexec_32.c | 5 ++--- arch/x86/kernel/machine_kexec_64.c | 5 ++--- 4 files changed, 4 inse

[PATCH v5 1/6] x86/apic: Split out restore_boot_irq_mode from disable_IO_APIC

This is a preparation patch. Split out the code which restores boot irq mode from disable_IO_APIC() and wrap into a new function restore_boot_irq_mode(). No functional change. Signed-off-by: Baoquan He <b...@redhat.com> --- arch/x86/include/asm/io_apic.h | 1 + arch/x86/kernel/apic/io_apic

[PATCH v5 3/6] x86/apic: Fix restoring boot irq mode in reboot and kexec/kdump

]--- [0.001000] masked ExtINT on CPU#0 To fix this, just call clear_IO_APIC() to stop IO_APIC where disable_IO_APIC() was called, and call restore_boot_irq_mode() to restore boot irq mode before reboot or kexec/kdump jump. Signed-off-by: Baoquan He <b...@redhat.com> Fixes: commit 522

[PATCH v5 0/6] x86/apic: Fix restoring boot irq mode in reboot and kexec/kdump

Fixes tag and Cc to stable. v2->v3: Change as Eric suggested: Rerrange patches and change code and messy function/variable naming. Change patch subject and log to make it more understandable. *** BLURB HERE *** Baoquan He (6): x86/apic: Split out restore_boot_irq_mode from disable_IO_APIC

[PATCH v5 5/6] x86/apic: Rename variable/function related to x86_io_apic_ops

to x86_apic_ops since it doesn't only handle IO_APIC, also LAPIC. And also rename its member variables and the related hooks. Signed-off-by: Baoquan He <b...@redhat.com> --- arch/x86/include/asm/io_apic.h | 6 +++--- arch/x86/include/asm/x86_init.h | 8 arch/x86/kernel/apic/io_apic.

[PATCH v5 6/6] x86/apic: Set up through-local-APIC on boot CPU if 'noapic' specified

ugh we fix the regression introduced by criminal commit 522e664644, for safety and clarity, better set up through-local-APIC explicitly, but not rely on the default boot irq mode. Do it now. Signed-off-by: Baoquan He <b...@redhat.com> --- arch/x86/kernel/apic/apic.c | 2 +- 1 file changed, 1 insertio

[PATCH v3 5/5] x86/apic: Set up through-local-APIC on boot CPU if 'noapic' specified

ugh we fix the regression introduced by criminal commit 522e664644, for safety and clarity, better set up through-local-APIC explicitly, but not rely on the default boot irq mode. Do it now. Signed-off-by: Baoquan He <b...@redhat.com> --- arch/x86/kernel/apic/apic.c | 2 +- 1 file changed, 1 insertio

[PATCH v3 4/5] x86/apic: Rename variable/function related to x86_io_apic_ops

to x86_apic_ops since it doesn't only handle IO_APIC, also LAPIC. And also rename its member variables and the related hooks. Signed-off-by: Baoquan He <b...@redhat.com> --- arch/x86/include/asm/io_apic.h | 6 +++--- arch/x86/include/asm/x86_init.h | 8 arch/x86/kernel/apic/io_apic.

[PATCH v3 1/5] x86/apic: Split out restore_boot_irq_mode from disable_IO_APIC

This is a preparation patch. Split out the code which restores boot irq mode from disable_IO_APIC() and wrap into a new function restore_boot_irq_mode(). No functional change. Signed-off-by: Baoquan He <b...@redhat.com> --- arch/x86/include/asm/io_apic.h | 1 + arch/x86/kernel/apic/io_apic

[PATCH v3 2/5] x86/apic: Fix restoring boot irq mode in reboot and kexec/kdump

efore reboot or kexec/kdump jump. Signed-off-by: Baoquan He <b...@redhat.com> --- arch/x86/include/asm/io_apic.h | 1 + arch/x86/kernel/apic/io_apic.c | 2 +- arch/x86/kernel/crash.c| 3 ++- arch/x86/kernel/machine_kexec_32.c | 2 +- arch/x86/kernel/machine_kexec_64.c

[PATCH v3 3/5] x86/apic: Remove useless disable_IO_APIC

No one uses it anymore. Signed-off-by: Baoquan He <b...@redhat.com> --- arch/x86/include/asm/io_apic.h | 1 - arch/x86/kernel/apic/io_apic.c | 13 - arch/x86/kernel/machine_kexec_32.c | 5 ++--- arch/x86/kernel/machine_kexec_64.c | 5 ++--- 4 files changed, 4 inse

[PATCH v3 0/5] x86/apic: Fix restoring boot irq mode in reboot and kexec/kdump

ys be seen during kdump kernel boot on qemu/kvm platform. Our customer even saw casual kdump kernel hang once in ~30 attempts during stress testing of kdump on KVM machine. This is v3 post, patches are rearranged and changed according to Eric's suggestions. Baoquan He (5): x86/apic:

Re: [PATCH v2 1/2] x86/apic/kexec: Enable legacy irq mode before jump to kexec/kdump kernel

On 02/07/18 at 01:48pm, Eric W. Biederman wrote: > ebied...@xmission.com (Eric W. Biederman) writes: > > Now that I see that I agree in essence with this patch series. > > I don't agree with the implemenation details. > > > > Can you please split disable_IO_APIC and switch_to_legacy_irq_mode > >

Re: [PATCH 4.14 023/159] mm/sparsemem: Allocate mem_section at runtime for CONFIG_SPARSEMEM_EXTREME=y

On 02/07/18 at 05:25pm, Dou Liyang wrote: > Hi All, > > I met the makedumpfile failed in the upstream kernel which contained > this patch. Did I missed something else? readmem: Can't convert a virtual address(88007ffd7000) to physical Should not related to this patch. Otherwise your code

Re: [PATCH 4.14 023/159] mm/sparsemem: Allocate mem_section at runtime for CONFIG_SPARSEMEM_EXTREME=y

On 02/07/18 at 08:00pm, Dou Liyang wrote: > Hi Kirill,Mike > > At 02/07/2018 06:45 PM, Mike Galbraith wrote: > > On Wed, 2018-02-07 at 13:41 +0300, Kirill A. Shutemov wrote: > > > On Wed, Feb 07, 2018 at 05:25:05PM +0800, Dou Liyang wrote: > > > > Hi All, > > > > > > > > I met the makedumpfile

Re: [PATCH 4.14 023/159] mm/sparsemem: Allocate mem_section at runtime for CONFIG_SPARSEMEM_EXTREME=y

On 02/07/18 at 08:17pm, Dou Liyang wrote: > Hi Baoquan, > > At 02/07/2018 08:08 PM, Baoquan He wrote: > > On 02/07/18 at 08:00pm, Dou Liyang wrote: > > > Hi Kirill,Mike > > > > > > At 02/07/2018 06:45 PM, Mike Galbraith wrote: > > > > On We

Re: [PATCH 4.14 023/159] mm/sparsemem: Allocate mem_section at runtime for CONFIG_SPARSEMEM_EXTREME=y

On 02/07/18 at 08:34pm, Dou Liyang wrote: > > > At 02/07/2018 08:27 PM, Baoquan He wrote: > > On 02/07/18 at 08:17pm, Dou Liyang wrote: > > > Hi Baoquan, > > > > > > At 02/07/2018 08:08 PM, Baoquan He wrote: > > > > On 02/07/18

Re: [PATCH v5 0/6] x86/apic: Fix restoring boot irq mode in reboot and kexec/kdump

On 02/17/18 at 11:46am, Ingo Molnar wrote: > > * Baoquan He <b...@redhat.com> wrote: > > > Thanks for checking this! > > > > I got warning message from kbuild test robot on previous v3 and v4. I > > guess this v5 post also has the issue since the

Re: [PATCH v5 0/6] x86/apic: Fix restoring boot irq mode in reboot and kexec/kdump

Hi Ingo, Eric, On 02/16/18 at 10:38am, Ingo Molnar wrote: > > * Baoquan He <b...@redhat.com> wrote: > > > This is v5 post. Newly added patch 0002 includes the change > > related to KEXEC_JUMP path. Patch 0003 only includes the > > regression fix. > &g

[PATCH v2 3/3] mm/sparse: Optimize memmap allocation during sparse_init()

-by: Baoquan He <b...@redhat.com> Signed-off-by: Baoquan He <b...@redhat.com> --- mm/sparse-vmemmap.c | 8 +--- mm/sparse.c | 40 ++-- 2 files changed, 31 insertions(+), 17 deletions(-) diff --git a/mm/sparse-vmemmap.c b/mm/sparse-vmem

[PATCH v2 2/3] mm/sparsemem: Defer the ms->section_mem_map clearing

) loop. This is in preparation for later optimizing the mem map allocation. Signed-off-by: Baoquan He <b...@redhat.com> --- mm/sparse-vmemmap.c | 1 - mm/sparse.c | 12 2 files changed, 8 insertions(+), 5 deletions(-) diff --git a/mm/sparse-vmemmap.c b/mm/sparse-vme

[PATCH v2 1/3] mm/sparse: Add a static variable nr_present_sections

It's used to record how many memory sections are marked as present during system boot up, and will be used in the later patch. Signed-off-by: Baoquan He <b...@redhat.com> --- mm/sparse.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/mm/sparse.c b/mm/sparse.c index 7af5e7

[PATCH v2 0/3] mm/sparse: Optimize memmap allocation during sparse_init()

allocation code to only use usemap_map and map_map with the size of nr_present_sections. This makes kdump kernel boot up with normal crashkernel='' setting when CONFIG_X86_5LEVEL=y. Baoquan He (3): mm/sparse: Add a static variable nr_present_sections mm/sparsemem: Defer the ms->section_mem_

Re: [PATCH v2 0/3] mm/sparse: Optimize memmap allocation during sparse_init()

On 02/22/18 at 05:11pm, Baoquan He wrote: > This is v2 post. V1 can be found here: > https://www.spinics.net/lists/linux-mm/msg144486.html > > In sparse_init(), two temporary pointer arrays, usemap_map and map_map > are allocated with the size of NR_MEM_SECTIONS. They are used

Re: [PATCH v2 3/3] mm/sparse: Optimize memmap allocation during sparse_init()

usemap_map and map_map with the size of > > 'nr_present_sections'. For the i-th present memory section, install its > > usemap and memmap to usemap_map[i] and mam_map[i] during allocation. Then > > in the last for_each_present_section_nr() loop which clears the failed > > memory

Re: [PATCH v2 1/3] mm/sparse: Add a static variable nr_present_sections

On 02/22/18 at 01:24pm, Andrew Morton wrote: > On Thu, 22 Feb 2018 17:11:28 +0800 Baoquan He <b...@redhat.com> wrote: > > > It's used to record how many memory sections are marked as present > > during system boot up, and will be used in the later patch. > > >

Re: [PATCH v2 3/3] mm/sparse: Optimize memmap allocation during sparse_init()

On 02/22/18 at 02:22pm, Dave Hansen wrote: > First of all, this is a much-improved changelog. Thanks for that! > > On 02/22/2018 01:11 AM, Baoquan He wrote: > > In sparse_init(), two temporary pointer arrays, usemap_map and map_map > > are allocated with the si

[PATCH] mm/sparse.c: Wrong allocation for mem_section

em_section*). Fix it. Signed-off-by: Baoquan He <b...@redhat.com> Tested-by: Dave Young <dyo...@redhat.com> Cc: Ingo Molnar <mi...@kernel.org> Cc: Andrew Morton <a...@linux-foundation.org> Cc: Andy Lutomirski <l...@amacapital.net> Cc: Peter Zijlstra <p

Re: [PATCH v2] x86/kexec: Exclude GART aperture from vmcore

On 12/19/17 at 06:58pm, Jiri Bohac wrote: Sorry for late response. Please see the inline comments. > > On Tue, Dec 19, 2017 at 09:58:04AM +0800, Baoquan He wrote: > > Hmm, as I have said in the first replying mail, the v2 will introduce > > issues: > > > > 1) If '

Re: [PATCH v2] x86/kexec: Exclude GART aperture from vmcore

On 12/27/17 at 01:25pm, Borislav Petkov wrote: > On Wed, Dec 27, 2017 at 03:44:49PM +0800, Baoquan He wrote: > > > yes, instead of crashing the machine (because GART may be initialized in > > > the > > > 2nd kernel, overlapping the 1st kernel memory, which

Re: [PATCH] x86/KASLR: move aligning of minimal address to choose_random_location()

On 01/04/18 at 03:54pm, Alexander Kuleshov wrote: > we align minimal possible address during randomization to > CONFIG_PHYSICAL_ALIGN > two times: during getting of random physical address and virtual > address (only for x86_64). > > Let's move this to choose_random_location() to not duplicate

Re: [PATCH 1/2] x86/boot/KASLR: Add two functions for 1GB huge pages handling

On 06/21/18 at 05:01pm, Ingo Molnar wrote: > > * Baoquan He wrote: > > > +/* Store the number of 1GB huge pages which user specified.*/ > > +static unsigned long max_gb_huge_pages; > > + > > +static int parse_gb_huge_pages(char *param, char* val) > > +

Re: [RESEND] [PATCH 1/2] x86/mm: Add an option to change the padding used for the physical memory mapping.

Hi Masa, On 08/21/18 at 09:24am, Masayoshi Mizuma wrote: > From: Masayoshi Mizuma > > There are some exceptional cases that the padding used for the physical > memory mapping section is not enough. > > For example of the cases: > - As Baoquan reported in the following, SGI UV system. >

[PATCH 1/2] x86/mm/KASLR: Fix the wrong calculation of kalsr region initial size

igger than 64TB. In fact, here MAX_PHYSMEM_BITS should be used instead. Fix it by by replacing __PHYSICAL_MASK_SHIFT with MAX_PHYSMEM_BITS. Signed-off-by: Baoquan He --- arch/x86/mm/kaslr.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/x86/mm/kaslr.c b/arch/x86/mm/kas

[PATCH 2/2] x86/mm/KASLR: Adjust the vmemmap size according to paging mode

Vmemmap area has different base and size depending on paging mode. Now we just hardcode its size as 1TB in memory KASLR, it's not right for 5-level paging mode. Adjust it according to paging mode and use it during memory KASLR. Signed-off-by: Baoquan He --- arch/x86/include/asm

Re: [PATCH v5 4/4] x86/boot/KASLR: Limit kaslr to choosing the immovable memory

On 08/27/18 at 02:28pm, Chao Fan wrote: > >Is it possible to take num_immovable_mem definition out from #ifdef > >CONFIG_MEMORY_HOTREMOVE block and check it here like below? This way, > >one level of indentation can be reduced in the for loop, and code is > >more readable. > > > > I think there

Re: [PATCH v5 4/4] x86/boot/KASLR: Limit kaslr to choosing the immovable memory

On 08/27/18 at 01:56pm, Baoquan He wrote: > On 08/07/18 at 02:50pm, Chao Fan wrote: > > If 'CONFIG_MEMORY_HOTREMOVE' specified and the account of immovable > If CONFIG_MEMORY_HOTREMOVE is enabled, > > memory regions is not zero. Calculate the intersection between memory > &g

Re: [PATCH v5 4/4] x86/boot/KASLR: Limit kaslr to choosing the immovable memory

On 08/27/18 at 01:35pm, Baoquan He wrote: > Is it possible to take num_immovable_mem out from the #ifdef > CONFIG_MEMORY_HOTREMOVE region so that you can check it earlier to see > if the old way need be taken? This way, we can reduce one level of > indentation in the for loop. J

Re: [PATCH v5 4/4] x86/boot/KASLR: Limit kaslr to choosing the immovable memory

On 08/07/18 at 02:50pm, Chao Fan wrote: > If 'CONFIG_MEMORY_HOTREMOVE' specified and the account of immovable If CONFIG_MEMORY_HOTREMOVE is enabled, > memory regions is not zero. Calculate the intersection between memory > regions from e820/efi memory table and immovable memory regions. > Or go

Re: [PATCH v5 3/4] x86/boot/KASLR: Walk srat tables to filter immovable memory

On 08/07/18 at 02:49pm, Chao Fan wrote: > If 'CONFIG_MEMORY_HOTREMOVE' specified, walk the acpi srat memory > tables, store the immovable memory regions, so that kaslr can get > the information abouth where can be selected or not. > If 'CONFIG_MEMORY_HOTREMOVE' not specified, go on the old code.

Re: [PATCH v5 3/4] x86/boot/KASLR: Walk srat tables to filter immovable memory

On 08/27/18 at 10:56am, Chao Fan wrote: > >> +#ifdef CONFIG_MEMORY_HOTREMOVE > >> +/* > >> + * According to ACPI table, filter the immvoable memory regions > >> + * and store them in immovable_mem[]. > >> + */ > >> +static void handle_immovable_mem(void) > > > >Can we change this function like

Re: [PATCH v5 4/4] x86/boot/KASLR: Limit kaslr to choosing the immovable memory

On 08/07/18 at 02:50pm, Chao Fan wrote: > If 'CONFIG_MEMORY_HOTREMOVE' specified and the account of immovable > memory regions is not zero. Calculate the intersection between memory > regions from e820/efi memory table and immovable memory regions. > Or go on the old code. > > Rename

Re: [PATCH v5 3/4] x86/boot/KASLR: Walk srat tables to filter immovable memory

On 08/07/18 at 02:49pm, Chao Fan wrote: > If 'CONFIG_MEMORY_HOTREMOVE' specified, walk the acpi srat memory > tables, store the immovable memory regions, so that kaslr can get > the information abouth where can be selected or not. > If 'CONFIG_MEMORY_HOTREMOVE' not specified, go on the old code. >

Re: [PATCH 2/2] x86/mm/KASLR: Adjust the vmemmap size according to paging mode

On 08/29/18 at 03:05pm, Kirill A. Shutemov wrote: > On Wed, Aug 29, 2018 at 10:17:54AM +0800, Baoquan He wrote: > > Vmemmap area has different base and size depending on paging mode. > > Now we just hardcode its size as 1TB in memory KASLR, it's not > > right fo

Re: [PATCH 2/2] x86/mm/KASLR: Adjust the vmemmap size according to paging mode

On 08/29/18 at 03:26pm, Kirill A. Shutemov wrote: > On Wed, Aug 29, 2018 at 08:18:56PM +0800, Baoquan He wrote: > > On 08/29/18 at 03:05pm, Kirill A. Shutemov wrote: > > > On Wed, Aug 29, 2018 at 10:17:54AM +0800, Baoquan He wrote: > > > > Vmemmap area has dif

Re: [PATCH 2/2] x86/mm/KASLR: Adjust the vmemmap size according to paging mode

On 08/29/18 at 03:05pm, Kirill A. Shutemov wrote: > On Wed, Aug 29, 2018 at 10:17:54AM +0800, Baoquan He wrote: > > Vmemmap area has different base and size depending on paging mode. > > Now we just hardcode its size as 1TB in memory KASLR, it's not > > right fo

Re: Bug report about KASLR and ZONE_MOVABLE

On 07/16/18 at 05:24pm, Michal Hocko wrote: > On Mon 16-07-18 21:02:02, Baoquan He wrote: > > On 07/16/18 at 01:38pm, Michal Hocko wrote: > > > On Fri 13-07-18 07:52:40, Baoquan He wrote: > > > > Hi Michal, > > > > > > > > On 07/12/18 at 0

Re: [PATCH v4 1/4] x86/boot: Add acpitb.h to help parse acpi tables

Hi chao, On 07/23/18 at 05:29pm, Chao Fan wrote: > In order to parse ACPI tables, reuse the head file linux/acpi.h, > so that the files in 'compressed' directory can read ACPI table > by including this head file. > > Signed-off-by: Chao Fan > --- > arch/x86/boot/compressed/acpitb.h | 7 +++

Re: [PATCH v7 4/4] kexec_file: Load kernel at top of system RAM if required

On 07/23/18 at 04:34pm, Michal Hocko wrote: > On Thu 19-07-18 23:17:53, Baoquan He wrote: > > Kexec has been a formal feature in our distro, and customers owning > > those kind of very large machine can make use of this feature to speed > > up the reboot process. On uefi ma

Re: [PATCH v4 1/4] x86/boot: Add acpitb.h to help parse acpi tables

On 07/24/18 at 04:36pm, Chao Fan wrote: > On Tue, Jul 24, 2018 at 02:02:57PM +0800, Baoquan He wrote: > >Hi chao, > > > >On 07/23/18 at 05:29pm, Chao Fan wrote: > >> In order to parse ACPI tables, reuse the head file linux/acpi.h, > >> so that the files

Re: Bug report about KASLR and ZONE_MOVABLE

On 07/16/18 at 01:38pm, Michal Hocko wrote: > On Fri 13-07-18 07:52:40, Baoquan He wrote: > > Hi Michal, > > > > On 07/12/18 at 02:32pm, Michal Hocko wrote: > [...] > > > I am not able to find the beginning of the email thread right now. Could > > > you s

[PATCH] mm/page_alloc: Deprecate kernelcore=nn and movable_core=

We can still use 'kernelcore=mirror' or 'movable_node' for the usage of hotplug and movable zone. If somebody shows up with a valid usecase we can reconsider. Suggested-by: Michal Hocko Signed-off-by: Baoquan He --- Documentation/admin-guide/kernel-parameters.txt | 2 ++ mm/page_alloc.c

Re: [PATCH 2/2] x86/mm/KASLR: Adjust the vmemmap size according to paging mode

it was touchde by other people. Any comment about this? I can change accordingly. >From b19955ec5d439f7cb580331c83a27ad5753b06b6 Mon Sep 17 00:00:00 2001 From: Baoquan He Date: Thu, 30 Aug 2018 11:45:13 +0800 Subject: [PATCH] x86/mm/KASLR: Calculate the actual size of vmemmap region Vmemmap region

Re: [PATCH 2/2] x86/mm/KASLR: Adjust the vmemmap size according to paging mode

On 09/04/18 at 11:13am, Kirill A. Shutemov wrote: > On Mon, Sep 03, 2018 at 10:52:13PM +0800, Baoquan He wrote: > > On 09/03/18 at 01:26pm, Kirill A. Shutemov wrote: > > > > > But there's corner case when struct page is unreasonably large and > > > > >

[PATCH v2 3/3] mm: Add build time sanity chcek for struct page size

. Here 1/4 of PAGE_SIZE is chosen since system must have been insane with this value. For those systems with PAGE_SIZE larger than 4KB, 1KB is simply taken. Suggested-by: Kirill A. Shutemov Signed-off-by: Baoquan He --- mm/page_alloc.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/mm

[PATCH v2 1/3] x86/mm/KASLR: Fix the wrong calculation of kalsr region initial size

igger than 64TB. In fact, here MAX_PHYSMEM_BITS should be used instead. Fix it by replacing __PHYSICAL_MASK_SHIFT with MAX_PHYSMEM_BITS. Fixes: b83ce5ee9147 ("x86/mm/64: Make __PHYSICAL_MASK_SHIFT always 52") Signed-off-by: Baoquan He Acked-by: Kirill A. Shutemov Reviewed-by: Thomas Garni

[PATCH v2 2/3] x86/mm/KASLR: Calculate the actual size of vmemmap region

. So here calculate how many TB by the actual size of vmemmap region and align up to 1TB boundary. Signed-off-by: Baoquan He --- arch/x86/mm/kaslr.c | 11 ++- 1 file changed, 10 insertions(+), 1 deletion(-) diff --git a/arch/x86/mm/kaslr.c b/arch/x86/mm/kaslr.c index 0988971069c9

Re: [PATCH 0/3] x86/boot/KASLR: enhance randomness of kernel load addr when using GiB hugepage

Hi Pingfan, On 09/06/18 at 10:36am, Pingfan Liu wrote: > commit 747ff6265db4 ("x86/boot/KASLR: Skip specified number of 1GB huge > pages when doing physical randomization (KASLR)") and commit > 9b912485e0e7 ("x86/boot/KASLR: Add two new functions for 1GB huge pages > handling") prevent the

Re: [PATCH 1/2] x86/mm/KASLR: Fix the wrong calculation of kalsr region initial size

On 09/08/18 at 02:10pm, Thomas Gleixner wrote: > On Wed, 29 Aug 2018, Baoquan He wrote: > > > In memory KASLR, __PHYSICAL_MASK_SHIFT is taken to calculate the > > initial size of the direct mapping region. This is right in the > > old code where __PHYSICAL_MASK_SHIFT was e

Re: [PATCH 2/2] x86/mm/KASLR: Adjust the vmemmap size according to paging mode

On 09/05/18 at 03:09pm, Kirill A. Shutemov wrote: > On Wed, Sep 05, 2018 at 08:15:31AM +0000, Baoquan He wrote: > > On 09/04/18 at 11:13am, Kirill A. Shutemov wrote: > > > On Mon, Sep 03, 2018 at 10:52:13PM +0800, Baoquan He wrote: > > > > On 09/03/18 at 01:

Re: [PATCH v2 3/3] mm: Add build time sanity chcek for struct page size

On 09/10/18 at 09:41pm, kbuild test robot wrote: >include/linux/build_bug.h:69:2: note: in expansion of macro > 'BUILD_BUG_ON_MSG' > BUILD_BUG_ON_MSG(condition, "BUILD_BUG_ON failed: " #condition) > ^~~~ > >> mm/page_alloc.c:6852:2: note: in expansion of macro

Re: [PATCH v2 2/3] x86/mm/KASLR: Calculate the actual size of vmemmap region

On 09/11/18 at 09:59am, Ingo Molnar wrote: > > * Baoquan He wrote: > > > /* > > + * Memory regions randomized by KASLR (except modules that use a separate > > + * logic earlier during boot). Currently they are the physical memory > > + * mapping, vmalloc and v

Re: [PATCH v2 2/3] x86/mm/KASLR: Calculate the actual size of vmemmap region

On 09/10/18 at 08:11am, Ingo Molnar wrote: > > * Baoquan He wrote: > > > @@ -108,6 +109,14 @@ void __init kernel_randomize_memory(void) > > if (memory_tb < kaslr_regions[0].size_tb) > > kaslr_regions[0].size_tb = memory_tb; > > > &g

<    7   8   9   10   11   12   13   14   15   16   >