[PATCH v4 2/4] 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 v4 4/4] mm/sparse: Optimize memmap allocation during sparse_init()

ts 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 section's ->section_mem_map, fetch usemap and memmap from usemap_map[] and map_map[] array and set them into mem_section[] accordingly. Signed-off

[PATCH v4 1/4] 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 --- mm/sparse.c | 7 +++ 1 file changed, 7 insertions(+) diff --git a/mm/sparse.c b/mm/sparse.c index 62eef264a7bd..48cf7b7982e2 100644

[PATCH v4 0/4] mm/sparse: Optimize memmap allocation during sparse_init()

according to Dave's suggestion. Fix code bug in patch 0002 reported by test robot. Baoquan He (4): mm/sparse: Add a static variable nr_present_sections mm/sparsemem: Defer the ms->section_mem_map clearing mm/sparse: Add a new parameter 'data_unit_size' for alloc_usemap_and_memmap mm/spar

[PATCH v4 3/4] mm/sparse: Add a new parameter 'data_unit_size' for alloc_usemap_and_memmap

It's used to pass the size of map data unit into alloc_usemap_and_memmap, and is preparation for next patch. Signed-off-by: Baoquan He --- mm/sparse.c | 10 +++--- 1 file changed, 7 insertions(+), 3 deletions(-) diff --git a/mm/sparse.c b/mm/sparse.c index 3d697292be08..4a58f8809542 100644

[PATCH v4 2/4] 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 --- 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-vmemmap.c index bd0276

Re: [PATCH 0/2] x86/boot/KASLR: Skip specified number of 1GB huge pages when do physical randomization

On 05/18/18 at 07:28pm, Baoquan He wrote: > On 05/18/18 at 10:19am, Ingo Molnar wrote: > > > > * Baoquan He <b...@redhat.com> wrote: > > > > > OK, I realized my saying above is misled because I didn't explain the > > > background clearly. Let me

Re: [PATCH 0/2] x86/boot/KASLR: Skip specified number of 1GB huge pages when do physical randomization

On 05/18/18 at 07:28pm, Baoquan He wrote: > On 05/18/18 at 10:19am, Ingo Molnar wrote: > > > > * Baoquan He wrote: > > > > > OK, I realized my saying above is misled because I didn't explain the > > > background clearly. Let me add it: > > > >

Re: [PATCH 0/2] x86/boot/KASLR: Skip specified number of 1GB huge pages when do physical randomization

On 05/18/18 at 10:19am, Ingo Molnar wrote: > > * Baoquan He <b...@redhat.com> wrote: > > > OK, I realized my saying above is misled because I didn't explain the > > background clearly. Let me add it: > > > > Previously, FJ reported the movable_no

Re: [PATCH 0/2] x86/boot/KASLR: Skip specified number of 1GB huge pages when do physical randomization

On 05/18/18 at 10:19am, Ingo Molnar wrote: > > * Baoquan He wrote: > > > OK, I realized my saying above is misled because I didn't explain the > > background clearly. Let me add it: > > > > Previously, FJ reported the movable_node issue that KASLR will

Re: [PATCH 0/2] x86/boot/KASLR: Skip specified number of 1GB huge pages when do physical randomization

On 05/18/18 at 09:00am, Ingo Molnar wrote: > > * Baoquan He <b...@redhat.com> wrote: > > > This is a regression bug fix. Luiz's team reported that 1GB huge page > > allocation will get one less 1GB page randomly when KASLR is enabled. On > > their KVM guest with

Re: [PATCH 0/2] x86/boot/KASLR: Skip specified number of 1GB huge pages when do physical randomization

On 05/18/18 at 09:00am, Ingo Molnar wrote: > > * Baoquan He wrote: > > > This is a regression bug fix. Luiz's team reported that 1GB huge page > > allocation will get one less 1GB page randomly when KASLR is enabled. On > > their KVM guest with 4GB RAM, which only

Re: [PATCH v9 04/11] arm64: kexec_file: allocate memory walking through memblock list

On 05/17/18 at 07:04pm, James Morse wrote: > Hi Baoquan, > > On 17/05/18 03:15, Baoquan He wrote: > > On 05/17/18 at 10:10am, Baoquan He wrote: > >> On 05/07/18 at 02:59pm, AKASHI Takahiro wrote: > >>> On Tue, May 01, 2018 at 06:46:09PM +0100, James Morse wro

Re: [PATCH v9 04/11] arm64: kexec_file: allocate memory walking through memblock list

On 05/17/18 at 07:04pm, James Morse wrote: > Hi Baoquan, > > On 17/05/18 03:15, Baoquan He wrote: > > On 05/17/18 at 10:10am, Baoquan He wrote: > >> On 05/07/18 at 02:59pm, AKASHI Takahiro wrote: > >>> On Tue, May 01, 2018 at 06:46:09PM +0100, James Morse wro

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

