/boot/compressed/kaslr.c
> b/arch/x86/boot/compressed/kaslr.c
> index b21741135673..b200a7ceafc1 100644
> --- a/arch/x86/boot/compressed/kaslr.c
> +++ b/arch/x86/boot/compressed/kaslr.c
> @@ -548,9 +548,9 @@ static unsigned long slots_fetch_random(void)
> return 0;
> }
Lo
LE 4
> +
> +/* Store the usable memory regions for kaslr */
> +static struct mem_vector mem_usable[MAX_KASLR_MEM_USABLE];
The name xx_usable sounds not so good, while I don't know what
is better. Otherwise this patch looks good to me.
Ack it.
Acked-by: Baoquan He
> +
> +/* The a
On 01/17/18 at 06:53pm, Chao Fan wrote:
> Since only 'movable_node' specified without 'kaslr_mem=' may break
> memory hotplug, so reconmmend users using 'kaslr_mem=' when
> 'movable_node' specified..
>
> Signed-off-by: Chao Fan
> ---
> arch/x86/boot/compressed/kaslr.c | 10 ++
> 1 file c
On 01/17/18 at 06:53pm, Chao Fan wrote:
> In kernel code, if movable_node specified, it will skip the mirror
> feature. So we should also skip mirror feature in KASLR.
>
> Signed-off-by: Chao Fan
> ---
> arch/x86/boot/compressed/kaslr.c | 7 +++
> 1 file changed, 7 insertions(+)
>
> diff --
On 01/17/18 at 06:53pm, Chao Fan wrote:
> Since only 'movable_node' specified without 'kaslr_mem=' may break
> memory hotplug, so reconmmend users using 'kaslr_mem=' when
> 'movable_node' specified..
>
> Signed-off-by: Chao Fan
> ---
> arch/x86/boot/compressed/kaslr.c | 10 ++
> 1 file c
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
Hi Eric,
Sorry I missed your mail contact in the CC list when posted patches.
Have CC-ed them to you one by one. I can send the patches to you
privately if the format is messy and not good for reviewing.
On 01/11/18 at 12:28pm, Eric W. Biederman wrote:
> Baoquan He writes:
>
>
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
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(), it no
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 jum
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
On 01/16/18 at 11:34am, Luiz Capitulino wrote:
> On Tue, 16 Jan 2018 08:43:20 +0800
> Baoquan He wrote:
>
> > On 01/15/18 at 08:49pm, Chao Fan wrote:
> > > Hi Luiz,
> > >
> > > I don't know if this patch is OK for you.
> > > Of coure yo
On 01/15/18 at 08:49pm, Chao Fan wrote:
> Hi Luiz,
>
> I don't know if this patch is OK for you.
> Of coure you can only use kaslr_mem=nn@ss to solve the 1G huge page
> issue. Because we know the region [0,1G] is not suitable for 1G huge
> page, so you can specify ksalr_mem=1G@0 of kaslr_mem=1G to
On 01/12/18 at 01:52pm, Luiz Capitulino wrote:
> On Fri, 12 Jan 2018 10:47:53 +0800
> Chao Fan 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 Thu, Jan 11, 2018 at 1:00 AM, B
On 01/11/18 at 01:05pm, Eric W. Biederman wrote:
> Baoquan He writes:
>
> > Hi all,
> >
> > PING!
> >
> > (Add Fenghua and Eric to this thread)
> >
> > On 01/05/18 at 11:42am, Baoquan He wrote:
> >> On kvm guest, the latest kernel will alw
On 01/11/18 at 10:04am, Kees Cook wrote:
> On Thu, Jan 11, 2018 at 1:00 AM, Baoquan He 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
> >> is one s
Hi Luiz,
On 01/04/18 at 11:21am, Luiz Capitulino wrote:
> Having a generic kaslr parameter to control where the kernel is extracted
> is one solution for this problem.
>
> The general problem statement is that KASLR may break some kernel features
> depending on where the kernel is extracted. Two
Hi all,
PING!
(Add Fenghua and Eric to this thread)
On 01/05/18 at 11:42am, Baoquan He wrote:
> On kvm guest, the latest kernel will always print warning during kdump kernel
> boots
> as below. The reaons is the legacy irq mode is disabled before jump to
> kexec/kdump
>
On 01/10/18 at 02:16pm, Kirill A. Shutemov wrote:
> On Wed, Jan 10, 2018 at 03:08:04AM +, Dave Young wrote:
> > On Tue, Jan 09, 2018 at 12:05:52PM +0300, Kirill A. Shutemov wrote:
> > > On Tue, Jan 09, 2018 at 03:24:40PM +0800, Dave Young wrote:
> > > > On 01/09/1
On 01/06/18 at 02:00am, Jiri Bohac wrote:
> Hi Baoquan,
>
> thank you very much for your review!
>
> On Wed, Dec 27, 2017 at 03:44:49PM +0800, Baoquan He wrote:
> > > > 1) If 'iommu=off' is specified in 1st kernel but not in kdump kernel, it
>
On 01/09/18 at 09:09am, Dave Young wrote:
> On 01/09/18 at 03:13am, Kirill A. Shutemov wrote:
> > On Mon, Jan 08, 2018 at 08:46:53PM +0300, Kirill A. Shutemov wrote:
> > > On Mon, Jan 08, 2018 at 04:04:44PM +, Ingo Molnar wrote:
> > > >
> > > > hi Kirill,
> > > >
> > > > As Mike reported it b
ke IO-APIC Virtual Wire mode setting code
out and wrap it inot a new function ioapic_set_virtual_wire_mode. Meanwhile
change the name of disconnect_bsp_APIC as lapic_set_legacy_irq_mode. These
makes the legacy irq mode setting more understandable.
Signed-off-by: Baoquan He
---
arch/x86/include/
e
disable_IO_APIC as switch_to_legacy_irq_mode. Then only call clear_IO_APIC
when IO-APIC need be disabled. And call switch_to_legacy_irq_mode before
kexec/kdump jumping.
Signed-off-by: Baoquan He
---
arch/x86/include/asm/io_apic.h | 3 ++-
arch/x86/kernel/apic/io_apic.c | 12
arc
fore shutdown of the local APIC") is merged. While in normal kernel,
the legacy irq mode has been set in BIOS.
So we need set the delivery mode AS ExtINT for LVT0 of boot CPU's LAPIC
explicitly if IO-APIC is disabled, to set up through-local-APIC.
Signed-off-by: Baoquan He
---
arch/x8
be consistent with normal kernel.
Patch 3/3 is doing clean up, I am fine if people think it's unnecessary.
Baoquan He (3):
x86/apic: Set up through LAPIC on boot CPU's LINT0 if ioapic is
disabled
x86/apic/kexec: Enable legacy irq mode before jump to kexec/kdump
kernel
x86/api
Sorry, my git send-email config seems incorrect. The patch subject is
not right. So NACK this series, will repost v2.
On 01/05/18 at 11:22am, Baoquan He wrote:
> Kdump kernel will become very slow if 'noapic' is specified in kernel
> command line. Normal kernel doesn't have
ke IO-APIC Virtual Wire mode setting code
out and wrap it inot a new function ioapic_set_virtual_wire_mode. Meanwhile
change the name of disconnect_bsp_APIC as lapic_set_legacy_irq_mode. These
makes the legacy irq mode setting more understandable.
Signed-off-by: Baoquan He
---
arch/x86/include/
h_to_legacy_irq_mode. Then only call clear_IO_APIC
when IO-APIC need be disabled. And call switch_to_legacy_irq_mode before
kexec/kdump jumping.
Signed-off-by: Baoquan He
---
arch/x86/include/asm/io_apic.h | 3 ++-
arch/x86/kernel/apic/io_apic.c | 12
arch/x86/kernel/cra
C before shutdown of the local APIC") is merged. While in normal kernel,
the legacy irq mode has been set in BIOS.
So we need set the delivery mode AS ExtINT for LVT0 of boot CPU's LAPIC
explicitly if IO-APIC is disabled, to set up through-local-APIC.
Signed-off-by: Baoquan He
---
a
normal kernel.
Patch 3/3 is doing clean up, I am fine if people think it's unnecessary.
Baoquan He (3):
x86/apic: Set up through LAPIC on boot CPU's LINT0 if ioapic is
disabled
x86/apic/kexec: Enable legacy irq mode before jump to kexec/kdump
kernel
x86/apic: Clean up t
On 01/04/18 at 04:02pm, Chao Fan wrote:
> In current code, kaslr may choose the memory region in movable
> nodes to extract kernel, which will make the nodes can't be hot-removed.
> To solve it, we can specify the memory region in immovable node.
> Create immovable_mem to store the regions in immov
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 co
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
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 &
em_section*).
Fix it.
Signed-off-by: Baoquan He
Tested-by: Dave Young
Cc: Ingo Molnar
Cc: Andrew Morton
Cc: Andy Lutomirski
Cc: Peter Zijlstra
Cc: Thomas Gleixner
Cc: Atsushi Kumagai
Cc: linux...@kvack.org
---
mm/sparse.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff
On 12/18/17 at 03:37pm, Borislav Petkov wrote:
> On Mon, Dec 18, 2017 at 09:47:36PM +0800, Baoquan He wrote:
> > pr_info("Your BIOS doesn't leave an aperture memory
> > hole\n");
> > pr_info("Please enable
On 12/17/17 at 10:47pm, Borislav Petkov wrote:
> On Sat, Dec 16, 2017 at 09:01:42AM +0800, Baoquan He wrote:
> > 2) If firmware is broken, you can't enable gart in firmware, will
> > firmware engineer fix this since it's a firmware bug?
>
> Slow down and get a rea
On 12/16/17 at 01:15am, 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.
>
> In the past, the GART region was added into the resource map, implemented by
> commit 56dd669a138
On 12/07/17 at 12:16pm, Dou Liyang wrote:
> Hi All,
>
> At 12/07/2017 11:56 AM, Chao Fan wrote:
> > On Thu, Dec 07, 2017 at 11:09:24AM +0800, Baoquan He wrote:
> > > On 12/07/17 at 10:53am, Chao Fan wrote:
> > > > On Wed, Dec 06, 2017 at 05:35:57PM +0800,
On 12/07/17 at 10:53am, Chao Fan wrote:
> On Wed, Dec 06, 2017 at 05:35:57PM +0800, Baoquan He wrote:
> >Hi Chao,
> >
> >Yes, now the code looks much better than the last version.
> >
> >On 12/05/17 at 04:51pm, Chao Fan wrote:
> >> In current code, kas
Hi Chao,
Yes, now the code looks much better than the last version.
On 12/05/17 at 04:51pm, Chao Fan wrote:
> In current code, kaslr may choose the memory region in movable
> nodes to extract kernel, which will make the nodes can't be hot-removed.
> To solve it, we can specify the memory region i
eal with immovable regions.
If put it into process_mem_region(), one level of loop is added. How
about changing it like below. If no immovable_mem, just process the
region in process_immovable_mem(). This we don't need to touch
process_mem_region().
>From 9ae3f5ab0e2f129757495af2412bd52dcf8
On 12/01/17 at 04:27pm, Borislav Petkov wrote:
> On Fri, Dec 01, 2017 at 11:18:51PM +0800, Baoquan He wrote:
> > On 12/01/17 at 02:52pm, Juerg Haefliger wrote:
> > > Loading a kexec kernel using today's linux-tip master with KAISER=y
> > > triggers the following
On 12/01/17 at 02:52pm, Juerg Haefliger wrote:
> Loading a kexec kernel using today's linux-tip master with KAISER=y
> triggers the following warning:
I also noticed this when trigger a crash to jump to kdump kernel, and
kdump kernel failed to bootup. I am trying to fix it on tip/WIP.x86/mm.
Maybe
On 11/28/17 at 10:58pm, Jiri Bohac wrote:
> Hi Baoquan,
>
> On Sun, Nov 12, 2017 at 04:04:26PM +0800, Baoquan He wrote:
> > Solution:
> > 1) Remove the code which support GART IOMMU when it's not enabled in
> > BIOS. This has been done in the new generation of ha
Hi Dave,
Thanks for your effort to push this into upstream. While I have one
concern, please see the inline comments.
On 10/24/17 at 01:31pm, Dave Young wrote:
> Now crashkernel=X will fail if there's not enough memory at low region
> (below 896M) when trying to reserve large memory size. One ca
> CC: Baoquan He
> CC: Dave Young
> CC: Dave Young
> CC: Hari Bathini
> CC: Tony Luck
> CC: Vivek Goyal
> Signed-off-by: Marc-André Lureau
> Acked-by: Gabriel Somlo
ACK
Acked-by: Baoquan He
Thanks
Baoquan
> ---
> kernel/crash_core.c | 1 +
> 1 file
On 11/13/17 at 05:50pm, Chao Fan wrote:
> On Mon, Nov 13, 2017 at 05:26:24PM +0800, Baoquan He wrote:
> >> >> +static bool select_immovable_node(struct mem_vector region,
> >> >> + unsigned long long minimum,
> >> >
On 11/13/17 at 05:18pm, Chao Fan wrote:
> On Mon, Nov 13, 2017 at 04:31:31PM +0800, Baoquan He wrote:
> >On 11/01/17 at 07:32pm, Chao Fan wrote:
> >> Compare the region of memmap entry and immovable_mem, then choose the
> >> intersection to process_mem_r
On 11/01/17 at 07:32pm, Chao Fan wrote:
> There are two same variable "rc" in this function. One is in the
> circulation, the other is out of the circulation. The one out will never
> be used, so drop it.
You can send this clean up patch alone.
>
> Signed-off-by: Chao Fan
> ---
> arch/x86/boot
On 11/01/17 at 07:32pm, Chao Fan wrote:
> Compare the region of memmap entry and immovable_mem, then choose the
> intersection to process_mem_region.
>
> Since the interrelationship between e820 or efi entries and memory
> region in immovable_mem is different:
> One memory region in one node may c
Hi Chao,
Please think more on your patches, better to discuss with your
colleagues and ask them to help review before your post.
On 11/01/17 at 07:32pm, Chao Fan wrote:
> Extend the movable_node to movable_node=nn[KMG]@ss[KMG].
Firstly, apparently we can't make use of movable_node kernel paramet
On 11/12/17 at 04:04pm, Baoquan He wrote:
> On 11/07/17 at 04:34pm, Jiri Bohac wrote:
> > On Tue, Nov 07, 2017 at 02:42:12PM +0100, Jiri Bohac wrote:
> > > On Tue, Nov 07, 2017 at 07:39:56PM +0800, Baoquan He wrote:
> > > > don't worry about
On 11/07/17 at 04:34pm, Jiri Bohac wrote:
> On Tue, Nov 07, 2017 at 02:42:12PM +0100, Jiri Bohac wrote:
> > On Tue, Nov 07, 2017 at 07:39:56PM +0800, Baoquan He wrote:
> > > don't worry about the user space kexec utility either.
> >
> > What's the problem
On 11/10/17 at 11:03am, Chao Fan wrote:
> On Thu, Nov 09, 2017 at 04:21:32PM +0800, Baoquan He wrote:
> >Hi Chao,
> >
> >On 11/01/17 at 07:32pm, Chao Fan wrote:
> >> Compare the region of memmap entry and immovable_mem, then choose the
> >> intersection to p
Hi Chao,
On 11/01/17 at 07:32pm, Chao Fan wrote:
> Compare the region of memmap entry and immovable_mem, then choose the
> intersection to process_mem_region.
>
> Since the interrelationship between e820 or efi entries and memory
> region in immovable_mem is different:
Could you paste a bootlog
s been a mechanism to check them, I am fine to leave it as is
or the tools like lindent to deal with it.
Thanks
Baoquan
>
> > -Original Message-
> > From: Baoquan He [mailto:b...@redhat.com]
> > Sent: Tuesday, November 7, 2017 2:43 AM
> > To: linux-kernel@vger.
, it's pointed out in an Redhat internal patch reviewing. I
am fine if no one like it.
If approved, I can update the git log to make it better and repost.
Thanks
Baoquan
On 10/06/17 at 11:37am, Baoquan He wrote:
> Currently total_size passed into elf_map() is non-zero only for dynamic
On 11/06/17 at 10:56am, Jiri Bohac wrote:
> On Mon, Nov 06, 2017 at 05:27:29PM +0800, Baoquan He wrote:
> > > 0010-c7e7 : System RAM
> > > 0b00-0b792eb5 : Kernel code
> > > 0b792eb6-0bd5d47f : Kernel data
> > > 0c274000-0c3c8fff :
PING!
On 10/28/17 at 09:34am, Baoquan He wrote:
> 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/actbl
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
> 0xb800
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
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
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 the
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
e expressive name, to avoid conflict with
new 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
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
> help
;
> 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
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
ilding error will be reported since these two 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: Li
es up 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 67780ebe5c99190d2a946de106bd0c7
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
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 s
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 r
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
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
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
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 command
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
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
: 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
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
.
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
: 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
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.
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
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 here
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 RA
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
>
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 uv_nmi_init(v
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 only
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
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 o
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
_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: K
uture.
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 +++
ction 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/in
ve a 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
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 -
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 fa
701 - 800 of 1622 matches
Mail list logo
