On 08/30/19 at 05:47pm, Masayoshi Mizuma wrote:
> From: Masayoshi Mizuma
>
> Cleanup calculation for direct mapping size.
>
> Signed-off-by: Baoquan He
> Signed-off-by: Masayoshi Mizuma
> ---
> arch/x86/mm/kaslr.c | 50 +++
On 08/30/19 at 05:47pm, Masayoshi Mizuma wrote:
> From: Masayoshi Mizuma
>
> Get the max address from SRAT and write it into boot_params->max_addr.
>
> Signed-off-by: Masayoshi Mizuma
> ---
> arch/x86/boot/compressed/acpi.c | 24 ++--
> 1 file changed, 18 insertions(+), 6
-by: Masayoshi Mizuma
> ---
> Documentation/x86/zero-page.rst | 4
> arch/x86/include/uapi/asm/bootparam.h | 2 +-
> 2 files changed, 5 insertions(+), 1 deletion(-)
Reviewed-by: Baoquan He
Thanks
Baoquan
>
> diff --git a/Documentation/x86/zero-page.rst b/Documentation/x86/zero-page.
ble(void)
> return 0;
> }
Reviewed-by: Baoquan He
Thanks
Baoquan
>
> +static void subtable_parse(struct acpi_subtable_header *sub_table, int *num)
> +{
> + struct acpi_srat_mem_affinity *ma;
> +
> + ma = (struct acpi_srat_mem_affinity *)sub_table;
> +
On 08/22/19 at 10:26am, Qian Cai wrote:
> If "i >= MAX_MEMMAP_REGIONS" already when entering mem_avoid_memmap(),
> even without the return statement the loop will not run anyway. The only
> time it needs to set "memmap_too_large = true" in this situation is
> "memmap_too_large" is "false"
On 08/22/19 at 08:32am, Qian Cai wrote:
> MAX_MEMMAP_REGIONS is a macro that equal to 4. "i" is static local
> variable that default to 0. The comparison "i >= MAX_MEMMAP_REGIONS"
> will always be false.
Seems not true. mem_avoid_memmap() could be invoked many times if
multiple memmap= added. It
On 08/21/19 at 05:12pm, Qian Cai wrote:
> > > Does disabling CONFIG_RANDOMIZE_BASE help? Maybe that workaround has
> > > regressed. Effectively we need to find what is causing the kernel to
> > > sometimes be placed in the middle of a custom reserved memmap= range.
> >
> > Yes, disabling KASLR
Commit-ID: 8ff80fbe7e9870078b1cc3c2cdd8f3f223b333a9
Gitweb: https://git.kernel.org/tip/8ff80fbe7e9870078b1cc3c2cdd8f3f223b333a9
Author: Baoquan He
AuthorDate: Fri, 24 May 2019 15:38:10 +0800
Committer: Thomas Gleixner
CommitDate: Fri, 28 Jun 2019 07:14:59 +0200
x86/kdump/64: Restrict
Commit-ID: ee338b9ee2822e65a85750da6129946c14962410
Gitweb: https://git.kernel.org/tip/ee338b9ee2822e65a85750da6129946c14962410
Author: Baoquan He
AuthorDate: Fri, 24 May 2019 15:38:09 +0800
Committer: Thomas Gleixner
CommitDate: Fri, 28 Jun 2019 07:14:59 +0200
x86/kexec/64: Prevent
Commit-ID: f2d08c5d3bcf3f7ef788af122b57a919efa1e9d0
Gitweb: https://git.kernel.org/tip/f2d08c5d3bcf3f7ef788af122b57a919efa1e9d0
Author: Baoquan He
AuthorDate: Fri, 24 May 2019 15:38:08 +0800
Committer: Thomas Gleixner
CommitDate: Fri, 28 Jun 2019 07:14:59 +0200
x86/boot: Add
On 06/24/19 at 03:23pm, Kirill A. Shutemov wrote:
> On Mon, Jun 24, 2019 at 06:07:42PM +0800, Baoquan He wrote:
> > On 06/21/19 at 01:54pm, Kirill A. Shutemov wrote:
> > > > The code block as below is to zero p4d entries which are not coverred by
> > > > the cur
nit() does. It makes it work correctly with
> phys-virt mismatch.
>
> Signed-off-by: Kirill A. Shutemov
> Reported-and-tested-by: Kyle Pelton
> Fixes: b569c1843498 ("x86/mm/KASLR: Reduce randomization granularity for
> 5-level paging to 1GB")
> Cc: Baoquan He
>
On 06/21/19 at 01:54pm, Kirill A. Shutemov wrote:
> > The code block as below is to zero p4d entries which are not coverred by
> > the current memory range, and if haven't been mapped already. It's
> > clearred away in this patch, could you also mention it in log, and tell
> > why it doesn't
zation, this
phys_p4d_init() part is included. Not sure why I missed it when later
took PUD level randomization for 5-level.
https://github.com/baoquan-he/linux/commit/dc91f5292bf1f55666c9139b6621d830b5b38aa5
Have some concerns, please check.
> [0.00] WARNING: CPU: 0 PID: 0 at arch/x86/m
is discarded. This is not clearly documented.
>
> Add a new symbol, __end_of_kernel_reserve, that more readily identifies
> what is reserved, along with comments that indicate what is reserved,
> what is discarded and what needs to be done to prevent a section from
> being discarded.
>
> C
88000-c7ff7 : System RAM
> 8cf00-8cf7677d4 : Kernel code (0x7677d4)
> 8cf7677d5-8cfe2e0bf : Kernel data (0x6c68ea)
> 8d0074000-8d0372fff : Kernel bss (0x2fefff)
>
> Cc: Baoquan He
> Cc: Lianbo
On 06/12/19 at 07:10pm, Lendacky, Thomas wrote:
> On 6/12/19 1:07 PM, Borislav Petkov wrote:
> > On Wed, Jun 12, 2019 at 04:52:22PM +, Lendacky, Thomas wrote:
> >> I think the discussion ended up being that debuginfo wasn't being stripped
> >> from the kernel and initrd (mainly the initrd).
Hi Tom,
On 06/11/19 at 05:52pm, lijiang wrote:
> After applied Tom's patch, i changed the reserved memory(for crash kernel) to
> the
> above 256M(>256M), such as crashkernel=320M or 384M,512M..., the kdump kernel
> can
> work and successfully dump the vmcore.
>
> But the kdump kernel always
Hi,
On 05/24/19 at 03:38pm, Baoquan He wrote:
>
Ping.
Can anyone help do further reviewing on this patchset? Or consider
merging since people have ack-ed?
Thanks
Baoquan
> The v4 cover letter tells the background about this adding, paste the
> link here for referenc
On 06/07/19 at 02:16pm, tip-bot for Baoquan He wrote:
> Commit-ID: 00e5a2bbcc31d5fea853f8daeba0f06c1c88c3ff
> Gitweb:
> https://git.kernel.org/tip/00e5a2bbcc31d5fea853f8daeba0f06c1c88c3ff
> Author: Baoquan He
> AuthorDate: Thu, 23 May 2019 10:57:44 +0800
> Committer
Commit-ID: 00e5a2bbcc31d5fea853f8daeba0f06c1c88c3ff
Gitweb: https://git.kernel.org/tip/00e5a2bbcc31d5fea853f8daeba0f06c1c88c3ff
Author: Baoquan He
AuthorDate: Thu, 23 May 2019 10:57:44 +0800
Committer: Borislav Petkov
CommitDate: Fri, 7 Jun 2019 23:12:13 +0200
x86/mm/KASLR: Compute
Hi,
On 05/29/19 at 01:14pm, Sasha Levin wrote:
> Hi,
>
> [This is an automated email]
>
> This commit has been processed because it contains a -stable tag.
> The stable tag indicates that it's relevant for the following trees: all
>
> The bot has tested the following trees: v5.1.4, v5.0.18,
will be loaded after system bootup, 5-level kernel
or 4-level kernel.
Signed-off-by: Baoquan He
Acked-by: Kirill A. Shutemov
Acked-by: Dave Young
---
arch/x86/kernel/setup.c | 15 ---
include/linux/sizes.h | 1 +
2 files changed, 13 insertions(+), 3 deletions(-)
diff --git a/arch/x86
paging is active, check the
xloadflags whether the kexec kernel can handle 5-level paging at least in
the decompressor. If not, reject the load attempt and print out error
message.
Signed-off-by: Baoquan He
Acked-by: Kirill A. Shutemov
---
arch/x86/kernel/kexec-bzimage64.c | 5 +
1 file
Change the constant to match the notation for the rest of defines as
Kirill suggested;
v1->v2:
Correct the subject of patch 1 according to tglx's comment;
Add more information to cover-letter to address reviewers' concerns;
Baoquan He (3):
x86/boot: Add xloadflags bits for 5-level ker
-off-by: Baoquan He
Acked-by: Kirill A. Shutemov
---
arch/x86/boot/header.S| 12 +++-
arch/x86/include/uapi/asm/bootparam.h | 2 ++
2 files changed, 13 insertions(+), 1 deletion(-)
diff --git a/arch/x86/boot/header.S b/arch/x86/boot/header.S
index 850b8762e889
On 05/22/19 at 11:11am, Dave Young wrote:
> > /*
> > - * Keep the crash kernel below this limit. On 32 bits earlier kernels
> > - * would limit the kernel to the low 512 MiB due to mapping restrictions.
> > + * Keep the crash kernel below this limit.
> > + *
> > + * On 32 bits earlier kernels
namic for
CONFIG_X86_5LEVEL=y")
Signed-off-by: Baoquan He
Acked-by: Kirill A. Shutemov
Reviewed-by: Kees Cook
Cc: sta...@vger.kernel.org
---
v4->v5:
Add Fixes tag and Cc to stable.
v3->v4:
Fix the incorrect style of code comment;
Add ack tags from Kirill and Kees.
v3 discussion
On 05/22/19 at 11:20am, Dave Young wrote:
> How about the userspace kexec-tools? It needs a similar detection, but
> I'm not sure how to detect paging mode, maybe some sysfs entry or
> vmcoreinfo in /proc/vmcore
In usersapce, I plan to parse /proc/kcore to get the starting address
of page_offset
On 05/22/19 at 11:11am, Dave Young wrote:
> Hi Baoquan,
>
> A few nitpicks, otherwise
> Acked-by: Dave Young
>
> On 05/09/19 at 09:36am, Baoquan He wrote:
> > Restrict kdump to only reserve crashkernel below 64TB.
> >
> > The reaons is that the kd
On 05/08/19 at 05:47pm, Kirill A. Shutemov wrote:
> On Wed, May 08, 2019 at 05:35:20PM +0800, Baoquan He wrote:
> > On 05/08/19 at 11:04am, Borislav Petkov wrote:
> > > On Wed, May 08, 2019 at 04:24:18PM +0800, Baoquan He wrote:
> > > > I think thi
paging is active, check the
xloadflags whether the kexec kernel can handle 5-level paging at least in
the decompressor. If not, reject the load attempt and print out error
message.
Signed-off-by: Baoquan He
Acked-by: Kirill A. Shutemov
---
v4->v5:
Update the output error message per tgl
On 05/09/19 at 09:36am, Baoquan He wrote:
> If the running kernel has 5-level paging activated, the 5-level paging
> mode is preserved across kexec. If the kexec'ed kernel does not contain
> support for handling active 5-level paging mode in the decompressor, the
> decompressor will cr
will be loaded after system bootup, 5-level kernel
or 5-level kernel.
Signed-off-by: Baoquan He
Acked-by: Kirill A. Shutemov
---
arch/x86/kernel/setup.c | 17 ++---
1 file changed, 14 insertions(+), 3 deletions(-)
diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index
nel.org/r/20180829141624.13985-1-...@redhat.com
Later a v1 RESEND version:
http://lkml.kernel.org/r/20190125022817.29506-1-...@redhat.com
V2 post is here:
http://lkml.kernel.org/r/20190312005004.19182-1-...@redhat.com
v3 post:
http://lkml.kernel.org/r/20190312103051.18086-1-...@redhat.com
Baoq
paging is active, check the
xloadflags whether the kexec kernel can handle 5-level paging at least in
the decompressor. If not, reject the load attempt and print out error
message.
Signed-off-by: Baoquan He
Acked-by: Kirill A. Shutemov
---
arch/x86/kernel/kexec-bzimage64.c | 5 +
1 file
-off-by: Baoquan He
Acked-by: Kirill A. Shutemov
---
arch/x86/boot/header.S| 12 +++-
arch/x86/include/uapi/asm/bootparam.h | 2 ++
2 files changed, 13 insertions(+), 1 deletion(-)
diff --git a/arch/x86/boot/header.S b/arch/x86/boot/header.S
index 850b8762e889
On 05/08/19 at 11:04am, Borislav Petkov wrote:
> On Wed, May 08, 2019 at 04:24:18PM +0800, Baoquan He wrote:
> > I think this's worth noticing stable tree:
> >
> > Cc: sta...@vger.kernel.org
>
> Fixes: ?
Not sure which commit validated 5-level.
Hi Kirill,
On 05/08/19 at 04:04pm, Baoquan He wrote:
> kernel_randomize_memory() hardcodes the size of vmemmap section as 1 TB,
> to support the maximum amount of system RAM in 4-level paging mode, 64 TB.
>
> However, 1 TB is not enough for vmemmap in 5-level paging mode. Assuming
> the size
up to 1 TB
boundary. In 4-level it's always 1 TB. In 5-level it's adjusted on demand.
The current code reserves 0.5 PB for vmemmap in 5-level. In this new way,
the left space can be saved to join randomization to increase the entropy.
Signed-off-by: Baoquan He
Acked-by: Kirill A. Shutemov
Reviewed
On 04/28/19 at 09:54pm, Kirill A. Shutemov wrote:
> > @@ -109,6 +110,14 @@ void __init kernel_randomize_memory(void)
> > if (memory_tb < kaslr_regions[0].size_tb)
> > kaslr_regions[0].size_tb = memory_tb;
> >
> > + /**
>
> Nit: that is weird style for inline comment.
Right,
On 04/26/19 at 12:04pm, Borislav Petkov wrote:
> On Fri, Apr 26, 2019 at 05:23:48PM +0800, Baoquan He wrote:
> > I sent private mail to Kirill and Kees. Kirill haven't replied yet, he
> > could be busy with something else as he doesn't show up recently on
> > lkml.
>
&
On 04/22/19 at 05:17pm, Borislav Petkov wrote:
> + hpa
>
> On Mon, Apr 22, 2019 at 10:33:46PM +0800, Baoquan He wrote:
> > On 04/19/19 at 01:36pm, Borislav Petkov wrote:
> > > On Fri, Apr 19, 2019 at 01:28:01PM +0200, Borislav Petkov wrote:
> > > > Read agai
Hi Boris,
On 04/15/19 at 09:47pm, Borislav Petkov wrote:
> On Sun, Apr 14, 2019 at 03:28:04PM +0800, Baoquan He wrote:
> > kernel_randomize_memory() hardcodes the size of vmemmap section as 1 TB,
> > to support the maximum amount of system RAM in 4-level paging mode, 64 TB.
> &g
Cc: Dave Young
Link:
https://lkml.kernel.org/r/20190408231011.ga5...@jeru.linux.bs1.fc.nec.co.jp
Signed-off-by: Baoquan He
---
arch/x86/boot/compressed/acpi.c | 143
1 file changed, 107 insertions(+), 36 deletions(-)
diff --git a/arch/x86/boot/compressed/ac
Hi Kirill, Kees,
On 04/22/19 at 05:10pm, Baoquan He wrote:
> kernel_randomize_memory() hardcodes the size of vmemmap section as 1 TB,
> to support the maximum amount of system RAM in 4-level paging mode, 64 TB.
Could you help review this one, and offer ack if it's OK to you?
Thanks
Baoquan
up to 1 TB
boundary. In 4-level it's always 1 TB. In 5-level it's adjusted on demand.
The current code reserves 0.5 PB for vmemmap in 5-level. In this new method,
the left space can be saved to join randomization to increase the entropy.
Signed-off-by: Baoquan He
---
v2->v3:
Fix typo Bo
ow reservation under 4G, so still keep <4G as default.
>
> Signed-off-by: Dave Young
> Reviewed-by: Ingo Molnar
> ---
Ack the whole series, thanks for the effort.
Acked-by: Baoquan He
> Documentation/admin-guide/kernel-parameters.txt |7 +--
> arch/x
Commit-ID: ec3937107ab43f3e8b2bc9dad95710043c462ff7
Gitweb: https://git.kernel.org/tip/ec3937107ab43f3e8b2bc9dad95710043c462ff7
Author: Baoquan He
AuthorDate: Thu, 4 Apr 2019 10:03:13 +0800
Committer: Borislav Petkov
CommitDate: Thu, 18 Apr 2019 10:42:58 +0200
x86/mm/KASLR: Fix
On 04/17/19 at 05:01pm, Borislav Petkov wrote:
> On Wed, Apr 17, 2019 at 04:35:36PM +0800, Baoquan He wrote:
> > I made a new one to add this fact, I can repost if it's OK to you.
>
> No, it looks ok and I can take it from here.
>
> Also, resending too often is annoying,
On 04/15/19 at 09:47pm, Borislav Petkov wrote:
> On Sun, Apr 14, 2019 at 03:28:04PM +0800, Baoquan He wrote:
> > kernel_randomize_memory() hardcodes the size of vmemmap section as 1 TB,
> > to support the maximum amount of system RAM in 4-level paging mode, 64 TB.
> &g
you.
Thanks.
>From 6f0fdb9df6acdcd42b8cbdecaf5058c3090fd577 Mon Sep 17 00:00:00 2001
From: Baoquan He
Date: Thu, 4 Apr 2019 10:03:13 +0800
Subject: [PATCH] x86/mm/KASLR: Fix the size of the direct mapping section
kernel_randomize_memory() uses __PHYSICAL_MASK_SHIFT to calculate
the maximu
64TB~120TB
So the code should use MAX_PHYSMEM_BITS instead. Fix it by replacing
__PHYSICAL_MASK_SHIFT with MAX_PHYSMEM_BITS.
Fixes: b83ce5ee9147 ("x86/mm/64: Make __PHYSICAL_MASK_SHIFT always 52")
Acked-by: Kirill A. Shutemov
Reviewed-by: Thomas Garnier
Signed-off-by: Baoqu
to 1 TB
boundary. In 4-level it's always 1 TB. In 5-level it's adjusted on demand.
The current code reserves 0.5 PB for vmemmap in 5-level. In this new methor,
the left space can be saved to join randomization to increase the entropy.
Signed-off-by: Baoquan He
---
arch/x86/mm/kaslr.c | 11
6/6, it happened on SGI UV system. Mike and
Frank have sent a machine with cards to our lab and loaned to me, I am
still debugging and discussing with Mike about the verification.
Baoquan He (2):
x86/mm/KASLR: Fix the size of the direct mapping section
x86/mm/KASLR: Fix the size of vmemmap sect
On 04/12/19 at 02:55pm, Baoquan He wrote:
> kernel_randomize_memory() uses __PHYSICAL_MASK_SHIFT to calculate
> the maximum amount of system RAM supported. The size of the direct
> mapping section is obtained from the smaller one of the below two
> values:
>
> (actual system
On 04/12/19 at 02:55pm, Baoquan He wrote:
> v1->v2:
> Rewrite log of the two patches. No functionality change.
~~ Sorry, I meant no new code change.
>
> ~
> v1 backg
o the code should use MAX_PHYSMEM_BITS instead. Fix it by replacing
__PHYSICAL_MASK_SHIFT with MAX_PHYSMEM_BITS.
Fixes: b83ce5ee9147 ("x86/mm/64: Make __PHYSICAL_MASK_SHIFT always 52")
Acked-by: Kirill A. Shutemov
Reviewed-by: Thomas Garnier
Signed-off-by: Baoquan He
---
arch/x86/mm/ka
ike and
Frank have sent a machine with cards to our lab and loaned to me, I am
still debugging and discussing with Mike about the verification.
Baoquan He (2):
x86/mm/KASLR: Fix the size of the direct mapping section
x86/mm/KASLR: Fix the size of vmemmap section
arch/x86/mm/kaslr.c |
boundary. In 4-level it's always 1 TB. In 5-level it's adjusted on demand.
The current code reserves 0.5 PB for vmemmap in 5-level. In this way, the
left space can be saved to join randomization to increase the entropy.
Signed-off-by: Baoquan He
---
arch/x86/mm/kaslr.c | 11 ++-
1 file
On 04/11/19 at 08:16am, Junichi Nomura wrote:
> On 4/11/19 5:09 PM, Borislav Petkov wrote:
> > On Wed, Apr 10, 2019 at 11:34:51PM +, Junichi Nomura wrote:
> >> But efi_get_rsdp_addr() needs to check whether the kernel was
> >> kexec booted to avoid accessing invalid EFI table address.
> >>
On 04/06/19 at 06:43am, Borislav Petkov wrote:
> On Sat, Apr 06, 2019 at 09:51:19AM +0800, Baoquan He wrote:
> > It's KASLR happened in kernel_randomize_memory() of arch/x86/mm/kaslr.c .
>
> What is "KASLR happened in"? This doesn't make any sense. When you look
&g
On 04/05/19 at 07:22pm, Thomas Gleixner wrote:
> On Fri, 5 Apr 2019, Borislav Petkov wrote:
> > On Thu, Apr 04, 2019 at 10:03:13AM +0800, Baoquan He wrote:
> > > In memory region KASLR, __PHYSICAL_MASK_SHIFT is taken to calculate
> >
> > What is "memory region
On 04/05/19 at 06:58pm, Borislav Petkov wrote:
> On Thu, Apr 04, 2019 at 10:03:13AM +0800, Baoquan He wrote:
> > In memory region KASLR, __PHYSICAL_MASK_SHIFT is taken to calculate
>
> What is "memory region KASLR"?
It's KASLR happened in kernel_randomize_memory
On 03/12/19 at 06:30pm, Baoquan He wrote:
> This is v3 post.
>
> The original v1 post can be found here:
> http://lkml.kernel.org/r/20180829141624.13985-1-...@redhat.com
>
> Later a v1 RESEND version:
> http://lkml.kernel.org/r/20190125022817.29506-1-...@redhat.com
>
&
On 04/05/19 at 10:23pm, Thomas Gleixner wrote:
> On Tue, 12 Mar 2019, Baoquan He wrote:
>
> > Add two bits XLF_5LEVEL and XLF_5LEVEL_ENABLED for 5-level kernel.
> > Bit XLF_5LEVEL indicates if 5-level related code is contained
> > in this kernel.
> > Bi
On 04/05/19 at 10:38pm, Thomas Gleixner wrote:
> On Tue, 12 Mar 2019, Baoquan He wrote:
>
> > In relocate_kernel() CR4.LA57 flag is set before kexec jumping if
> > the kernel has 5-level paging enabled. Then in boot/compressed/head_64.S,
> > it will check if the booting k
Commit-ID: 0925dda5962e9b55e4d38a72eba93858f24bac41
Gitweb: https://git.kernel.org/tip/0925dda5962e9b55e4d38a72eba93858f24bac41
Author: Baoquan He
AuthorDate: Fri, 8 Mar 2019 10:56:15 +0800
Committer: Thomas Gleixner
CommitDate: Fri, 5 Apr 2019 22:13:00 +0200
x86/mm/KASLR: Use only
Commit-ID: b569c18434987163a05f05a12cdf6a9975c55ff3
Gitweb: https://git.kernel.org/tip/b569c18434987163a05f05a12cdf6a9975c55ff3
Author: Baoquan He
AuthorDate: Fri, 8 Mar 2019 10:56:16 +0800
Committer: Thomas Gleixner
CommitDate: Fri, 5 Apr 2019 22:13:52 +0200
x86/mm/KASLR: Reduce
PING
Any comment for this patch, Or consider to merge?
On 03/12/19 at 06:30pm, Baoquan He wrote:
> This is v3 post.
>
> The original v1 post can be found here:
> http://lkml.kernel.org/r/20180829141624.13985-1-...@redhat.com
>
> Later a v1 RESEND version:
> htt
PING
Is there any comment for this patchset, or could we consider to merge
them?
On 03/08/19 at 10:56am, Baoquan He wrote:
> This is v3 post, v2 post is here:
> http://lkml.kernel.org/r/20190228003522.9957-1-...@redhat.com
> v1 can be found here:
> http://lkml.kernel.org/r/201902241
ace should be saved to join randomization.
So, here MAX_PHYSMEM_BITS should be used instead. Fix it by replacing
__PHYSICAL_MASK_SHIFT with MAX_PHYSMEM_BITS.
Acked-by: Kirill A. Shutemov
Reviewed-by: Thomas Garnier
Signed-off-by: Baoquan He
---
arch/x86/mm/kaslr.c | 2 +-
1 file changed, 1 inser
.
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 387d4ed25d7c..4679a0075048 100644
--- a/arch/x86/mm/kaslr.c
+++ b/arch/x86/mm/kaslr.c
@@ -52,7 +52,7 @@ static
is very rare, still waiting. So defer that bug fix reposting
later.
Baoquan He (2):
x86/mm/KASLR: Fix the wrong calculation of memory region initial size
x86/mm/KASLR: Calculate the actual size of vmemmap region
arch/x86/mm/kaslr.c | 13 +++--
1 file changed, 11 insertions(+), 2
On 04/02/19 at 03:34pm, Oscar Salvador wrote:
> NODEMASK_ALLOC is used to allocate a nodemask bitmap, ant it does it by
~ and
> first determining whether it should be allocated in the stack or dinamically
On 04/03/19 at 10:58am, Pingfan Liu wrote:
> On Tue, Apr 2, 2019 at 4:08 PM Baoquan He wrote:
> >
> > > +/* handle crashkernel=x@y or =range1:size1[,range2:size2,...]@offset
> > > options */
> > > +static void mem_avoid_specified_crashkernel_region(char *o
> +/* handle crashkernel=x@y or =range1:size1[,range2:size2,...]@offset options
> */
> +static void mem_avoid_specified_crashkernel_region(char *option)
> +{
> + unsigned long long crash_size, crash_base = 0;
> + char*first_colon, *first_space, *cur = option;
> +
Another thing which
gt; >region. To avoid this uncertainty, asking KASLR to skip the required
> >region.
> >
> >Signed-off-by: Pingfan Liu
> >Cc: Thomas Gleixner
> >Cc: Ingo Molnar
> >Cc: Borislav Petkov
> >Cc: "H. Peter Anvin"
> >Cc: Baoquan He
> >Cc
;
> Signed-off-by: Pingfan Liu
> Cc: Thomas Gleixner
> Cc: Ingo Molnar
> Cc: Borislav Petkov
> Cc: "H. Peter Anvin"
> Cc: Baoquan He
> Cc: Will Deacon
> Cc: Nicolas Pitre
> Cc: Pingfan Liu
> Cc: Chao Fan
> Cc: "Kirill A. Shutemov"
> Cc: Ard
' and 'phys_device'
are not used by anyone. Remove them.
Signed-off-by: Baoquan He
Acked-by: Michal Hocko
Reviewed-by: Rafael J. Wysocki
Reviewed-by: Mukesh Ojha
Reviewed-by: Oscar Salvador
---
v3->v4:
Remove useless parameters in remove_memory_section().
drivers/base/memory.c |
The code comment above sparse_add_one_section() is obsolete and
incorrect, clean it up and write new one.
Signed-off-by: Baoquan He
Acked-by: Michal Hocko
Reviewed-by: Oscar Salvador
Reviewed-by: Mukesh Ojha
Reviewed-by: Mike Rapoport
---
v3->v4:
Improve the doc format further.
On 03/29/19 at 11:36am, Oscar Salvador wrote:
> > +/**
> > + * sparse_add_one_section - add a memory section
> > + * @nid: The node to add section on
> > + * @start_pfn: start pfn of the memory range
> > + * @altmap: device page map
> > + *
> > + * This is only intended for hotplug.
> > + *
> > +
On 03/29/19 at 10:37am, Oscar Salvador wrote:
> On Fri, Mar 29, 2019 at 10:13:25AM +0100, Michal Hocko wrote:
> > On Fri 29-03-19 16:29:15, Baoquan He wrote:
> > > The input parameter 'phys_index' of memory_block_action() is actually
> > > the section number, but not the
On 03/29/19 at 06:00pm, Pingfan Liu wrote:
> On Fri, Mar 29, 2019 at 3:34 PM Baoquan He wrote:
> >
> > On 03/29/19 at 03:25pm, Pingfan Liu wrote:
> > > On Fri, Mar 29, 2019 at 2:27 PM Baoquan He wrote:
> > > >
> > > > On 03/29/19 at 01:45pm, Pingfa
The input parameter 'phys_index' of memory_block_action() is actually
the section number, but not the phys_index of memory_block. This is
a relict from the past when one memory block could only contain one
section.
Rename it to start_section_nr.
Signed-off-by: Baoquan He
Acked-by: Michal Hocko
On 03/29/19 at 10:13am, Michal Hocko wrote:
> On Fri 29-03-19 16:29:15, Baoquan He wrote:
> > The input parameter 'phys_index' of memory_block_action() is actually
> > the section number, but not the phys_index of memory_block. Fix it.
>
> I have tried to explain that
The code comment above sparse_add_one_section() is obsolete and
incorrect, clean it up and write new one.
Signed-off-by: Baoquan He
---
v2->v3:
Normalize the code comment to use '/**' at 1st line of doc
above function.
v1-v2:
Add comments to explain what the returned value means for
e
The input parameter 'phys_index' of memory_block_action() is actually
the section number, but not the phys_index of memory_block. Fix it.
Signed-off-by: Baoquan He
---
v2->v3:
Rename the parameter to 'start_section_nr' from 'sec'.
drivers/base/memory.c | 7 ---
1 file changed
On 03/29/19 at 03:25pm, Pingfan Liu wrote:
> On Fri, Mar 29, 2019 at 2:27 PM Baoquan He wrote:
> >
> > On 03/29/19 at 01:45pm, Pingfan Liu wrote:
> > > On Fri, Mar 22, 2019 at 4:34 PM Baoquan He wrote:
> > > >
> > > > On 03/22/19 at 03:52pm, Ba
addressing reviewers' concern. Sorry for the noise.
On 03/26/19 at 05:02pm, Baoquan He wrote:
> This is v2 post. V1 is here:
> http://lkml.kernel.org/r/20190320073540.12866-1-...@redhat.com
>
> This patchset includes 4 patches. The first three patches are around
> sparse_add_one_section(
On 03/29/19 at 01:45pm, Pingfan Liu wrote:
> On Fri, Mar 22, 2019 at 4:34 PM Baoquan He wrote:
> >
> > On 03/22/19 at 03:52pm, Baoquan He wrote:
> > > On 03/22/19 at 03:43pm, Pingfan Liu wrote:
> > > > > > +/* parse crashkernel=x@y option */
> > &
Commit-ID: 0f02daed4e089c7a380a0ffdc9d93a5989043cf4
Gitweb: https://git.kernel.org/tip/0f02daed4e089c7a380a0ffdc9d93a5989043cf4
Author: Baoquan He
AuthorDate: Mon, 4 Mar 2019 13:55:46 +0800
Committer: Borislav Petkov
CommitDate: Wed, 27 Mar 2019 14:00:51 +0100
x86/boot: Fix incorrect
Hi Michal,
On 03/26/19 at 03:31pm, Michal Hocko wrote:
> > > > OK, I am fine to drop it. Or only put the section existence checking
> > > > earlier to avoid unnecessary usemap/memmap allocation?
> > >
> > > DO you have any data on how often that happens? Should basically never
> > > happening,
On 03/26/19 at 03:03pm, Michal Hocko wrote:
> On Tue 26-03-19 21:45:22, Baoquan He wrote:
> > On 03/26/19 at 11:17am, Michal Hocko wrote:
> > > On Tue 26-03-19 18:08:17, Baoquan He wrote:
> > > > On 03/26/19 at 10:29am, Michal Hocko wrote:
> > > > &g
On 03/26/19 at 11:17am, Michal Hocko wrote:
> On Tue 26-03-19 18:08:17, Baoquan He wrote:
> > On 03/26/19 at 10:29am, Michal Hocko wrote:
> > > On Tue 26-03-19 17:02:25, Baoquan He wrote:
> > > > Reorder the allocation of usemap and memmap since usemap allocation
>
On 03/26/19 at 04:43am, Matthew Wilcox wrote:
> On Tue, Mar 26, 2019 at 05:02:27PM +0800, Baoquan He wrote:
> > The input parameter 'phys_index' of memory_block_action() is actually
> > the section number, but not the phys_index of memory_block. Fix it.
>
> > static int
On 03/26/19 at 10:29am, Michal Hocko wrote:
> On Tue 26-03-19 17:02:25, Baoquan He wrote:
> > Reorder the allocation of usemap and memmap since usemap allocation
> > is much simpler and easier. Otherwise hard work is done to make
> > memmap ready, then have to rollback j
On 03/26/19 at 05:36pm, Chao Fan wrote:
> On Tue, Mar 26, 2019 at 05:30:57PM +0800, Baoquan He wrote:
> >On 03/26/19 at 10:23am, Michal Hocko wrote:
> >> On Tue 26-03-19 17:02:24, Baoquan He wrote:
> >> > The code comment above sparse_add_one_section() is obsolete and
On 03/26/19 at 10:23am, Michal Hocko wrote:
> On Tue 26-03-19 17:02:24, Baoquan He wrote:
> > The code comment above sparse_add_one_section() is obsolete and
> > incorrect, clean it up and write new one.
> >
> > Signed-off-by: Baoquan He
>
> Please note that y
These functions are used to allocate/free section memmap, have nothing
to do with kmalloc/free during the handling. Rename them to remove
the confusion.
Signed-off-by: Baoquan He
Acked-by: Mike Rapoport
---
mm/sparse.c | 16
1 file changed, 8 insertions(+), 8 deletions
201 - 300 of 3124 matches
Mail list logo