On 05/17/18 at 01:53pm, Chao Fan wrote: > On Thu, May 17, 2018 at 12:03:43PM +0800, Baoquan He wrote: > >Hi Chao, > > > >On 05/17/18 at 11:27am, Chao Fan wrote: > >> >+/* Store the number of 1GB huge pages which user specified.*/ > >> >+static unsigned

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

On 05/17/18 at 01:53pm, Chao Fan wrote: > On Thu, May 17, 2018 at 12:03:43PM +0800, Baoquan He wrote: > >Hi Chao, > > > >On 05/17/18 at 11:27am, Chao Fan wrote: > >> >+/* Store the number of 1GB huge pages which user specified.*/ > >> >+static unsigned

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

On 05/17/18 at 07:12am, damian wrote: > On Wed, 16. May 18:05, Baoquan He wrote: > > Functions parse_gb_huge_pages() and process_gb_huge_page() are introduced to > > handle conflict between KASLR and huge pages, will be used in the next > > patch. > > > > Funct

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

On 05/17/18 at 07:12am, damian wrote: > On Wed, 16. May 18:05, Baoquan He wrote: > > Functions parse_gb_huge_pages() and process_gb_huge_page() are introduced to > > handle conflict between KASLR and huge pages, will be used in the next > > patch. > > > > Funct

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

Hi Chao, On 05/17/18 at 11:27am, Chao Fan 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) > >+{ > >+char *p; > >+u64 mem_size; > >+static bool gbpage_sz

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

Hi Chao, On 05/17/18 at 11:27am, Chao Fan 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) > >+{ > >+char *p; > >+u64 mem_size; > >+static bool gbpage_sz

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, Russ and Frank, On 09/28/17 at 07:10am, Mike Travis wrote: > > > On 9/28/2017 2:01 AM, Ingo Molnar wrote: > > > > * Baoquan He <b...@redhat.com> wrote: > > > > > > > @@ -123,7 +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, Russ and Frank, On 09/28/17 at 07:10am, Mike Travis wrote: > > > On 9/28/2017 2:01 AM, Ingo Molnar wrote: > > > > * Baoquan He wrote: > > > > > > > @@ -123,7 +124,7 @@ void __init kernel_randomize_memory(void) > > > > &g

Re: [PATCH v9 04/11] arm64: kexec_file: allocate memory walking through memblock list

On 05/17/18 at 10:10am, Baoquan He wrote: > On 05/07/18 at 02:59pm, AKASHI Takahiro wrote: > > James, > > > > On Tue, May 01, 2018 at 06:46:09PM +0100, James Morse wrote: > > > Hi Akashi, > > > > > > On 25/04/18 07:26, AKASHI Takahiro wrote: >

Re: [PATCH v9 04/11] arm64: kexec_file: allocate memory walking through memblock list

On 05/17/18 at 10:10am, Baoquan He wrote: > On 05/07/18 at 02:59pm, AKASHI Takahiro wrote: > > James, > > > > On Tue, May 01, 2018 at 06:46:09PM +0100, James Morse wrote: > > > Hi Akashi, > > > > > > On 25/04/18 07:26, AKASHI Takahiro wrote: >

Re: [PATCH v9 04/11] arm64: kexec_file: allocate memory walking through memblock list

On 05/07/18 at 02:59pm, AKASHI Takahiro wrote: > James, > > On Tue, May 01, 2018 at 06:46:09PM +0100, James Morse wrote: > > Hi Akashi, > > > > On 25/04/18 07:26, AKASHI Takahiro wrote: > > > We need to prevent firmware-reserved memory regions, particularly EFI > > > memory map as well as ACPI

Re: [PATCH v9 04/11] arm64: kexec_file: allocate memory walking through memblock list

On 05/07/18 at 02:59pm, AKASHI Takahiro wrote: > James, > > On Tue, May 01, 2018 at 06:46:09PM +0100, James Morse wrote: > > Hi Akashi, > > > > On 25/04/18 07:26, AKASHI Takahiro wrote: > > > We need to prevent firmware-reserved memory regions, particularly EFI > > > memory map as well as ACPI

[PATCH 0/2] x86/boot/KASLR: Skip specified number of 1GB huge pages when do physical randomization

is appreciated. Baoquan He (2): x86/boot/KASLR: Add two functions for 1GB huge pages handling x86/boot/KASLR: Skip specified number of 1GB huge pages when do physical randomization arch/x86/boot/compressed/kaslr.c | 84 +--- 1 file changed, 79 insertions

[PATCH 0/2] x86/boot/KASLR: Skip specified number of 1GB huge pages when do physical randomization

is appreciated. Baoquan He (2): x86/boot/KASLR: Add two functions for 1GB huge pages handling x86/boot/KASLR: Skip specified number of 1GB huge pages when do physical randomization arch/x86/boot/compressed/kaslr.c | 84 +--- 1 file changed, 79 insertions

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

variable 'max_gb_huge_pages' is added to store the number. And process_gb_huge_page() is used to skip as many 1GB huge pages as possible from the passed in memory region according to the specified number. Signed-off-by: Baoquan He <b...@redhat.com> --- arch/x86/boot/compressed/kaslr.

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

variable 'max_gb_huge_pages' is added to store the number. And process_gb_huge_page() is used to skip as many 1GB huge pages as possible from the passed in memory region according to the specified number. Signed-off-by: Baoquan He --- arch/x86/boot/compressed/kaslr.c | 71

[PATCH 2/2] x86/boot/KASLR: Skip specified number of 1GB huge pages when do physical randomization

n't only handle 'mem=' and 'memmap=', but include 'hugepagesxxx' now. Signed-off-by: Baoquan He <b...@redhat.com> --- arch/x86/boot/compressed/kaslr.c | 13 - 1 file changed, 8 insertions(+), 5 deletions(-) diff --git a/arch/x86/boot/compressed/kaslr.c b/arch/x86/boot/compressed/

[PATCH 2/2] x86/boot/KASLR: Skip specified number of 1GB huge pages when do physical randomization

n't only handle 'mem=' and 'memmap=', but include 'hugepagesxxx' now. Signed-off-by: Baoquan He --- arch/x86/boot/compressed/kaslr.c | 13 - 1 file changed, 8 insertions(+), 5 deletions(-) diff --git a/arch/x86/boot/compressed/kaslr.c b/arch/x86/boot/compressed/kaslr.c index 13bd879cdc5d.

Re: [PATCH v3] x86/kexec: avoid double free_page() upon do_kexec_load() failure.

.com> > Cc: H. Peter Anvin <h...@zytor.com> > Cc: Ingo Molnar <mi...@elte.hu> > --- > arch/x86/kernel/machine_kexec_32.c | 6 +- > arch/x86/kernel/machine_kexec_64.c | 5 - > 2 files changed, 9 insertions(+), 2 deletions(-) Looks good to me, thx! Acked-by: Baoqu

Re: [PATCH v3] x86/kexec: avoid double free_page() upon do_kexec_load() failure.

xec") > Fixes: 92be3d6bdf2cb349 ("kexec/i386: allocate page table pages dynamically") > Cc: Huang Ying > Cc: H. Peter Anvin > Cc: Ingo Molnar > --- > arch/x86/kernel/machine_kexec_32.c | 6 +- > arch/x86/kernel/machine_kexec_64.c | 5 - > 2 file

Re: [PATCH v4 1/3] resource: Use list_head to link sibling resource

us a note to > help improve the system] > > url: > https://github.com/0day-ci/linux/commits/Baoquan-He/resource-Use-list_head-to-link-sibling-resource/20180507-144345 > config: powerpc-defconfig (attached as .config) > compiler: powerpc64-linux-gnu-gcc (Debian 7.2.0-11) 7.2

