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

Hi Jiri, Thanks for providing these information. On 11/06/17 at 10:01am, Jiri Bohac wrote: > Hi Baoquan, > > [0.00] memblock_reserve: > [0xb800-0xbbff] gart_iommu_hole_init+0x396/0x4b6 > [0.00] AGP: Mapping aperture over RAM [mem >

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

Hi Jiri, Thanks for providing these information. On 11/06/17 at 10:01am, Jiri Bohac wrote: > Hi Baoquan, > > [0.00] memblock_reserve: > [0xb800-0xbbff] gart_iommu_hole_init+0x396/0x4b6 > [0.00] AGP: Mapping aperture over RAM [mem >

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

Hi Jiri, On 11/03/17 at 06:28pm, Jiri Bohac wrote: > On machines where the GART aperture is mapped over physical RAM > /proc/vmcore contains the remapped range and reading it may > cause hangs or reboots. This range needs to be excluded from /proc/vmcore. > > This has originally been implemented

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

Hi Jiri, On 11/03/17 at 06:28pm, Jiri Bohac wrote: > On machines where the GART aperture is mapped over physical RAM > /proc/vmcore contains the remapped range and reading it may > cause hangs or reboots. This range needs to be excluded from /proc/vmcore. > > This has originally been implemented

Re: [PATCH 3/3] kdump: round up the total memory size to 128M for crashkernel reservation

On 10/24/17 at 02:09pm, Dave Young wrote: > Hi Baoquan, > > On 10/24/17 at 01:57pm, Baoquan He wrote: > > Hi Dave, > > > > On 10/24/17 at 01:31pm, Dave Young wrote: > > > The total memory size we get in kernel is usually slightly less than 2G > &g

Re: [PATCH 3/3] kdump: round up the total memory size to 128M for crashkernel reservation

On 10/24/17 at 02:09pm, Dave Young wrote: > Hi Baoquan, > > On 10/24/17 at 01:57pm, Baoquan He wrote: > > Hi Dave, > > > > On 10/24/17 at 01:31pm, Dave Young wrote: > > > The total memory size we get in kernel is usually slightly less than 2G > &g

[tip:x86/mm] x86/mm/64: Rename the register_page_bootmem_memmap() 'size' parameter to 'nr_pages'

Commit-ID: 15670bfe19905b1dcbb63137f40d718b59d84479 Gitweb: https://git.kernel.org/tip/15670bfe19905b1dcbb63137f40d718b59d84479 Author: Baoquan He <b...@redhat.com> AuthorDate: Sat, 28 Oct 2017 09:30:38 +0800 Committer: Ingo Molnar <mi...@kernel.org> CommitDate: Mon, 30 Oct 2

[tip:x86/mm] x86/mm/64: Rename the register_page_bootmem_memmap() 'size' parameter to 'nr_pages'

Commit-ID: 15670bfe19905b1dcbb63137f40d718b59d84479 Gitweb: https://git.kernel.org/tip/15670bfe19905b1dcbb63137f40d718b59d84479 Author: Baoquan He AuthorDate: Sat, 28 Oct 2017 09:30:38 +0800 Committer: Ingo Molnar CommitDate: Mon, 30 Oct 2017 10:30:23 +0100 x86/mm/64: Rename

[PATCH] ACPICA: Clean up whitespace of indentation

Use tabs (not spaces) for indentation. Signed-off-by: Baoquan He <b...@redhat.com> --- include/acpi/actbl1.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/include/acpi/actbl1.h b/include/acpi/actbl1.h index 6b8714a428b6..d8a4fc066abe 100644 --- a/include/acpi/ac

[PATCH] ACPICA: Clean up whitespace of indentation

Use tabs (not spaces) for indentation. Signed-off-by: Baoquan He --- include/acpi/actbl1.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/include/acpi/actbl1.h b/include/acpi/actbl1.h index 6b8714a428b6..d8a4fc066abe 100644 --- a/include/acpi/actbl1.h +++ b/include/acpi

[PATCH v3] x86/mm/64: Rename the register_page_bootmem_memmap() 'size' parameter to 'nr_pages'

function parameter 'nr_pages'. And also clean up the extra parentheses in which get_order() is called. Signed-off-by: Baoquan He <b...@redhat.com> Cc: Linus Torvalds <torva...@linux-foundation.org> Cc: Peter Zijlstra <pet...@infradead.org> Cc: Thomas Gleixner <t...@linutron

[PATCH v3] x86/mm/64: Rename the register_page_bootmem_memmap() 'size' parameter to 'nr_pages'

function parameter 'nr_pages'. And also clean up the extra parentheses in which get_order() is called. Signed-off-by: Baoquan He Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: a...@linux-foundation.org Link: http://lkml.kernel.org/r/1508849249-18035-1-git-send-email-...@redhat.com

Re: [PATCH] x86/mm/64: Rename the register_page_bootmem_memmap() 'size' parameter to 'nr_pages'

Hi, On 10/27/17 at 11:51pm, kbuild test robot wrote: > Hi Ingo, > > Thank you for the patch! Yet we hit a small issue. > [auto build test ERROR on tip/x86/core] > [also build test ERROR on v4.14-rc6 next-20171018] > [if your patch is applied to the wrong git tree, please drop us a note to >

Re: [PATCH] x86/mm/64: Rename the register_page_bootmem_memmap() 'size' parameter to 'nr_pages'

Hi, On 10/27/17 at 11:51pm, kbuild test robot wrote: > Hi Ingo, > > Thank you for the patch! Yet we hit a small issue. > [auto build test ERROR on tip/x86/core] > [also build test ERROR on v4.14-rc6 next-20171018] > [if your patch is applied to the wrong git tree, please drop us a note to >

Re: [PATCH] x86/mm/64: Rename the argument 'size' as 'nr_pages' in register_page_bootmem_memmap

; > url: > https://github.com/0day-ci/linux/commits/Baoquan-He/x86-mm-64-Rename-the-argument-size-as-nr_pages-in-register_page_bootmem_memmap/20171026-125956 > config: x86_64-allyesconfig (attached as .config) > compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901 > reproduce: > # s

Re: [PATCH] x86/mm/64: Rename the argument 'size' as 'nr_pages' in register_page_bootmem_memmap

; > url: > https://github.com/0day-ci/linux/commits/Baoquan-He/x86-mm-64-Rename-the-argument-size-as-nr_pages-in-register_page_bootmem_memmap/20171026-125956 > config: x86_64-allyesconfig (attached as .config) > compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901 > reproduce: > # s

Re: [PATCH v2] x86/mm/64: Rename the register_page_bootmem_memmap() 'size' parameter to 'nr_pages'

On 10/26/17 at 08:25am, Ingo Molnar wrote: > > * Baoquan He <b...@redhat.com> wrote: > > > register_page_bootmem_memmap()'s 3rd 'size' parameter is named > > in a somewhat misleading fashion - rename it to 'nr_pages' which > > makes the units of it much

Re: [PATCH v2] x86/mm/64: Rename the register_page_bootmem_memmap() 'size' parameter to 'nr_pages'

On 10/26/17 at 08:25am, Ingo Molnar wrote: > > * Baoquan He wrote: > > > register_page_bootmem_memmap()'s 3rd 'size' parameter is named > > in a somewhat misleading fashion - rename it to 'nr_pages' which > > makes the units of it much clearer. > > >

[PATCH v2] x86/mm/64: Rename the register_page_bootmem_memmap() 'size' parameter to 'nr_pages'

variables are different type though both represent number of pages. Take 'nr_pages' as register_page_bootmem_memmap()'s parameter name since it has more specific meaning, can make better function interface. Signed-off-by: Baoquan He <b...@redhat.com> Cc: Linus Torvalds <torva...@linux-foundatio

[PATCH v2] x86/mm/64: Rename the register_page_bootmem_memmap() 'size' parameter to 'nr_pages'

variables are different type though both represent number of pages. Take 'nr_pages' as register_page_bootmem_memmap()'s parameter name since it has more specific meaning, can make better function interface. Signed-off-by: Baoquan He Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Thomas Gleixner Cc

Re: [PATCH] x86/mm/64: Rename the argument 'size' as 'nr_pages' in register_page_bootmem_memmap

for a v2 submission? Thanks a lot for checking this and rewrote the change log. Seems I didn't merge the change in mm.h. Will make v2 with your patch log changes and repost after testing. Thanks Baoquan > > > ==> > From 67780ebe5c99190d2a946de106bd0c7b83e11b68

Re: [PATCH] x86/mm/64: Rename the argument 'size' as 'nr_pages' in register_page_bootmem_memmap

for a v2 submission? Thanks a lot for checking this and rewrote the change log. Seems I didn't merge the change in mm.h. Will make v2 with your patch log changes and repost after testing. Thanks Baoquan > > > ==> > From 67780ebe5c99190d2a946de106bd0c7b83e11b

[PATCH] x86/mm/64: Rename the argument 'size' as 'nr_pages' in register_page_bootmem_memmap

For register_page_bootmem_memmap(), the 3rd argument 'size' indicates the number of pages which are inside the memory section, not a size. Signed-off-by: Baoquan He <b...@redhat.com> --- arch/x86/mm/init_64.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/

[PATCH] x86/mm/64: Rename the argument 'size' as 'nr_pages' in register_page_bootmem_memmap

For register_page_bootmem_memmap(), the 3rd argument 'size' indicates the number of pages which are inside the memory section, not a size. Signed-off-by: Baoquan He --- arch/x86/mm/init_64.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/x86/mm/init_64.c b/arch/x86

Re: [PATCH 1/3] kdump: extend crashkernel=range:size to dynamically increase reservation size

On 10/24/17 at 01:31pm, Dave Young wrote: > 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

Re: [PATCH 1/3] kdump: extend crashkernel=range:size to dynamically increase reservation size

On 10/24/17 at 01:31pm, Dave Young wrote: > 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

Re: [PATCH 3/3] kdump: round up the total memory size to 128M for crashkernel reservation

Hi Dave, On 10/24/17 at 01:31pm, Dave Young wrote: > 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

Re: [PATCH 3/3] kdump: round up the total memory size to 128M for crashkernel reservation

Hi Dave, On 10/24/17 at 01:31pm, Dave Young wrote: > 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

[PATCH] printk: fix typo in printk_safe.c

Signed-off-by: Baoquan He <b...@redhat.com> --- kernel/printk/printk_safe.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kernel/printk/printk_safe.c b/kernel/printk/printk_safe.c index 3cdaeaef9ce1..89558b85f45c 100644 --- a/kernel/printk/printk_safe.c +++ b/kernel/

[PATCH] printk: fix typo in printk_safe.c

Signed-off-by: Baoquan He --- kernel/printk/printk_safe.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kernel/printk/printk_safe.c b/kernel/printk/printk_safe.c index 3cdaeaef9ce1..89558b85f45c 100644 --- a/kernel/printk/printk_safe.c +++ b/kernel/printk/printk_safe.c

Re: [PATCH 1/2] fs, elf: drop MAP_FIXED usage from elf_map

On 10/17/17 at 03:33pm, Michal Hocko wrote: > On Tue 17-10-17 21:22:46, Baoquan He wrote: > [...] > > And as I said before, then we will still have the > > ungraceful 'mapping total'|'unmapping the rest' method. > > yes I haven't touched this part and I guess you are right

Re: [PATCH 1/2] fs, elf: drop MAP_FIXED usage from elf_map

On 10/17/17 at 03:33pm, Michal Hocko wrote: > On Tue 17-10-17 21:22:46, Baoquan He wrote: > [...] > > And as I said before, then we will still have the > > ungraceful 'mapping total'|'unmapping the rest' method. > > yes I haven't touched this part and I guess you are right

Re: [PATCH 1/2] fs, elf: drop MAP_FIXED usage from elf_map

On 10/17/17 at 02:56pm, Michal Hocko wrote: > On Tue 17-10-17 20:26:14, Baoquan He wrote: > > Hi Michal, > > > > Earlier I posted a patchset to clean up these in a different way, but > > patches sent to your below mail address are all rejected. > > > >

Re: [PATCH 1/2] fs, elf: drop MAP_FIXED usage from elf_map

On 10/17/17 at 02:56pm, Michal Hocko wrote: > On Tue 17-10-17 20:26:14, Baoquan He wrote: > > Hi Michal, > > > > Earlier I posted a patchset to clean up these in a different way, but > > patches sent to your below mail address are all rejected. > > > > : h

Re: [PATCH 1/2] fs, elf: drop MAP_FIXED usage from elf_map

Hi Michal, Earlier I posted a patchset to clean up these in a different way, but patches sent to your below mail address are all rejected. : host mail.kerne.org[104.131.33.237] said: 454 4.1.1 : Recipient address rejected: User unknown in virtual

Re: [PATCH 1/2] fs, elf: drop MAP_FIXED usage from elf_map

Hi Michal, Earlier I posted a patchset to clean up these in a different way, but patches sent to your below mail address are all rejected. : host mail.kerne.org[104.131.33.237] said: 454 4.1.1 : Recipient address rejected: User unknown in virtual mailbox table (in reply to RCPT TO

Re: [POC] Extend "movable_node" to "movable_node=nn@ss" and add the interface in /sys to show the value

Hi dear Fan San, On 10/11/17 at 04:23pm, Chao Fan wrote: > On Wed, Oct 11, 2017 at 03:55:13PM +0800, Baoquan He wrote: > >Hi Fan San, > >> 1. Get and parse the srat table before kernel extracted, then mark the > >> memory > >>region in movable node which s

Re: [POC] Extend "movable_node" to "movable_node=nn@ss" and add the interface in /sys to show the value

Hi dear Fan San, On 10/11/17 at 04:23pm, Chao Fan wrote: > On Wed, Oct 11, 2017 at 03:55:13PM +0800, Baoquan He wrote: > >Hi Fan San, > >> 1. Get and parse the srat table before kernel extracted, then mark the > >> memory > >>region in movable node which s

Re: [POC] Extend "movable_node" to "movable_node=nn@ss" and add the interface in /sys to show the value

Hi Fan San, On 10/11/17 at 10:28am, Chao Fan wrote: > Hi all, > > Here is a problem: > Here is a machine with several NUMA nodes and some of them are hot-pluggable, > It's not good for kernel to be extracted in the memory region of movable node. > But in current code, I print the address choosen

Re: [POC] Extend "movable_node" to "movable_node=nn@ss" and add the interface in /sys to show the value

Hi Fan San, On 10/11/17 at 10:28am, Chao Fan wrote: > Hi all, > > Here is a problem: > Here is a machine with several NUMA nodes and some of them are hot-pluggable, > It's not good for kernel to be extracted in the memory region of movable node. > But in current code, I print the address choosen

[PATCH 3/3] binfmt_elf: Search an unmapped area with total_size but not map the whole image

-by: Baoquan He <b...@redhat.com> --- fs/binfmt_elf.c | 25 ++--- 1 file changed, 14 insertions(+), 11 deletions(-) diff --git a/fs/binfmt_elf.c b/fs/binfmt_elf.c index d7a8a53a6f18..bebb9f2c934e 100644 --- a/fs/binfmt_elf.c +++ b/fs/binfmt_elf.c @@ -357,20 +357,23 @@ static un

[PATCH 2/3] binfmt_elf: Get the total_size only for dynamic loader in load_elf_binary()

n the stack and mm->mmap_base. Whether it's harmless or not, we should not allow program to map above mm->mmap_base. So here change to get the total_size only for dynamic loader in load_elf_binary(). Signed-off-by: Baoquan He <b...@redhat.com> --- fs/binfmt_elf.c | 17 +---

[PATCH 3/3] binfmt_elf: Search an unmapped area with total_size but not map the whole image

-by: Baoquan He --- fs/binfmt_elf.c | 25 ++--- 1 file changed, 14 insertions(+), 11 deletions(-) diff --git a/fs/binfmt_elf.c b/fs/binfmt_elf.c index d7a8a53a6f18..bebb9f2c934e 100644 --- a/fs/binfmt_elf.c +++ b/fs/binfmt_elf.c @@ -357,20 +357,23 @@ static unsigned long elf_map

[PATCH 2/3] binfmt_elf: Get the total_size only for dynamic loader in load_elf_binary()

n the stack and mm->mmap_base. Whether it's harmless or not, we should not allow program to map above mm->mmap_base. So here change to get the total_size only for dynamic loader in load_elf_binary(). Signed-off-by: Baoquan He --- fs/binfmt_elf.c | 17 + 1 file changed, 9 i

[PATCH 0/3] binfmt_elf: Clean up codes related to total_size passed into elf_map()

. And in elf_map(), Oleg pointed out that the mmap(total_size) + munmap(extra_size) way looks very ugly. We can search the unmapped area of total_size big, then only map the 1st PT_LOAD segment with the searched address. In this patchset, clean up them all. Baoquan He (3): binfmt_elf: Clean up

[PATCH 1/3] binfmt_elf: Clean up the variable name of map flags

-by: Baoquan He <b...@redhat.com> --- fs/binfmt_elf.c | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/fs/binfmt_elf.c b/fs/binfmt_elf.c index 73b01e474fdc..72b7ecba7ead 100644 --- a/fs/binfmt_elf.c +++ b/fs/binfmt_elf.c @@ -342,7 +342,7 @@ create_elf_tables(

[PATCH 0/3] binfmt_elf: Clean up codes related to total_size passed into elf_map()

. And in elf_map(), Oleg pointed out that the mmap(total_size) + munmap(extra_size) way looks very ugly. We can search the unmapped area of total_size big, then only map the 1st PT_LOAD segment with the searched address. In this patchset, clean up them all. Baoquan He (3): binfmt_elf: Clean up

[PATCH 1/3] binfmt_elf: Clean up the variable name of map flags

-by: Baoquan He --- fs/binfmt_elf.c | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/fs/binfmt_elf.c b/fs/binfmt_elf.c index 73b01e474fdc..72b7ecba7ead 100644 --- a/fs/binfmt_elf.c +++ b/fs/binfmt_elf.c @@ -342,7 +342,7 @@ create_elf_tables(struct linux_binprm *bprm

Re: MAP_FIXED for ELF mappings

On 10/04/17 at 05:17pm, Michal Hocko wrote: > On Wed 04-10-17 23:12:38, Baoquan He wrote: > > I made a clean up patch according to Oleg's suggestion. It's trying to > > get an map area to cover total_size, then do mmap for for the 1st > > program segment only. Not sure i

Re: MAP_FIXED for ELF mappings

On 10/04/17 at 05:17pm, Michal Hocko wrote: > On Wed 04-10-17 23:12:38, Baoquan He wrote: > > I made a clean up patch according to Oleg's suggestion. It's trying to > > get an map area to cover total_size, then do mmap for for the 1st > > program segment only. Not sure i

Re: MAP_FIXED for ELF mappings

I made a clean up patch according to Oleg's suggestion. It's trying to get an map area to cover total_size, then do mmap for for the 1st program segment only. Not sure if this way is correct. >From 40f231bb78a74caebcb4a898089a9fa5323be05f Mon Sep 17 00:00:00 2001 From: Baoquan He <b...@redh

Re: MAP_FIXED for ELF mappings

I made a clean up patch according to Oleg's suggestion. It's trying to get an map area to cover total_size, then do mmap for for the 1st program segment only. Not sure if this way is correct. >From 40f231bb78a74caebcb4a898089a9fa5323be05f Mon Sep 17 00:00:00 2001 From: Baoquan He Date: Fri,

Re: MAP_FIXED for ELF mappings

On 10/04/17 at 09:50am, Michal Hocko wrote: > Hi, > while studying CVE-2017-1000253 and the MAP_FIXED usage in load_elf* > code paths I have stumbled over MAP_FIXED usage for elf segments > mapping. I am not really familiar with this area much so I might draw > completely incorrect conclusions

Re: MAP_FIXED for ELF mappings

On 10/04/17 at 09:50am, Michal Hocko wrote: > Hi, > while studying CVE-2017-1000253 and the MAP_FIXED usage in load_elf* > code paths I have stumbled over MAP_FIXED usage for elf segments > mapping. I am not really familiar with this area much so I might draw > completely incorrect conclusions

Re: [PATCH v2 RESEND 2/2] x86/mm/KASLR: Do not adapt the size of the direct mapping section for SGI UV system

Hi Mike, On 09/28/17 at 07:10am, Mike Travis wrote: > > > On 9/28/2017 2:01 AM, Ingo Molnar wrote: > > > > > If on SGI UV system, the kaslr_regions[0].size_tb, namely the size of > > > the direct mapping section, is incorrect. > > > > > > Its direct mapping size includes two parts: > > > #1

Re: [PATCH v2 RESEND 2/2] x86/mm/KASLR: Do not adapt the size of the direct mapping section for SGI UV system

Hi Mike, On 09/28/17 at 07:10am, Mike Travis wrote: > > > On 9/28/2017 2:01 AM, Ingo Molnar wrote: > > > > > If on SGI UV system, the kaslr_regions[0].size_tb, namely the size of > > > the direct mapping section, is incorrect. > > > > > > Its direct mapping size includes two parts: > > > #1

Re: [PATCH v2 RESEND 2/2] x86/mm/KASLR: Do not adapt the size of the direct mapping section for SGI UV system

Hi Ingo, On 09/28/17 at 09:56am, Ingo Molnar wrote: > > diff --git a/arch/x86/mm/kaslr.c b/arch/x86/mm/kaslr.c > > index af599167fe3c..4d68c08df82d 100644 > > --- a/arch/x86/mm/kaslr.c > > +++ b/arch/x86/mm/kaslr.c > > @@ -27,6 +27,7 @@ > > #include > > #include > > #include > > +#include

Re: [PATCH v2 RESEND 2/2] x86/mm/KASLR: Do not adapt the size of the direct mapping section for SGI UV system

Hi Ingo, On 09/28/17 at 09:56am, Ingo Molnar wrote: > > diff --git a/arch/x86/mm/kaslr.c b/arch/x86/mm/kaslr.c > > index af599167fe3c..4d68c08df82d 100644 > > --- a/arch/x86/mm/kaslr.c > > +++ b/arch/x86/mm/kaslr.c > > @@ -27,6 +27,7 @@ > > #include > > #include > > #include > > +#include

Re: [PATCH v2 RESEND 1/2] x86/UV: Introduce a helper function to check UV system at earlier stage

On 09/14/17 at 03:49pm, Dave Young wrote: > > > diff --git a/arch/x86/include/asm/uv/uv.h b/arch/x86/include/asm/uv/uv.h > > > index b5a32231abd8..93d7ad8763ba 100644 > > > --- a/arch/x86/include/asm/uv/uv.h > > > +++ b/arch/x86/include/asm/uv/uv.h > > > @@ -18,6 +18,11 @@ extern void

Re: [PATCH v2 RESEND 1/2] x86/UV: Introduce a helper function to check UV system at earlier stage

On 09/14/17 at 03:49pm, Dave Young wrote: > > > diff --git a/arch/x86/include/asm/uv/uv.h b/arch/x86/include/asm/uv/uv.h > > > index b5a32231abd8..93d7ad8763ba 100644 > > > --- a/arch/x86/include/asm/uv/uv.h > > > +++ b/arch/x86/include/asm/uv/uv.h > > > @@ -18,6 +18,11 @@ extern void

Re: [PATCH v2 RESEND 1/2] x86/UV: Introduce a helper function to check UV system at earlier stage

Add Dave to the CC list, he may have concerns about the code change. On 09/07/17 at 03:42pm, Baoquan He wrote: > The BIOS on SGI UV system will report a UV system table which describes > specific firmware capabilities available to the Linux kernel at runtime. > This UV system table on

Re: [PATCH v2 RESEND 1/2] x86/UV: Introduce a helper function to check UV system at earlier stage

Add Dave to the CC list, he may have concerns about the code change. On 09/07/17 at 03:42pm, Baoquan He wrote: > The BIOS on SGI UV system will report a UV system table which describes > specific firmware capabilities available to the Linux kernel at runtime. > This UV system table on

Re: [PATCH v2 RESEND 0/2] x86/mm/KASLR: Do not adapt the size of the direct mapping section for SGI UV system

Hi all, PING! Do anyone has any suggestion about this issue? This bug blocks SGI system's boot, KASLR has to be disabled on SGI system if they want to run tests. Thanks Baoquan On 09/07/17 at 03:42pm, Baoquan He wrote: > This is v2 post RESEND. Add Mike's Acked-by to patch 2/2 as he sugges

Re: [PATCH v2 RESEND 0/2] x86/mm/KASLR: Do not adapt the size of the direct mapping section for SGI UV system

Hi all, PING! Do anyone has any suggestion about this issue? This bug blocks SGI system's boot, KASLR has to be disabled on SGI system if they want to run tests. Thanks Baoquan On 09/07/17 at 03:42pm, Baoquan He wrote: > This is v2 post RESEND. Add Mike's Acked-by to patch 2/2 as he sugges

Re: [PATCH v8 01/13] x86/apic: Construct a selector for the interrupt delivery mode

Hi dou, On 09/12/17 at 09:20am, Dou Liyang wrote: > I thought again and again, I would not change this check logic. > > Because actually, we have three possibilities: > > 1. ACPI on chip > 2. 82489DX > 3. no APIC > > lapic_is_integrated() is used to check the APIC's type which is > APIC

Re: [PATCH v8 01/13] x86/apic: Construct a selector for the interrupt delivery mode

Hi dou, On 09/12/17 at 09:20am, Dou Liyang wrote: > I thought again and again, I would not change this check logic. > > Because actually, we have three possibilities: > > 1. ACPI on chip > 2. 82489DX > 3. no APIC > > lapic_is_integrated() is used to check the APIC's type which is > APIC

Re: [PATCH v8 01/13] x86/apic: Construct a selector for the interrupt delivery mode

Hi dou, I tested your patchset, the result is positive. Kdump kernel functions well. About the sanity check in patch 1/13, I still have concerns. On 09/12/17 at 09:20am, Dou Liyang wrote: > Hi Baoquan, > > At 09/07/2017 01:22 PM, Baoquan He wrote: > > On 09/07/17 at 12:19pm, D

Re: [PATCH v8 01/13] x86/apic: Construct a selector for the interrupt delivery mode

Hi dou, I tested your patchset, the result is positive. Kdump kernel functions well. About the sanity check in patch 1/13, I still have concerns. On 09/12/17 at 09:20am, Dou Liyang wrote: > Hi Baoquan, > > At 09/07/2017 01:22 PM, Baoquan He wrote: > > On 09/07/17 at 12:19pm, D

[PATCH v2 RESEND 2/2] x86/mm/KASLR: Do not adapt the size of the direct mapping section for SGI UV system

() in kernel_randomize_memory(). If yes, do not adapt the size of the direct mapping section, just keep it as 64TB. Signed-off-by: Baoquan He <b...@redhat.com> Reviewed-by: Thomas Garnier <thgar...@google.com> Acked-by: Mike Travis <tra...@sgi.com> Cc: Ingo Molnar <mi...@redh

[PATCH v2 RESEND 0/2] x86/mm/KASLR: Do not adapt the size of the direct mapping section for SGI UV system

2. Split the v1 code into uv part and mm KASLR part as Mike suggested. Baoquan He (2): x86/UV: Introduce a helper function to check UV system at earlier stage x86/mm/KASLR: Do not adapt the size of the direct mapping section for SGI UV system arch/x86/include/asm/uv/uv.h | 6 ++ arch/

[PATCH v2 RESEND 2/2] x86/mm/KASLR: Do not adapt the size of the direct mapping section for SGI UV system

() in kernel_randomize_memory(). If yes, do not adapt the size of the direct mapping section, just keep it as 64TB. Signed-off-by: Baoquan He Reviewed-by: Thomas Garnier Acked-by: Mike Travis Cc: Ingo Molnar Cc: "H. Peter Anvin" Cc: x...@kernel.org Cc: Thomas Garnier Cc: Kees Cook

[PATCH v2 RESEND 0/2] x86/mm/KASLR: Do not adapt the size of the direct mapping section for SGI UV system

2. Split the v1 code into uv part and mm KASLR part as Mike suggested. Baoquan He (2): x86/UV: Introduce a helper function to check UV system at earlier stage x86/mm/KASLR: Do not adapt the size of the direct mapping section for SGI UV system arch/x86/include/asm/uv/uv.h | 6 ++ arch/

[PATCH v2 RESEND 1/2] x86/UV: Introduce a helper function to check UV system at earlier stage

is_early_uv_system() to identify if a system is UV system. Later we will use it to check if the running system is UV system in mm KASLR code. Signed-off-by: Baoquan He <b...@redhat.com> Acked-by: Mike Travis <tra...@sgi.com> --- arch/x86/include/asm/uv/uv.h | 6 ++ 1 file changed,

[PATCH v2 RESEND 1/2] x86/UV: Introduce a helper function to check UV system at earlier stage

is_early_uv_system() to identify if a system is UV system. Later we will use it to check if the running system is UV system in mm KASLR code. Signed-off-by: Baoquan He Acked-by: Mike Travis --- arch/x86/include/asm/uv/uv.h | 6 ++ 1 file changed, 6 insertions(+) diff --git a/arch/x86/include

Re: [PATCH v8 01/13] x86/apic: Construct a selector for the interrupt delivery mode

BIOS bug. > > [1] Commit 8312136fa8b0("x86, apic: Fix missed handling of discrete apics") Hmm, sounds reasonable. Just a sentence to describe it could be better. > > At 09/06/2017 06:17 PM, Baoquan He wrote: > > Hi Dou, > > > > On 08/28/17 at 11:2

Re: [PATCH v8 01/13] x86/apic: Construct a selector for the interrupt delivery mode

BIOS bug. > > [1] Commit 8312136fa8b0("x86, apic: Fix missed handling of discrete apics") Hmm, sounds reasonable. Just a sentence to describe it could be better. > > At 09/06/2017 06:17 PM, Baoquan He wrote: > > Hi Dou, > > > > On 08/28/17 at 11:2

Re: [PATCH v8 06/13] x86/apic: Mark the apic_intr_mode extern for sanity check cleanup

On 09/07/17 at 10:27am, Dou Liyang wrote: > > > At 09/06/2017 04:03 PM, Baoquan He wrote: > > On 09/06/17 at 01:41pm, Dou Liyang wrote: > > > Hi Baoquan, > > > > > > At 09/06/2017 01:26 PM, Baoquan He wrote: > > > [...] > > > diff -

Re: [PATCH v8 06/13] x86/apic: Mark the apic_intr_mode extern for sanity check cleanup

On 09/07/17 at 10:27am, Dou Liyang wrote: > > > At 09/06/2017 04:03 PM, Baoquan He wrote: > > On 09/06/17 at 01:41pm, Dou Liyang wrote: > > > Hi Baoquan, > > > > > > At 09/06/2017 01:26 PM, Baoquan He wrote: > > > [...] > > > diff -

Re: [PATCH v8 01/13] x86/apic: Construct a selector for the interrupt delivery mode

Hi Dou, On 08/28/17 at 11:20am, Dou Liyang wrote: > +static int __init apic_intr_mode_select(void) > +{ > + /* Check kernel option */ > + if (disable_apic) { > + pr_info("APIC disabled via kernel command line\n"); > + return APIC_PIC; > + } > + I am not very

Re: [PATCH v8 01/13] x86/apic: Construct a selector for the interrupt delivery mode

Hi Dou, On 08/28/17 at 11:20am, Dou Liyang wrote: > +static int __init apic_intr_mode_select(void) > +{ > + /* Check kernel option */ > + if (disable_apic) { > + pr_info("APIC disabled via kernel command line\n"); > + return APIC_PIC; > + } > + I am not very

Re: [PATCH v8 01/13] x86/apic: Construct a selector for the interrupt delivery mode

On 09/06/17 at 12:18pm, Dou Liyang wrote: > > > +static int __init apic_intr_mode_select(void) > > > +{ > > > + /* Check kernel option */ > > > + if (disable_apic) { > > > + pr_info("APIC disabled via kernel command line\n"); > > > + return APIC_PIC; > > > + } > > > + > > > + /*

Re: [PATCH v8 01/13] x86/apic: Construct a selector for the interrupt delivery mode

On 09/06/17 at 12:18pm, Dou Liyang wrote: > > > +static int __init apic_intr_mode_select(void) > > > +{ > > > + /* Check kernel option */ > > > + if (disable_apic) { > > > + pr_info("APIC disabled via kernel command line\n"); > > > + return APIC_PIC; > > > + } > > > + > > > + /*

Re: [PATCH v8 06/13] x86/apic: Mark the apic_intr_mode extern for sanity check cleanup

On 09/06/17 at 01:41pm, Dou Liyang wrote: > Hi Baoquan, > > At 09/06/2017 01:26 PM, Baoquan He wrote: > [...] > diff --git a/arch/x86/kernel/smpboot.c b/arch/x86/kernel/smpboot.c > index 4f63afc..9f8479c 100644 > --- a/arch/x86/kernel/smpboot.c > +++ b/arch/x86/kerne

Re: [PATCH v8 06/13] x86/apic: Mark the apic_intr_mode extern for sanity check cleanup

On 09/06/17 at 01:41pm, Dou Liyang wrote: > Hi Baoquan, > > At 09/06/2017 01:26 PM, Baoquan He wrote: > [...] > diff --git a/arch/x86/kernel/smpboot.c b/arch/x86/kernel/smpboot.c > index 4f63afc..9f8479c 100644 > --- a/arch/x86/kernel/smpboot.c > +++ b/arch/x86/kerne

Re: [PATCH v8 06/13] x86/apic: Mark the apic_intr_mode extern for sanity check cleanup

On 09/06/17 at 12:25pm, Baoquan He wrote: > On 08/28/17 at 11:20am, Dou Liyang wrote: > > - /* > > * Should not be necessary because the MP table should list the boot > > * CPU too, but we do it for the sake of robustness anyway. > > */ > > @@ -125

Re: [PATCH v8 06/13] x86/apic: Mark the apic_intr_mode extern for sanity check cleanup

On 09/06/17 at 12:25pm, Baoquan He wrote: > On 08/28/17 at 11:20am, Dou Liyang wrote: > > - /* > > * Should not be necessary because the MP table should list the boot > > * CPU too, but we do it for the sake of robustness anyway. > > */ > > @@ -125

Re: [PATCH v8 06/13] x86/apic: Mark the apic_intr_mode extern for sanity check cleanup

On 08/28/17 at 11:20am, Dou Liyang wrote: > Calling native_smp_prepare_cpus() to prepare for SMP bootup, does > some sanity checking, enables APIC mode and disables SMP feature. > > Now, APIC mode setup has been unified to apic_intr_mode_init(), > some sanity checks are redundant and need to be

Re: [PATCH v8 06/13] x86/apic: Mark the apic_intr_mode extern for sanity check cleanup

On 08/28/17 at 11:20am, Dou Liyang wrote: > Calling native_smp_prepare_cpus() to prepare for SMP bootup, does > some sanity checking, enables APIC mode and disables SMP feature. > > Now, APIC mode setup has been unified to apic_intr_mode_init(), > some sanity checks are redundant and need to be

Re: [PATCH v8 01/13] x86/apic: Construct a selector for the interrupt delivery mode

Hi Liyang, On 08/28/17 at 11:20am, Dou Liyang wrote: > Now, there are many switches in kernel which are used to determine > the final interrupt delivery mode, as shown below: > > 1) kconfig: >CONFIG_X86_64; CONFIG_X86_LOCAL_APIC; CONFIG_x86_IO_APIC > 2) kernel option: disable_apic;

Re: [PATCH v8 01/13] x86/apic: Construct a selector for the interrupt delivery mode

Hi Liyang, On 08/28/17 at 11:20am, Dou Liyang wrote: > Now, there are many switches in kernel which are used to determine > the final interrupt delivery mode, as shown below: > > 1) kconfig: >CONFIG_X86_64; CONFIG_X86_LOCAL_APIC; CONFIG_x86_IO_APIC > 2) kernel option: disable_apic;

Re: [PATCH v2] kaslr: get ACPI SRAT table to avoid movable memory

On 09/04/17 at 04:17pm, Dou Liyang wrote: > With "movable_node=1024M" option in cmdline, KASLR will can't access > the node3 memory. So you have extended the movable_node option from no value specified to adding a limit value, then why don't you go one step further to extend it as

Re: [PATCH v2] kaslr: get ACPI SRAT table to avoid movable memory

On 09/04/17 at 04:17pm, Dou Liyang wrote: > With "movable_node=1024M" option in cmdline, KASLR will can't access > the node3 memory. So you have extended the movable_node option from no value specified to adding a limit value, then why don't you go one step further to extend it as

Re: [PATCH v2] kaslr: get ACPI SRAT table to avoid movable memory

On 09/04/17 at 12:55am, Rafael J. Wysocki wrote: > On Sunday, September 3, 2017 4:31:23 PM CEST Chao Fan wrote: > > KASLR should choose the memory region of immovable node to extract kernel. > > So get ACPI SRAT table and store the memory region of movable node which > > kaslr shold avoid. > >

Re: [PATCH v2] kaslr: get ACPI SRAT table to avoid movable memory

On 09/04/17 at 12:55am, Rafael J. Wysocki wrote: > On Sunday, September 3, 2017 4:31:23 PM CEST Chao Fan wrote: > > KASLR should choose the memory region of immovable node to extract kernel. > > So get ACPI SRAT table and store the memory region of movable node which > > kaslr shold avoid. > >

Re: [PATCH v2 2/2] x86/mm/KASLR: Do not adapt size of the direct mapping section for SGI UV system

, SGI UV system will panic during boot with very high possibility. On 05/20/17 at 08:02pm, Baoquan He wrote: > On SGI UV system, kernel casually hang with kaslr enabled. > > The back trace is: > > kernel BUG at arch/x86/mm/init_64.c:311! > invalid opcode: [#1] SMP &

Re: [PATCH v2 2/2] x86/mm/KASLR: Do not adapt size of the direct mapping section for SGI UV system

, SGI UV system will panic during boot with very high possibility. On 05/20/17 at 08:02pm, Baoquan He wrote: > On SGI UV system, kernel casually hang with kaslr enabled. > > The back trace is: > > kernel BUG at arch/x86/mm/init_64.c:311! > invalid opcode: [#1] SMP &

Re: [PATCH v5] x86/boot/KASLR: exclude EFI_BOOT_SERVICES_* and EFI_LOADER_* from KASLR's choice

ess only from EFI_CONVENTIONAL_MEMORY which is the > only memory type we know to be free. > > Signed-off-by: Naoya Horiguchi <n-horigu...@ah.jp.nec.com> Thanks, looks good to me. Ack it. Acked-by: Baoquan He <b...@redhat.com> > --- > v4 -> v5: > - addressed why EFI_LOA

Re: [PATCH v5] x86/boot/KASLR: exclude EFI_BOOT_SERVICES_* and EFI_LOADER_* from KASLR's choice

hich is the > only memory type we know to be free. > > Signed-off-by: Naoya Horiguchi Thanks, looks good to me. Ack it. Acked-by: Baoquan He > --- > v4 -> v5: > - addressed why EFI_LOADER_* is excluded. > - changed patch subject. > > v3 -> v4: > - upda

Re: [PATCH v4] x86/boot/KASLR: exclude EFI_BOOT_SERVICES_{CODE|DATA} from KASLR's choice

Hi Naoya, Thanks for this fix. I saw NEC had reported a bug to rhel previously, and the bug truly will corrupt OS, it can be fixed by this patch. This patch looks good to me, just a small concern, please see below inline comment. On 08/24/17 at 07:33pm, Naoya Horiguchi wrote: > KASLR chooses

Re: [PATCH v4] x86/boot/KASLR: exclude EFI_BOOT_SERVICES_{CODE|DATA} from KASLR's choice

Hi Naoya, Thanks for this fix. I saw NEC had reported a bug to rhel previously, and the bug truly will corrupt OS, it can be fixed by this patch. This patch looks good to me, just a small concern, please see below inline comment. On 08/24/17 at 07:33pm, Naoya Horiguchi wrote: > KASLR chooses

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