Re: [PATCH v3 1/4] kaslr: add immovable_mem=nn[KMG]@ss[KMG] to specify extracting memory

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

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] 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

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

[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

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. >

[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 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 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 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 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 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 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 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 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 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 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: microblaze-mmu_defconfig (attached as .config) > compiler: microblaze-linux-gcc (GCC) 7.2

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

[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 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.

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 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

[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 <b...@redhat.com> --- mm/sparse.c | 7 +++ 1 file changed, 7 insertions(+) diff --git a/mm/sparse.c b/mm/sparse.c index 62eef2

[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 <b...@redhat.com> --- mm/sparse.c | 10 +++--- 1 file changed, 7 insertions(+), 3 deletions(-) diff --git a/mm/sparse.c b/mm/sparse.c index 3d6972

[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

Re: [PATCH] kdump: add default crashkernel reserve kernel config options

On 05/24/18 at 08:57am, Petr Tesarik wrote: > On Thu, 24 May 2018 09:49:05 +0800 > Dave Young wrote: > > > Hi Petr, > > > > On 05/23/18 at 10:22pm, Petr Tesarik wrote: > >[...] > > > In short, if one size fits none, what good is it to hardcode that "one > > > size" into the

Re: [PATCH] kdump: add default crashkernel reserve kernel config options

On 05/24/18 at 03:56pm, Dave Young wrote: > > > > Instead of setting aside a significant chunk of memory nobody can use, > > > > [...] reserve a significant chunk of memory that the kernel is prevented > > > > from using [...], but applications are free to use it. > > > > > > That works great,

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 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 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 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

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 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 v4 3/4] mm/sparse: Add a new parameter 'data_unit_size' for alloc_usemap_and_memmap

On 06/08/18 at 09:13am, Dave Hansen wrote: > On 06/08/2018 08:17 AM, Baoquan He wrote: > > > > Then inside alloc_usemap_and_memmap(), For each node, we get how many > > present sections on this node, call hook alloc_func(). Then we update > > the pointer to point at a

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

On 06/07/18 at 03:48pm, Dave Hansen wrote: > On 05/21/2018 03:15 AM, Baoquan He wrote: > > It's used to pass the size of map data unit into alloc_usemap_and_memmap, > > and is preparation for next patch. > > This is the "what", but not the "why".

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

On 06/08/18 at 07:20am, Dave Hansen wrote: > On 06/07/2018 11:27 PM, Baoquan He wrote: > > In alloc_usemap_and_memmap(), it will call > > sparse_early_usemaps_alloc_node() or sparse_early_mem_maps_alloc_node() > > to allocate usemap and memmap for each node and install the

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

On 06/07/18 at 03:46pm, Dave Hansen wrote: > > @@ -297,8 +298,8 @@ void __init sparse_mem_maps_populate_node(struct page > > **map_map, > > if (!present_section_nr(pnum)) > > continue; > > > > - map_map[pnum] = sparse_mem_map_populate(pnum, nodeid,

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

On 06/08/18 at 03:28pm, Baoquan He wrote: > On 06/07/18 at 03:46pm, Dave Hansen wrote: > > > @@ -297,8 +298,8 @@ void __init sparse_mem_maps_populate_node(struct page > > > **map_map, > > > if (!present_section_nr(pnum)) > > > co

Re: [PATCH] slab: Clean up the code comment in slab kmem_cache struct

On 06/06/18 at 11:48pm, Christopher Lameter wrote: > On Wed, 6 Jun 2018, Baoquan He wrote: > > > I am back porting Thomas's sl[a|u]b freelist randomization feature to > > our distros, need go through slab code for better understanding. From > > git log histor

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

On 05/24/18 at 01:50pm, Mike Travis wrote: > Hi Baoquan, > > My apologies for my delay, we are going through a network reconfig so mail > to me was not available for a bit. Comments below... Not at all. > > > > > > > Is there any chance we can get the size of MMIOH region before mm > > > > >

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

On 05/23/18 at 03:10pm, Luiz Capitulino wrote: > On Fri, 18 May 2018 19:28:36 +0800 > Baoquan He <b...@redhat.com> wrote: > > > > Note that it's not KASLR specific: if we had some other kernel feature > > > that tried > > > to allocate a piece of memor

Re: [PATCH] slab: Clean up the code comment in slab kmem_cache struct

On 06/05/18 at 05:04pm, Christopher Lameter wrote: > On Sun, 3 Jun 2018, Baoquan He wrote: > > > diff --git a/include/linux/slab_def.h b/include/linux/slab_def.h > > index d9228e4d0320..3485c58cfd1c 100644 > > --- a/include/linux/slab_def.h > > +++ b/include/linux/

[PATCH] slab: Clean up the code comment in slab kmem_cache struct

In commit 3b0efdfa1e7("mm, sl[aou]b: Extract common fields from struct kmem_cache") The variable 'obj_size' was moved above, however the related code comment is not updated accordingly. Do it here. Signed-off-by: Baoquan He --- include/linux/slab_def.h | 7 --- 1 file

Re: [PATCH v2 2/2] mm/sparse: start using sparse_init_nid(), and remove old code

On 06/29/18 at 11:09pm, Pavel Tatashin wrote: > Change sprase_init() to only find the pnum ranges that belong to a specific > node and call sprase_init_nid() for that range from sparse_init(). > > Delete all the code that became obsolete with this change. > void __init sparse_init(void) > { > -

Re: [PATCH v2 2/2] mm/sparse: start using sparse_init_nid(), and remove old code

On 07/01/18 at 09:46pm, Pavel Tatashin wrote: > ~~~ > > Here, node id passed to sparse_init_nid() should be 'nid_begin', but not > > 'nid'. When you found out the current section's 'nid' is diferent than > > 'nid_begin', handle node 'nid_begin', then start to next node

Re: [PATCH v3 1/2] mm/sparse: add sparse_init_nid()

On 07/01/18 at 10:18pm, Pavel Tatashin wrote: > > Here, I think it might be not right to jump to 'failed' directly if one > > section of the node failed to populate memmap. I think the original code > > is only skipping the section which memmap failed to populate by marking > > it as not present

Re: [PATCH v3 1/2] mm/sparse: add sparse_init_nid()

On 07/01/18 at 10:43pm, Pavel Tatashin wrote: > On Sun, Jul 1, 2018 at 10:31 PM Baoquan He wrote: > > > > On 07/01/18 at 10:18pm, Pavel Tatashin wrote: > > > > Here, I think it might be not right to jump to 'failed' directly if one > > > > section of the

Re: [PATCH v3 1/2] mm/sparse: add sparse_init_nid()

On 07/01/18 at 10:04pm, Pavel Tatashin wrote: > +/* > + * Initialize sparse on a specific node. The node spans [pnum_begin, > pnum_end) > + * And number of present sections in this node is map_count. > + */ > +void __init sparse_init_nid(int nid, unsigned long pnum_begin, > +

Re: [PATCH v3 1/2] mm/sparse: add sparse_init_nid()

On 07/01/18 at 11:03pm, Pavel Tatashin wrote: > > Ah, yes, I misunderstood it, sorry for that. > > > > Then I have only one concern, for vmemmap case, if one section doesn't > > succeed to populate its memmap, do we need to skip all the remaining > > sections in that node? > > Yes, in

Re: [PATCH v3 1/2] mm/sparse: add sparse_init_nid()

On 07/02/18 at 11:14am, Baoquan He wrote: > On 07/01/18 at 11:03pm, Pavel Tatashin wrote: > > > Ah, yes, I misunderstood it, sorry for that. > > > > > > Then I have only one concern, for vmemmap case, if one section doesn't > > > succeed to populate its memma

Re: [PATCH v3 1/2] mm/sparse: add sparse_init_nid()

On 07/01/18 at 11:28pm, Pavel Tatashin wrote: > > > So, on the first failure, we even stop trying to populate other > > > sections. No more memory to do so. > > > > This is the thing I worry about. In old sparse_mem_maps_populate_node() > > you can see, when not present or failed to populate, just

Re: [PATCH v2 2/2] mm/sparse: start using sparse_init_nid(), and remove old code

Hi Pavel, On 06/29/18 at 11:09pm, Pavel Tatashin wrote: > Change sprase_init() to only find the pnum ranges that belong to a specific > node and call sprase_init_nid() for that range from sparse_init(). > > Delete all the code that became obsolete with this change. > @@ -617,87 +491,24 @@ void

Re: [PATCH v3 1/2] mm/sparse: add sparse_init_nid()

Hi Pavel, Thanks for your quick fix. You might have missed another comment to v2 patch 1/2 which is at the bottom. On 07/01/18 at 10:04pm, Pavel Tatashin wrote: > +/* > + * Initialize sparse on a specific node. The node spans [pnum_begin, > pnum_end) > + * And number of present sections in this

Re: [PATCH v2 1/2] mm/sparse: add sparse_init_nid()

On 06/29/18 at 11:09pm, Pavel Tatashin wrote: > sparse_init() requires to temporary allocate two large buffers: > usemap_map and map_map. Baoquan He has identified that these buffers are so > large that Linux is not bootable on small memory machines, such as a kdump > boot. These t

Re: [RFC PATCH 0/4] x86/boot/KASLR: Parse ACPI table and limit kaslr in immovable memory.

Hi Chao, On 06/12/18 at 04:10pm, Chao Fan wrote: > *** Issues need be discussed > There are several issues I am not quite sure, please help review and > give suggestions: > > 1) In PATCH 1, I copy the structures and functions from ACPI head file, >so that ACPI head file will never been used

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

Hi Pavel, On 06/27/18 at 01:47pm, Pavel Tatashin wrote: > This work made me think why do we even have > CONFIG_SPARSEMEM_ALLOC_MEM_MAP_TOGETHER ? This really should be the > default behavior for all systems. Yet, it is enabled only on x86_64. > We could clean up an already messy sparse.c if we

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

On 06/27/18 at 11:54am, Oscar Salvador wrote: > On Wed, Jun 27, 2018 at 09:31:14AM +0800, Baoquan He wrote: > > In sparse_init(), if CONFIG_SPARSEMEM_ALLOC_MEM_MAP_TOGETHER=y, system > > will allocate one continuous memory chunk for mem maps on one node and > > populate the

Re: [PATCH] x86/mm: don't free p4d table when it is folded at runtime.

Hi Kirill, On 06/25/18 at 02:50pm, Kirill A. Shutemov wrote: > On Mon, Jun 25, 2018 at 01:24:27PM +0300, Andrey Ryabinin wrote: > > When the p4d page table layer is folded at runtime, the p4d_free() > > should do nothing, the same as in . > > > > It seems this bug should cause double-free in

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

consistent with the current huge page implementation. v1->v2: There are several code style problems and typos which were pointed out by Ingo, fix them in this patchset. Baoquan He (2): x86/boot/KASLR: Add two functions for 1GB huge pages handling x86/boot/KASLR: Skip specified number of 1GB h

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

global variable 'max_gb_huge_pages' is added to store the number. And process_gb_huge_pages() 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 | 83

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

many 1GB huge pages are specified. Then try to skip the specified number of 1GB huge pages when decide which memory region kernel can be randomized into. And also change the name of handle_mem_memmap() as handle_mem_options() since it handles not only 'mem=' and 'memmap=', but also 'hugepagesxxx' now. Si

[PATCH v5 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 f13f2723950a..6314303130b0 100644

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

On 06/27/18 at 09:31am, Baoquan He wrote: > This is v4 post. V3 can be found here: > https://lkml.org/lkml/2018/2/27/928 Sorry, forgot updating this part. This is v5 post, v4 can be found here: http://lkml.kernel.org/r/20180521101555.25610-1-...@redhat.com > > V1 can be found h

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

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/sparse: Optimize memmap al

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

as things get consumed. But, it knows only the quantity of objects consumed and not the type. This effectively tells it enough about the type to let it update the pointer as objects are consumed. Signed-off-by: Baoquan He --- mm/sparse.c | 10 +++--- 1 file changed, 7 insertions(+), 3

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

-by: Baoquan He Signed-off-by: Baoquan He --- mm/sparse-vmemmap.c | 5 +++-- mm/sparse.c | 43 ++- 2 files changed, 37 insertions(+), 11 deletions(-) diff --git a/mm/sparse-vmemmap.c b/mm/sparse-vmemmap.c index 640e68f8324b..a98ec2fb6915 100644 ---

[PATCH v5 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] x86/mm: don't free p4d table when it is folded at runtime.

On 06/26/18 at 01:00pm, Kirill A. Shutemov wrote: > On Tue, Jun 26, 2018 at 07:40:49AM +0000, Baoquan He wrote: > > Hi Kirill, > > > > On 06/25/18 at 02:50pm, Kirill A. Shutemov wrote: > > > On Mon, Jun 25, 2018 at 01:24:27PM +0300, Andrey Ryabinin wrote: > &g

Re: [RFC PATCH 0/4] x86/boot/KASLR: Parse ACPI table and limit kaslr in immovable memory.

On 07/03/18 at 09:32am, Chao Fan wrote: > On Mon, Jul 02, 2018 at 08:18:55PM +0800, Baoquan He wrote: > >Hi Chao, > > > >On 06/12/18 at 04:10pm, Chao Fan wrote: > >> *** Issues need be discussed > >> There are several issues I am not quite sure, pleas

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: 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() >

[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

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 >

[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

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

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 <b...@redhat.com> --- ar

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

le_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 <b...@redhat.com> --- arch/x86/include/asm/io_apic.h | 3 ++- arch/x86/kernel/apic/io_apic.c | 12

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

tdown 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 <b...@redhat.com> --- arch

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

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 <b...@redhat.com> --- ar

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

nsistent 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/apic: Clean up the

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

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 this

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

y_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 <b...@redhat.com> --- arch/x86/include/asm/io_apic.h | 3 ++- arch/x86/kernel/apic/io_apic.c | 12 arch/x8

[PATCH 1/3] x86/apic: Set up through LAPIC on boot CPU's LINT0 if ioapic is disabled to kexec/kdump kernel

tdown 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 <b...@redhat.com> ---

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

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 > > >

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

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

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

Hi 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

Re: [PATCH v5 1/4] kaslr: add immovable_mem=nn[KMG]@ss[KMG] to specify extracting memory

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

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

l 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 the names of leg

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

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

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

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

Re: [PATCH v7 4/5] x86/KASLR: Skip memory mirror handling if movable_node specified

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

Re: [PATCH v7 3/5] x86/KASLR: Give a warning if movable_node specified without kaslr_mem=

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

Re: [PATCH v7 3/5] x86/KASLR: Give a warning if movable_node specified without kaslr_mem=

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

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

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

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

On 01/19/18 at 04:06pm, Dou Liyang wrote: > > > At 01/19/2018 03:21 PM, Baoquan He wrote: > > On 01/19/18 at 02:42pm, Dou Liyang wrote: > > > Hi Baoquan, > > > > > > At 01/05/2018 12:39 PM, Baoquan He wrote: > > > [...] > > > &

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

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

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