Re: [PATCH v4 1/3] resource: Use list_head to link sibling resource

us a note to > help improve the system] > > url: > https://github.com/0day-ci/linux/commits/Baoquan-He/resource-Use-list_head-to-link-sibling-resource/20180507-144345 > config: powerpc-defconfig (attached as .config) > compiler: powerpc64-linux-gnu-gcc (Debian 7.2.0-11) 7.2

Re: [PATCH v4 1/3] resource: Use list_head to link sibling resource

us a note to > help improve the system] > > url: > https://github.com/0day-ci/linux/commits/Baoquan-He/resource-Use-list_head-to-link-sibling-resource/20180507-144345 > config: arm-allmodconfig (attached as .config) > compiler: arm-linux-gnueabi-gcc (Debian 7.2.0-11) 7.2

Re: [PATCH v4 1/3] resource: Use list_head to link sibling resource

us a note to > help improve the system] > > url: > https://github.com/0day-ci/linux/commits/Baoquan-He/resource-Use-list_head-to-link-sibling-resource/20180507-144345 > config: arm-allmodconfig (attached as .config) > compiler: arm-linux-gnueabi-gcc (Debian 7.2.0-11) 7.2

Re: [PATCH v3 1/3] resource: Use list_head to link sibling resource

On 05/08/18 at 08:48pm, Wei Yang wrote: > On Mon, May 07, 2018 at 09:14:29AM +0800, Baoquan He wrote: > >Hi Wei Yang, > > > >On 04/26/18 at 09:18am, Wei Yang wrote: > >> On Thu, Apr 19, 2018 at 08:18:46AM +0800, Baoquan He wrote: > >> >The struct resourc

Re: [PATCH v3 1/3] resource: Use list_head to link sibling resource

On 05/08/18 at 08:48pm, Wei Yang wrote: > On Mon, May 07, 2018 at 09:14:29AM +0800, Baoquan He wrote: > >Hi Wei Yang, > > > >On 04/26/18 at 09:18am, Wei Yang wrote: > >> On Thu, Apr 19, 2018 at 08:18:46AM +0800, Baoquan He wrote: > >> >The struct resourc

[PATCH v4 1/3] resource: Use list_head to link sibling resource

of member variables of struct resource, sibling and child, are changed from 'struct resource *' to 'struct list_head'. This brings two pointers of size increase. Suggested-by: Andrew Morton <a...@linux-foundation.org> Signed-off-by: Baoquan He <b...@redhat.com> Cc: Patrik Jakobsson <

[PATCH v4 1/3] resource: Use list_head to link sibling resource

of member variables of struct resource, sibling and child, are changed from 'struct resource *' to 'struct list_head'. This brings two pointers of size increase. Suggested-by: Andrew Morton Signed-off-by: Baoquan He Cc: Patrik Jakobsson Cc: David Airlie Cc: "K. Y. Srinivasan" Cc: Hai

[PATCH v4 3/3] kexec_file: Load kernel at top of system RAM if required

. Signed-off-by: Baoquan He <b...@redhat.com> Cc: Eric Biederman <ebied...@xmission.com> Cc: Vivek Goyal <vgo...@redhat.com> Cc: Dave Young <dyo...@redhat.com> Cc: Andrew Morton <a...@linux-foundation.org> Cc: Yinghai Lu <ying...@kernel.org> Cc: ke...@lists.infrad

[PATCH v4 3/3] kexec_file: Load kernel at top of system RAM if required

. Signed-off-by: Baoquan He Cc: Eric Biederman Cc: Vivek Goyal Cc: Dave Young Cc: Andrew Morton Cc: Yinghai Lu Cc: ke...@lists.infradead.org --- kernel/kexec_file.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/kernel/kexec_file.c b/kernel/kexec_file.c index 75d8e7cf040e..7a66d9d5a534

[PATCH v4 2/3] resource: add walk_system_ram_res_rev()

_file code. Signed-off-by: Baoquan He <b...@redhat.com> Cc: Andrew Morton <a...@linux-foundation.org> Cc: Thomas Gleixner <t...@linutronix.de> Cc: Brijesh Singh <brijesh.si...@amd.com> Cc: "Jérôme Glisse" <jgli...@redhat.com> Cc: Borislav Petkov <b...@suse.de>

[PATCH v4 2/3] resource: add walk_system_ram_res_rev()

_file code. Signed-off-by: Baoquan He Cc: Andrew Morton Cc: Thomas Gleixner Cc: Brijesh Singh Cc: "Jérôme Glisse" Cc: Borislav Petkov Cc: Tom Lendacky Cc: Wei Yang --- include/linux/ioport.h | 3 +++ kernel/resource.c | 40 2 files ch

[PATCH v4 0/3] resource: Use list_head to link sibling resource

Andrew. Rewrite walk_system_ram_res_rev() after list_head is taken to link resouce siblings. Baoquan He (3): resource: Use list_head to link sibling resource resource: add walk_system_ram_res_rev() kexec_file: Load kernel at top of system RAM if required arch/microblaze/pci/pci

[PATCH v4 0/3] resource: Use list_head to link sibling resource

Andrew. Rewrite walk_system_ram_res_rev() after list_head is taken to link resouce siblings. Baoquan He (3): resource: Use list_head to link sibling resource resource: add walk_system_ram_res_rev() kexec_file: Load kernel at top of system RAM if required arch/microblaze/pci/pci

Re: [PATCH v3 1/3] resource: Use list_head to link sibling resource

Hi Wei Yang, On 04/26/18 at 09:18am, Wei Yang wrote: > On Thu, Apr 19, 2018 at 08:18:46AM +0800, Baoquan He wrote: > >The struct resource uses singly linked list to link siblings. It's not > >easy to do reverse iteration on sibling list. So replace it with list_head. >

Re: [PATCH v3 1/3] resource: Use list_head to link sibling resource

Hi Wei Yang, On 04/26/18 at 09:18am, Wei Yang wrote: > On Thu, Apr 19, 2018 at 08:18:46AM +0800, Baoquan He wrote: > >The struct resource uses singly linked list to link siblings. It's not > >easy to do reverse iteration on sibling list. So replace it with list_head. >

Re: [PATCH v3 1/3] resource: Use list_head to link sibling resource

us a note to > help improve the system] > > url: > https://github.com/0day-ci/linux/commits/Baoquan-He/resource-Use-list_head-to-link-sibling-resource/20180419-223752 > config: microblaze-mmu_defconfig (attached as .config) > compiler: microblaze-linux-gcc (GCC) 7.2

Re: [PATCH v3 1/3] resource: Use list_head to link sibling resource

us a note to > help improve the system] > > url: > https://github.com/0day-ci/linux/commits/Baoquan-He/resource-Use-list_head-to-link-sibling-resource/20180419-223752 > config: microblaze-mmu_defconfig (attached as .config) > compiler: microblaze-linux-gcc (GCC) 7.2

Re: [PATCH v3 1/3] resource: Use list_head to link sibling resource

us a note to > help improve the system] > > url: > https://github.com/0day-ci/linux/commits/Baoquan-He/resource-Use-list_head-to-link-sibling-resource/20180419-223752 > config: xtensa-common_defconfig (attached as .config) > compiler: xtensa-linux-gcc (GCC) 7.2

Re: [PATCH v3 1/3] resource: Use list_head to link sibling resource

us a note to > help improve the system] > > url: > https://github.com/0day-ci/linux/commits/Baoquan-He/resource-Use-list_head-to-link-sibling-resource/20180419-223752 > config: xtensa-common_defconfig (attached as .config) > compiler: xtensa-linux-gcc (GCC) 7.2

Re: [PATCH v3 2/3] resource: add walk_system_ram_res_rev()

On 05/04/18 at 12:16pm, Borislav Petkov wrote: > On Thu, Apr 26, 2018 at 09:22:04PM +0800, Baoquan He wrote: > > I noticed maintainers merged patches with this Message-ID, could you > > tell how to get this Message-ID? > > https://en.wikipedia.org/wiki/Message-ID thx. >

Re: [PATCH v3 2/3] resource: add walk_system_ram_res_rev()

On 05/04/18 at 12:16pm, Borislav Petkov wrote: > On Thu, Apr 26, 2018 at 09:22:04PM +0800, Baoquan He wrote: > > I noticed maintainers merged patches with this Message-ID, could you > > tell how to get this Message-ID? > > https://en.wikipedia.org/wiki/Message-ID thx. >

Re: kernel BUG at include/linux/mm.h:LINE!

On 05/01/18 at 07:10pm, Tetsuo Handa wrote: > From d54b2acf63191eba3d5052bf34fe6d26e3580ac2 Mon Sep 17 00:00:00 2001 > From: Tetsuo Handa > Date: Tue, 1 May 2018 15:36:52 +0900 > Subject: [PATCH] x86/kexec: avoid double free_page() upon do_kexec_load() >

Re: kernel BUG at include/linux/mm.h:LINE!

On 05/01/18 at 07:10pm, Tetsuo Handa wrote: > From d54b2acf63191eba3d5052bf34fe6d26e3580ac2 Mon Sep 17 00:00:00 2001 > From: Tetsuo Handa > Date: Tue, 1 May 2018 15:36:52 +0900 > Subject: [PATCH] x86/kexec: avoid double free_page() upon do_kexec_load() > failure. > > syzbot is reporting crashes

Re: [PATCH 1/2] kdump/x86: crashkernel=X try to reserve below 896M first then below 4G and MAXMEM

ent kdump only fixes. > > Other than above, the patches are just same. Thanks to work on this. Looks good to me. ACK Acked-by: Baoquan He <b...@redhat.com> Thanks Baoquan > ___ > kexec mailing list > ke...@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/kexec

Re: [PATCH 1/2] kdump/x86: crashkernel=X try to reserve below 896M first then below 4G and MAXMEM

ent kdump only fixes. > > Other than above, the patches are just same. Thanks to work on this. Looks good to me. ACK Acked-by: Baoquan He Thanks Baoquan > ___ > kexec mailing list > ke...@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/kexec

Re: [PATCH v3 2/3] resource: add walk_system_ram_res_rev()

On 04/26/18 at 01:09pm, Borislav Petkov wrote: > On Thu, Apr 26, 2018 at 04:56:49PM +0800, Baoquan He wrote: > > Sorry for that, I just ran scripts/get_maintainer.pl to get expert's > > name and added them into each patch. The reason this change is made is > > in patch 3/3

Re: [PATCH v3 2/3] resource: add walk_system_ram_res_rev()

On 04/26/18 at 01:09pm, Borislav Petkov wrote: > On Thu, Apr 26, 2018 at 04:56:49PM +0800, Baoquan He wrote: > > Sorry for that, I just ran scripts/get_maintainer.pl to get expert's > > name and added them into each patch. The reason this change is made is > > in patch 3/3

Re: [PATCH v3 2/3] resource: add walk_system_ram_res_rev()

Sorry to all reviewers, I had a redhat urgent issue, this patchset discussing is delayed. On 04/19/18 at 12:07pm, Borislav Petkov wrote: > On Thu, Apr 19, 2018 at 08:18:47AM +0800, Baoquan He wrote: > > This function, being a variant of walk_system_ram_res() introduced in > > comm

Re: [PATCH v3 2/3] resource: add walk_system_ram_res_rev()

Sorry to all reviewers, I had a redhat urgent issue, this patchset discussing is delayed. On 04/19/18 at 12:07pm, Borislav Petkov wrote: > On Thu, Apr 19, 2018 at 08:18:47AM +0800, Baoquan He wrote: > > This function, being a variant of walk_system_ram_res() introduced in > > comm

[PATCH v3 1/3] resource: Use list_head to link sibling resource

resource, sibling and child, are changed from 'struct resource *' to 'struct list_head'. This brings two pointers of size increase. Suggested-by: Andrew Morton <a...@linux-foundation.org> Signed-off-by: Baoquan He <b...@redhat.com> Cc: Patrik Jakobsson <patrik.r.jakobs...@gmail.com> Cc:

[PATCH v3 1/3] resource: Use list_head to link sibling resource

resource, sibling and child, are changed from 'struct resource *' to 'struct list_head'. This brings two pointers of size increase. Suggested-by: Andrew Morton Signed-off-by: Baoquan He Cc: Patrik Jakobsson Cc: David Airlie Cc: "K. Y. Srinivasan" Cc: Haiyang Zhang Cc: Stephen Hemminger

[PATCH v3 3/3] kexec_file: Load kernel at top of system RAM if required

, call the newly added walk_system_ram_res_rev() to find memory region from top to down to load kernel. Signed-off-by: Baoquan He <b...@redhat.com> Cc: Eric Biederman <ebied...@xmission.com> Cc: Vivek Goyal <vgo...@redhat.com> Cc: Dave Young <dyo...@redhat.com> Cc: A

[PATCH v3 3/3] kexec_file: Load kernel at top of system RAM if required

, call the newly added walk_system_ram_res_rev() to find memory region from top to down to load kernel. Signed-off-by: Baoquan He Cc: Eric Biederman Cc: Vivek Goyal Cc: Dave Young Cc: Andrew Morton Cc: Yinghai Lu Cc: ke...@lists.infradead.org --- kernel/kexec_file.c | 2 ++ 1 file changed, 2

[PATCH v3 0/3] resource: Use list_head to link sibling resource

ers of size increase, mention this in git log to make it more specifically, Rob suggested this. v1->v2: Use list_head instead to link resource siblings. This is suggested by Andrew. Rewrite walk_system_ram_res_rev() after list_head is taken to link resouce siblings. Baoquan

[PATCH v3 0/3] resource: Use list_head to link sibling resource

ers of size increase, mention this in git log to make it more specifically, Rob suggested this. v1->v2: Use list_head instead to link resource siblings. This is suggested by Andrew. Rewrite walk_system_ram_res_rev() after list_head is taken to link resouce siblings. Baoquan

[PATCH v3 2/3] resource: add walk_system_ram_res_rev()

_file code. Signed-off-by: Baoquan He <b...@redhat.com> Cc: Andrew Morton <a...@linux-foundation.org> Cc: Thomas Gleixner <t...@linutronix.de> Cc: Brijesh Singh <brijesh.si...@amd.com> Cc: "Jérôme Glisse" <jgli...@redhat.com> Cc: Borislav Petkov <b...@suse.de>

[PATCH v3 2/3] resource: add walk_system_ram_res_rev()

_file code. Signed-off-by: Baoquan He Cc: Andrew Morton Cc: Thomas Gleixner Cc: Brijesh Singh Cc: "Jérôme Glisse" Cc: Borislav Petkov Cc: Tom Lendacky Cc: Wei Yang --- include/linux/ioport.h | 3 +++ kernel/resource.c | 40 2 files ch

Re: [PATCH v1 0/2] kexec: Remove "weak" annotations from headers

On 04/17/18 at 09:07am, Bjorn Helgaas wrote: > On Fri, Apr 13, 2018 at 05:29:08PM +0800, Baoquan He wrote: > > Hi Bjorn, > > > > There are changes I have made to solve 5-level conflict with > > kexec/kdump and also interface unification task, they will invo

Re: [PATCH v1 0/2] kexec: Remove "weak" annotations from headers

On 04/17/18 at 09:07am, Bjorn Helgaas wrote: > On Fri, Apr 13, 2018 at 05:29:08PM +0800, Baoquan He wrote: > > Hi Bjorn, > > > > There are changes I have made to solve 5-level conflict with > > kexec/kdump and also interface unification task, they will invo

Re: [PATCH v3 4/4] mm/sparse: Optimize memmap allocation during sparse_init()

Hi Dave, Sorry for late reply. On 04/11/18 at 08:48am, Dave Hansen wrote: > On 04/08/2018 01:20 AM, Baoquan He wrote: > > On 04/06/18 at 07:50am, Dave Hansen wrote: > >> The code looks fine to me. It's a bit of a shame that there's no > >> verification to ensure

Re: [PATCH v3 4/4] mm/sparse: Optimize memmap allocation during sparse_init()

Hi Dave, Sorry for late reply. On 04/11/18 at 08:48am, Dave Hansen wrote: > On 04/08/2018 01:20 AM, Baoquan He wrote: > > On 04/06/18 at 07:50am, Dave Hansen wrote: > >> The code looks fine to me. It's a bit of a shame that there's no > >> verification to ensure

Re: [PATCH v1 0/2] kexec: Remove "weak" annotations from headers

Hi Bjorn, There are changes I have made to solve 5-level conflict with kexec/kdump and also interface unification task, they will involve x86 64 only changes on these functions, I don't think we need remove them if without any obvious impact or error reported. Thanks Baoquan On 04/13/18 at

Re: [PATCH v1 0/2] kexec: Remove "weak" annotations from headers

Hi Bjorn, There are changes I have made to solve 5-level conflict with kexec/kdump and also interface unification task, they will involve x86 64 only changes on these functions, I don't think we need remove them if without any obvious impact or error reported. Thanks Baoquan On 04/13/18 at

Re: [PATCH v3 1/3] resource: Use list_head to link resource sibling

Hi Rob, Thanks a lot for looking into this and involve Nico to this thread! On 04/09/18 at 09:49am, Rob Herring wrote: > +Nico who has been working on tinification of the kernel. > > On Mon, Apr 9, 2018 at 4:08 AM, Baoquan He <b...@redhat.com> wrote: > > The struct resour

Re: [PATCH v3 1/3] resource: Use list_head to link resource sibling

Hi Rob, Thanks a lot for looking into this and involve Nico to this thread! On 04/09/18 at 09:49am, Rob Herring wrote: > +Nico who has been working on tinification of the kernel. > > On Mon, Apr 9, 2018 at 4:08 AM, Baoquan He wrote: > > The struct resource uses singly link

Re: [PATCH v3 1/3] resource: Use list_head to link resource sibling

On 04/09/18 at 07:34pm, Dan Williams wrote: > On Mon, Apr 9, 2018 at 7:10 PM, Baoquan He <b...@redhat.com> wrote: > > On 04/09/18 at 08:38am, Dan Williams wrote: > >> On Mon, Apr 9, 2018 at 2:08 AM, Baoquan He <b...@redhat.com> wrote: > >> > The struc

Re: [PATCH v3 1/3] resource: Use list_head to link resource sibling

On 04/09/18 at 07:34pm, Dan Williams wrote: > On Mon, Apr 9, 2018 at 7:10 PM, Baoquan He wrote: > > On 04/09/18 at 08:38am, Dan Williams wrote: > >> On Mon, Apr 9, 2018 at 2:08 AM, Baoquan He wrote: > >> > The struct resource uses singly linked list to link siblin

Re: [PATCH v3 1/3] resource: Use list_head to link resource sibling

On 04/09/18 at 08:38am, Dan Williams wrote: > On Mon, Apr 9, 2018 at 2:08 AM, Baoquan He <b...@redhat.com> wrote: > > The struct resource uses singly linked list to link siblings. It's not > > easy to do reverse iteration on sibling list. So replace it with list_head. > &g

Re: [PATCH v3 1/3] resource: Use list_head to link resource sibling

On 04/09/18 at 08:38am, Dan Williams wrote: > On Mon, Apr 9, 2018 at 2:08 AM, Baoquan He wrote: > > The struct resource uses singly linked list to link siblings. It's not > > easy to do reverse iteration on sibling list. So replace it with list_head. > > > > And c

Re: [PATCH v3 2/4] mm/sparsemem: Defer the ms->section_mem_map clearing

On 04/09/18 at 09:02am, Dave Hansen wrote: > On 04/07/2018 11:50 PM, Baoquan He wrote: > >> Should the " = 0" instead be clearing SECTION_MARKED_PRESENT or > >> something? That would make it easier to match the code up with the code > >> that it is eff

Re: [PATCH v3 2/4] mm/sparsemem: Defer the ms->section_mem_map clearing

On 04/09/18 at 09:02am, Dave Hansen wrote: > On 04/07/2018 11:50 PM, Baoquan He wrote: > >> Should the " = 0" instead be clearing SECTION_MARKED_PRESENT or > >> something? That would make it easier to match the code up with the code > >> that it is eff

Re: [PATCH v3 1/3] resource: Use list_head to link resource sibling

, sibling and child, are changed from 'struct resource *' to 'struct list_head'. Kernel size will increase because of those statically defined struct resource instances. Signed-off-by: Baoquan He <b...@redhat.com> --- v2->v3: Make sibling() and first_child() global so that they can be cal

Re: [PATCH v3 1/3] resource: Use list_head to link resource sibling

, sibling and child, are changed from 'struct resource *' to 'struct list_head'. Kernel size will increase because of those statically defined struct resource instances. Signed-off-by: Baoquan He --- v2->v3: Make sibling() and first_child() global so that they can be called out of kernel/resourc

Re: [PATCH v3 4/4] mm/sparse: Optimize memmap allocation during sparse_init()

On 04/08/18 at 04:20pm, Baoquan He wrote: > On 04/06/18 at 07:50am, Dave Hansen wrote: > > I'm having a really hard time tying all the pieces back together. Let > > me give it a shot and you can tell me where I go wrong. > > > > On 02/27/2018 07:26 PM, Baoquan He

Re: [PATCH v3 4/4] mm/sparse: Optimize memmap allocation during sparse_init()

On 04/08/18 at 04:20pm, Baoquan He wrote: > On 04/06/18 at 07:50am, Dave Hansen wrote: > > I'm having a really hard time tying all the pieces back together. Let > > me give it a shot and you can tell me where I go wrong. > > > > On 02/27/2018 07:26 PM, Baoquan He

Re: [PATCH v2 1/3] resource: Use list_head to link sibling resource

te to > help improve the system] > > url: > https://github.com/0day-ci/linux/commits/Baoquan-He/resource-Use-list_head-to-link-sibling-resource/20180408-110108 > config: sparc-defconfig (attached as .config) > compiler: sparc-linux-gcc (GCC) 7.2.0 > reproduce: >

Re: [PATCH v2 1/3] resource: Use list_head to link sibling resource

te to > help improve the system] > > url: > https://github.com/0day-ci/linux/commits/Baoquan-He/resource-Use-list_head-to-link-sibling-resource/20180408-110108 > config: sparc-defconfig (attached as .config) > compiler: sparc-linux-gcc (GCC) 7.2.0 > reproduce: >

Re: [PATCH v2 1/3] resource: Use list_head to link sibling resource

tree, please drop us a note to > help improve the system] > > url: > https://github.com/0day-ci/linux/commits/Baoquan-He/resource-Use-list_head-to-link-sibling-resource/20180408-110108 > config: parisc-c3000_defconfig (attached as .config) > compiler: hppa-linux-gnu-

Re: [PATCH v2 1/3] resource: Use list_head to link sibling resource

tree, please drop us a note to > help improve the system] > > url: > https://github.com/0day-ci/linux/commits/Baoquan-He/resource-Use-list_head-to-link-sibling-resource/20180408-110108 > config: parisc-c3000_defconfig (attached as .config) > compiler: hppa-linux-gnu-

Re: [PATCH v3 4/4] mm/sparse: Optimize memmap allocation during sparse_init()

On 04/06/18 at 07:50am, Dave Hansen wrote: > I'm having a really hard time tying all the pieces back together. Let > me give it a shot and you can tell me where I go wrong. > > On 02/27/2018 07:26 PM, Baoquan He wrote: > > In sparse_init(), two temporary pointer arrays, usem

Re: [PATCH v3 4/4] mm/sparse: Optimize memmap allocation during sparse_init()

On 04/06/18 at 07:50am, Dave Hansen wrote: > I'm having a really hard time tying all the pieces back together. Let > me give it a shot and you can tell me where I go wrong. > > On 02/27/2018 07:26 PM, Baoquan He wrote: > > In sparse_init(), two temporary pointer arrays, usem

Re: [PATCH v3 2/4] mm/sparsemem: Defer the ms->section_mem_map clearing

Hi Dave, Thanks a lot for your careful reviewing! On 04/06/18 at 07:23am, Dave Hansen wrote: > On 02/27/2018 07:26 PM, Baoquan He wrote: > > In sparse_init(), if CONFIG_SPARSEMEM_ALLOC_MEM_MAP_TOGETHER=y, system > > will allocate one continuous memory chunk for mem m

Re: [PATCH v3 2/4] mm/sparsemem: Defer the ms->section_mem_map clearing

Hi Dave, Thanks a lot for your careful reviewing! On 04/06/18 at 07:23am, Dave Hansen wrote: > On 02/27/2018 07:26 PM, Baoquan He wrote: > > In sparse_init(), if CONFIG_SPARSEMEM_ALLOC_MEM_MAP_TOGETHER=y, system > > will allocate one continuous memory chunk for mem m

[PATCH v2 2/3] resource: add walk_system_ram_res_rev()

_file code. Signed-off-by: Baoquan He <b...@redhat.com> Cc: Andrew Morton <a...@linux-foundation.org> Cc: Thomas Gleixner <t...@linutronix.de> Cc: Brijesh Singh <brijesh.si...@amd.com> Cc: "Jérôme Glisse" <jgli...@redhat.com> Cc: Borislav Petkov <b...@suse.de>

[PATCH v2 3/3] kexec_file: Load kernel at top of system RAM if required

, call the newly added walk_system_ram_res_rev() to find memory region from top to down to load kernel. Signed-off-by: Baoquan He <b...@redhat.com> Cc: Eric Biederman <ebied...@xmission.com> Cc: Vivek Goyal <vgo...@redhat.com> Cc: Dave Young <dyo...@redhat.com> Cc: A

<    3   4   5   6   7   8   9   10   11   12   >