Re: [PATCH v12 1/5] x86/boot: Add get_acpi_rsdp() to parse RSDP in cmdline from KEXEC

2018-12-06 Thread Baoquan He
On 12/07/18 at 10:10am, Baoquan He wrote: > Hi, > > On 11/29/18 at 04:10pm, Masayoshi Mizuma wrote: > > > diff --git a/arch/x86/boot/compressed/misc.c > > > b/arch/x86/boot/compressed/misc.c > > > index 8dd1d5ccae58..e51713fe3add 100644 > > > ---

Re: [PATCH v12 1/5] x86/boot: Add get_acpi_rsdp() to parse RSDP in cmdline from KEXEC

2018-12-06 Thread Baoquan He
ie may not be used together > make[1]: *** [scripts/Makefile.build:294: arch/x86/boot/compressed/misc.o] > Error 1 > make: *** [Makefile:1715: arch/x86/boot/compressed/misc.o] Error 2 I have met this issue when change code in boot/compressed/kaslr.c. I remember Ingo merged my patch and found

Re: [PATCHv3 1/3] x86/mm: Move LDT remap out of KASLR region on 5-level paging

2018-12-02 Thread Baoquan He
Hi Kirill, On 11/23/18 at 06:58pm, Kirill A. Shutemov wrote: > > Thanks for this fix. One small concern is whether we can put LDT > > remap in other place, e.g shrink KASAN area and save one pgd size for > > it, Just from Redhat's enterprise relase point of view, we don't > > enable CONFIG_KASAN,

Re: Memory hotplug softlock issue

2018-11-20 Thread Baoquan He
On 11/20/18 at 03:05pm, Michal Hocko wrote: > > Yes, I applied Hugh's patch 8 hours ago, then our QE Ping operated on > > that machine, after many times of hot removing/adding, the endless > > looping during mirgrating is not seen any more. The test result for > > Hugh's patch is positive. I even

Re: Memory hotplug softlock issue

2018-11-20 Thread Baoquan He
Hi, On 11/20/18 at 02:38pm, Vlastimil Babka wrote: > On 11/20/18 6:44 AM, Hugh Dickins wrote: > > [PATCH] mm: put_and_wait_on_page_locked() while page is migrated > > > > We have all assumed that it is essential to hold a page reference while > > waiting on a page lock: partly to guarantee that

Re: Memory hotplug softlock issue

2018-11-19 Thread Baoquan He
On 11/19/18 at 09:59pm, Michal Hocko wrote: > On Mon 19-11-18 12:34:09, Hugh Dickins wrote: > > I'm glad that I delayed, what I had then (migration_waitqueue instead > > of using page_waitqueue) was not wrong, but what I've been using the > > last couple of months is rather better (and can be put

Re: Memory hotplug softlock issue

2018-11-16 Thread Baoquan He
On 11/16/18 at 10:14am, Michal Hocko wrote: > Could you try to apply this debugging patch on top please? It will dump > stack trace for each reference count elevation for one page that fails > to migrate after multiple passes. Thanks, applied and fixed two code issues. The dmesg has been sent to

Re: Memory hotplug softlock issue

2018-11-15 Thread Baoquan He
On 11/15/18 at 03:32pm, Michal Hocko wrote: > On Thu 15-11-18 21:38:40, Baoquan He wrote: > > On 11/15/18 at 02:19pm, Michal Hocko wrote: > > > On Thu 15-11-18 21:12:11, Baoquan He wrote: > > > > On 11/15/18 at 09:30am, Michal Hocko wrote: > > > [...] >

Re: [RFC PATCH 2/5] mm: lower the printk loglevel for __dump_page messages

2018-11-15 Thread Baoquan He
On 11/07/18 at 11:18am, Michal Hocko wrote: > From: Michal Hocko > > __dump_page messages use KERN_EMERG resp. KERN_ALERT loglevel (this is > the case since 2004). Most callers of this function are really detecting > a critical page state and BUG right after. On the other hand the > function is

Re: Memory hotplug softlock issue

2018-11-15 Thread Baoquan He
On 11/15/18 at 03:32pm, Michal Hocko wrote: > On Thu 15-11-18 21:38:40, Baoquan He wrote: > > On 11/15/18 at 02:19pm, Michal Hocko wrote: > > > On Thu 15-11-18 21:12:11, Baoquan He wrote: > > > > On 11/15/18 at 09:30am, Michal Hocko wrote: > > > [...] >

Re: Memory hotplug softlock issue

2018-11-15 Thread Baoquan He
On 11/15/18 at 02:19pm, Michal Hocko wrote: > On Thu 15-11-18 21:12:11, Baoquan He wrote: > > On 11/15/18 at 09:30am, Michal Hocko wrote: > [...] > > > It would be also good to find out whether this is fs specific. E.g. does > > > it make any difference if you use a

Re: Memory hotplug softlock issue

2018-11-15 Thread Baoquan He
On 11/15/18 at 02:19pm, Michal Hocko wrote: > On Thu 15-11-18 21:12:11, Baoquan He wrote: > > On 11/15/18 at 09:30am, Michal Hocko wrote: > [...] > > > It would be also good to find out whether this is fs specific. E.g. does > > > it make any difference if you use a

Re: Memory hotplug softlock issue

2018-11-15 Thread Baoquan He
On 11/15/18 at 09:30am, Michal Hocko wrote: > On Thu 15-11-18 15:53:56, Baoquan He wrote: > > On 11/15/18 at 08:30am, Michal Hocko wrote: > > > On Thu 15-11-18 13:10:34, Baoquan He wrote: > > > > On 11/14/18 at 04:00pm, Michal Hocko wrote: > > > > &g

Re: Memory hotplug softlock issue

2018-11-15 Thread Baoquan He
On 11/15/18 at 10:42am, David Hildenbrand wrote: > I am wondering why it is always the last memory block of that device > (and even that node). Coincidence? I remember one or two times it's the last 6G or 4G which stall there, the size of memory block is 2G. But most of time it's the last memory

Re: Memory hotplug softlock issue

2018-11-14 Thread Baoquan He
On 11/15/18 at 08:30am, Michal Hocko wrote: > On Thu 15-11-18 13:10:34, Baoquan He wrote: > > On 11/14/18 at 04:00pm, Michal Hocko wrote: > > > On Wed 14-11-18 22:52:50, Baoquan He wrote: > > > > On 11/14/18 at 10:01am, Michal Hocko wrote: > > > > > I

Re: Memory hotplug softlock issue

2018-11-14 Thread Baoquan He
On 11/14/18 at 04:00pm, Michal Hocko wrote: > On Wed 14-11-18 22:52:50, Baoquan He wrote: > > On 11/14/18 at 10:01am, Michal Hocko wrote: > > > I have seen an issue when the migration cannot make a forward progress > > > because of a glibc page with a reference coun

Re: [PATCH] mm, memory_hotplug: check zone_movable in has_unmovable_pages

2018-11-14 Thread Baoquan He
On 11/15/18 at 11:13am, Baoquan He wrote: > On 11/06/18 at 10:55am, Michal Hocko wrote: > > From: Michal Hocko > > > > Page state checks are racy. Under a heavy memory workload (e.g. stress > > -m 200 -t 2h) it is quite easy to hit a race window when the page is

Re: [PATCH] mm, memory_hotplug: check zone_movable in has_unmovable_pages

2018-11-14 Thread Baoquan He
r > zones are still prone to races but we even do not pretend that memory > hotremove works for those so pre-mature failure doesn't hurt that much. > > Reported-and-tested-by: Baoquan He > Acked-by: Baoquan He > Fixes: "mm, memory_hotplug: make has_unmovable_pages more rob

Re: Memory hotplug softlock issue

2018-11-14 Thread Baoquan He
On 11/14/18 at 10:01am, Michal Hocko wrote: > I have seen an issue when the migration cannot make a forward progress > because of a glibc page with a reference count bumping up and down. Most > probable explanation is the faultaround code. I am working on this and > will post a patch soon. In any

Re: Memory hotplug softlock issue

2018-11-14 Thread Baoquan He
Hi David, On 11/14/18 at 09:18am, David Hildenbrand wrote: > Code seems to be waiting for the mem_hotplug_lock in read. > We hold mem_hotplug_lock in write whenever we online/offline/add/remove > memory. There are two ways to trigger offlining of memory: > > 1. Offlining via "cat offline >

Re: [PATCHv3 1/3] x86/mm: Move LDT remap out of KASLR region on 5-level paging

2018-11-10 Thread Baoquan He
On 10/26/18 at 03:28pm, Kirill A. Shutemov wrote: > On 5-level paging LDT remap area is placed in the middle of > KASLR randomization region and it can overlap with direct mapping, > vmalloc or vmap area. ~~~ We usually call it vmemmap. > > Let's move LDT just before

Re: [PATCH] mm, memory_hotplug: teach has_unmovable_pages about of LRU migrateable pages

2018-11-06 Thread Baoquan He
On 11/06/18 at 10:51am, Michal Hocko wrote: > > I just tested the movable zone checking yesterday, will add your > > previous check back, then test again. I believe the result will be > > positive. Will udpate once done. > > THere is no need to retest with that patch for your movable node setup.

Re: [PATCH] mm, memory_hotplug: teach has_unmovable_pages about of LRU migrateable pages

2018-11-06 Thread Baoquan He
On 11/06/18 at 05:16pm, Baoquan He wrote: > On 11/06/18 at 09:28am, Michal Hocko wrote: > > > > > > > It failed. Paste the log and patch diff here, please help check > > > > > > > if I made > > > > > > > any mistake on manual cod

Re: [PATCH] mm, memory_hotplug: teach has_unmovable_pages about of LRU migrateable pages

2018-11-06 Thread Baoquan He
gt; > > > > > > > > So what about the following (on top of the previous patch which makes > > > > > sense on its own I believe). > > > > > > > > Yes, I think this looks very reasonable and should be robust. > > > > > > >

Re: [PATCH] mm, memory_hotplug: teach has_unmovable_pages about of LRU migrateable pages

2018-11-05 Thread Baoquan He
On 11/05/18 at 06:10pm, Michal Hocko wrote: > On Mon 05-11-18 22:23:08, Baoquan He wrote: > > On 11/05/18 at 01:38pm, Michal Hocko wrote: > > > On Mon 05-11-18 18:25:20, Baoquan He wrote: > > > > Hi Michal, > > > > > >

Re: [PATCH] mm, memory_hotplug: teach has_unmovable_pages about of LRU migrateable pages

2018-11-05 Thread Baoquan He
On 11/05/18 at 01:38pm, Michal Hocko wrote: > On Mon 05-11-18 18:25:20, Baoquan He wrote: > > Hi Michal, > > > > On 11/05/18 at 10:28am, Michal Hocko wrote: > > > > > > Or something like this. Ugly as hell, no question about that. I also > > >

Re: [PATCH] mm, memory_hotplug: teach has_unmovable_pages about of LRU migrateable pages

2018-11-05 Thread Baoquan He
Hi Michal, On 11/05/18 at 10:28am, Michal Hocko wrote: > > Or something like this. Ugly as hell, no question about that. I also > have to think about this some more to convince myself this will not > result in an endless loop under some situations. It failed. Paste the log and patch diff here,

Re: [PATCH] mm, memory_hotplug: teach has_unmovable_pages about of LRU migrateable pages

2018-11-05 Thread Baoquan He
On 11/05/18 at 10:28am, Michal Hocko wrote: > On Mon 05-11-18 10:14:07, Michal Hocko wrote: > > Maybe we can add a retry for movable zone pages. > > Or something like this. Ugly as hell, no question about that. I also > have to think about this some more to convince myself this will not > result

Re: [PATCH] mm, memory_hotplug: teach has_unmovable_pages about of LRU migrateable pages

2018-11-05 Thread Baoquan He
On 11/05/18 at 10:14am, Michal Hocko wrote: > On Mon 05-11-18 08:20:09, Baoquan He wrote: > > Hi Michal, > > > > On 11/02/18 at 04:55pm, Michal Hocko wrote: > > > From: Michal Hocko > > > > > > Baoquan He has noticed that 15c30bc09085 ("mm

Re: [PATCH] mm, memory_hotplug: teach has_unmovable_pages about of LRU migrateable pages

2018-11-04 Thread Baoquan He
Hi Michal, On 11/02/18 at 04:55pm, Michal Hocko wrote: > From: Michal Hocko > > Baoquan He has noticed that 15c30bc09085 ("mm, memory_hotplug: make > has_unmovable_pages more robust") is causing memory offlining failures > on a movable node. After a furthe

Re: Memory hotplug failed to offline on bare metal system of multiple nodes

2018-11-01 Thread Baoquan He
On 11/01/18 at 10:22am, Michal Hocko wrote: > > I haven't figured out why the above commit caused those memmory > > block in MOVABL zone being not removable. Still checking. Attach the > > tested reverting patch in this mail. > > Could you check which of the test inside has_unmovable_pages

Memory hotplug failed to offline on bare metal system of multiple nodes

2018-11-01 Thread Baoquan He
l checking. Attach the tested reverting patch in this mail. Thanks Baoquan >From 6644aefdf0f2499f7c7c3f30c7c31e791fe3c05a Mon Sep 17 00:00:00 2001 From: Baoquan He Date: Thu, 1 Nov 2018 11:52:41 +0800 Subject: [PATCH] mm, memory_hotplug: memory block failed to offline On bare metal with multip

Re: [PATCH] x86_64, vmcoreinfo: Append 'page_offset_base' to vmcoreinfo

2018-10-30 Thread Baoquan He
Hi Bhupesh, On 10/30/18 at 12:33pm, Bhupesh Sharma wrote: > > Why it's broken? Have you investigated and figured out why it's broken? > > If fix, what patch will it look like? Does the patch prove it's not > > worth using the current way? > > > > Have you thought about this in advance? Or still

Re: [PATCHv2 1/2] x86/mm: Move LDT remap out of KASLR region on 5-level paging

2018-10-25 Thread Baoquan He
On 10/25/18 at 10:24am, Kirill A. Shutemov wrote: > On Thu, Oct 25, 2018 at 10:18:09AM +0800, Baoquan He wrote: > > > We don't touch 4 pgd slot gap just before the direct mapping reserved > > > for a hypervisor, but move direct mapping by one slot instead. > > > &

Re: [PATCHv2 1/2] x86/mm: Move LDT remap out of KASLR region on 5-level paging

2018-10-24 Thread Baoquan He
Hi Kirill, Thanks for making this patchset. I have small concerns, please see the inline comments. On 10/24/18 at 03:51pm, Kirill A. Shutemov wrote: > On 5-level paging LDT remap area is placed in the middle of > KASLR randomization region and it can overlap with direct mapping, > vmalloc or

Re: [PATCH v9 8/8] x86/boot/KASLR: Limit kaslr to choosing the immovable memory

2018-10-22 Thread Baoquan He
On 10/22/18 at 06:13pm, Chao Fan wrote: > >> +static bool process_mem_region(struct mem_vector *region, > >> + unsigned long long minimum, > >> + unsigned long long image_size) > >> +{ > >> + int i; > >> + /* > >> + * If no immovable memory

[tip:x86/mm] x86/mm/doc: Clean up the x86-64 virtual memory layout descriptions

2018-10-06 Thread tip-bot for Baoquan He
Commit-ID: 5b12904065798fee8b153a506ac7b72d5ebbe26c Gitweb: https://git.kernel.org/tip/5b12904065798fee8b153a506ac7b72d5ebbe26c Author: Baoquan He AuthorDate: Sat, 6 Oct 2018 16:43:26 +0800 Committer: Ingo Molnar CommitDate: Sat, 6 Oct 2018 14:46:47 +0200 x86/mm/doc: Clean up the x86

[tip:x86/mm] x86/KASLR: Update KERNEL_IMAGE_SIZE description

2018-10-06 Thread tip-bot for Baoquan He
Commit-ID: 06d4a462e954756f3d3d54e6f3f1bdc2e6f592a9 Gitweb: https://git.kernel.org/tip/06d4a462e954756f3d3d54e6f3f1bdc2e6f592a9 Author: Baoquan He AuthorDate: Sat, 6 Oct 2018 16:43:25 +0800 Committer: Ingo Molnar CommitDate: Sat, 6 Oct 2018 14:46:46 +0200 x86/KASLR: Update

Re: [PATCH v4 2/3] ACPI / NUMA: Add warning message if the padding size for KASLR is not enough

2018-09-27 Thread Baoquan He
On 09/27/18 at 04:31pm, Masayoshi Mizuma wrote: > From: Masayoshi Mizuma > > Add warning message if the padding size for KASLR, > rand_mem_physical_padding, is not enough. The message also > says the suitable padding size. > > Signed-off-by: Masayoshi Mizuma > --- >

Re: [PATCH] x86/boot: Fix kexec booting failure after SEV early boot support

2018-09-26 Thread Baoquan He
On 09/25/18 at 07:26pm, Borislav Petkov wrote: > IINM, the problem can be addressed in a simpler way by getting rid of > enc_bit and thus getting rid of the need to do relative addressing of > anything and simply doing the whole dance of figuring out the C-bit each > time. It probably wouldn't be

Re: [PATCH v2 2/3] x86/mm/KASLR: Calculate the actual size of vmemmap region

2018-09-20 Thread Baoquan He
On 09/12/18 at 08:31am, Ingo Molnar wrote: > Would you like to work on this? These would be really nice additions, once > the code is cleaned > up to be maintainable and the pending bug fixes you have are merged. > > In terms of patch logistics I'd suggest this ordering: > > - documentation

Re: [PATCH v2 2/3] x86/mm/KASLR: Calculate the actual size of vmemmap region

2018-09-12 Thread Baoquan He
On 09/12/18 at 08:31am, Ingo Molnar wrote: > > * Baoquan He wrote: > > > On 09/11/18 at 08:08pm, Baoquan He wrote: > > > On 09/11/18 at 11:28am, Ingo Molnar wrote: > > > > Yeah, so proper context is still missing, this paragraph appears to > > >

Re: [PATCH v2 2/3] x86/mm/KASLR: Calculate the actual size of vmemmap region

2018-09-11 Thread Baoquan He
On 09/11/18 at 08:08pm, Baoquan He wrote: > On 09/11/18 at 11:28am, Ingo Molnar wrote: > > Yeah, so proper context is still missing, this paragraph appears to assume > > from the reader a > > whole lot of prior knowledge, and this is one of the top comments in > >

Re: [PATCH v2 2/3] x86/mm/KASLR: Calculate the actual size of vmemmap region

2018-09-11 Thread Baoquan He
On 09/11/18 at 11:28am, Ingo Molnar wrote: > Yeah, so proper context is still missing, this paragraph appears to assume > from the reader a > whole lot of prior knowledge, and this is one of the top comments in kaslr.c > so there's nowhere > else to go read about the background. > > For

Re: [PATCH v2 2/3] x86/mm/KASLR: Calculate the actual size of vmemmap region

2018-09-11 Thread Baoquan He
On 09/11/18 at 09:59am, Ingo Molnar wrote: > > * Baoquan He wrote: > > > /* > > + * Memory regions randomized by KASLR (except modules that use a separate > > + * logic earlier during boot). Currently they are the physical memory > > + * mapping, vmalloc and v

Re: [PATCH v2 3/3] mm: Add build time sanity chcek for struct page size

2018-09-11 Thread Baoquan He
On 09/10/18 at 09:41pm, kbuild test robot wrote: >include/linux/build_bug.h:69:2: note: in expansion of macro > 'BUILD_BUG_ON_MSG' > BUILD_BUG_ON_MSG(condition, "BUILD_BUG_ON failed: " #condition) > ^~~~ > >> mm/page_alloc.c:6852:2: note: in expansion of macro

Re: [PATCH v2 2/3] x86/mm/KASLR: Calculate the actual size of vmemmap region

2018-09-11 Thread Baoquan He
On 09/10/18 at 08:11am, Ingo Molnar wrote: > > * Baoquan He wrote: > > > @@ -108,6 +109,14 @@ void __init kernel_randomize_memory(void) > > if (memory_tb < kaslr_regions[0].size_tb) > > kaslr_regions[0].size_tb = memory_tb; > > > &g

Re: [PATCH v2 1/3] x86/mm/KASLR: Fix the wrong calculation of kalsr region initial size

2018-09-11 Thread Baoquan He
On 09/10/18 at 08:18am, Ingo Molnar wrote: > > * Baoquan He wrote: > > > In memory KASLR, __PHYSICAL_MASK_SHIFT is taken to calculate the > > initial size of the direct mapping region. This is right in the > > old code where __PHYSICAL_MASK_SHIFT was equal to

Re: [PATCH 0/3] x86/boot/KASLR: enhance randomness of kernel load addr when using GiB hugepage

2018-09-09 Thread Baoquan He
Hi Pingfan, On 09/06/18 at 10:36am, Pingfan Liu wrote: > commit 747ff6265db4 ("x86/boot/KASLR: Skip specified number of 1GB huge > pages when doing physical randomization (KASLR)") and commit > 9b912485e0e7 ("x86/boot/KASLR: Add two new functions for 1GB huge pages > handling") prevent the

[PATCH v2 3/3] mm: Add build time sanity chcek for struct page size

2018-09-09 Thread Baoquan He
. Here 1/4 of PAGE_SIZE is chosen since system must have been insane with this value. For those systems with PAGE_SIZE larger than 4KB, 1KB is simply taken. Suggested-by: Kirill A. Shutemov Signed-off-by: Baoquan He --- mm/page_alloc.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/mm

[PATCH v2 1/3] x86/mm/KASLR: Fix the wrong calculation of kalsr region initial size

2018-09-09 Thread Baoquan He
igger than 64TB. In fact, here MAX_PHYSMEM_BITS should be used instead. Fix it by replacing __PHYSICAL_MASK_SHIFT with MAX_PHYSMEM_BITS. Fixes: b83ce5ee9147 ("x86/mm/64: Make __PHYSICAL_MASK_SHIFT always 52") Signed-off-by: Baoquan He Acked-by: Kirill A. Shutemov Reviewed-by: Thomas Garni

[PATCH v2 2/3] x86/mm/KASLR: Calculate the actual size of vmemmap region

2018-09-09 Thread Baoquan He
. So here calculate how many TB by the actual size of vmemmap region and align up to 1TB boundary. 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 0988971069c9

Re: [PATCH 1/2] x86/mm/KASLR: Fix the wrong calculation of kalsr region initial size

2018-09-08 Thread Baoquan He
On 09/08/18 at 02:10pm, Thomas Gleixner wrote: > On Wed, 29 Aug 2018, Baoquan He wrote: > > > In memory KASLR, __PHYSICAL_MASK_SHIFT is taken to calculate the > > initial size of the direct mapping region. This is right in the > > old code where __PHYSICAL_MASK_SHIFT was e

Re: [PATCH 2/2] x86/mm/KASLR: Adjust the vmemmap size according to paging mode

2018-09-05 Thread Baoquan He
On 09/05/18 at 03:09pm, Kirill A. Shutemov wrote: > On Wed, Sep 05, 2018 at 08:15:31AM +0000, Baoquan He wrote: > > On 09/04/18 at 11:13am, Kirill A. Shutemov wrote: > > > On Mon, Sep 03, 2018 at 10:52:13PM +0800, Baoquan He wrote: > > > > On 09/03/18 at 01:

Re: [PATCH 2/2] x86/mm/KASLR: Adjust the vmemmap size according to paging mode

2018-09-05 Thread Baoquan He
On 09/04/18 at 11:13am, Kirill A. Shutemov wrote: > On Mon, Sep 03, 2018 at 10:52:13PM +0800, Baoquan He wrote: > > On 09/03/18 at 01:26pm, Kirill A. Shutemov wrote: > > > > > But there's corner case when struct page is unreasonably large and > > > > >

Re: [PATCH 1/3] x86/boot: Add bit fields into xloadflags for 5-level kernel checking

2018-09-03 Thread Baoquan He
On 09/03/18 at 09:13pm, H. Peter Anvin wrote: > On 09/03/18 20:44, Baoquan He wrote: > > > > 1) in arch/x86/kernel/relocate_kernel_64.S, we set X86_CR4_LA57 into cr4 > > if the 1st kernel is in 5-level mode. Then in > > arch/x86/boot/compressed/head_64.S, paging_pr

Re: [PATCH 1/3] x86/boot: Add bit fields into xloadflags for 5-level kernel checking

2018-09-03 Thread Baoquan He
Hi hpa, Thanks for looking into this. On 09/03/18 at 07:41pm, H. Peter Anvin wrote: > I don't understand why there is any reason not to always enter the target > kernel in 4-level mode. There certainly is no point whatsoever in having two > xloadflags: the only thing that could possibly matter

Re: [PATCH 2/2] x86/mm/KASLR: Adjust the vmemmap size according to paging mode

2018-09-03 Thread Baoquan He
On 09/03/18 at 01:26pm, Kirill A. Shutemov wrote: > On Mon, Sep 03, 2018 at 03:47:18PM +0800, Baoquan He wrote: > > On 09/02/18 at 11:52pm, Kirill A. Shutemov wrote: > > > On Thu, Aug 30, 2018 at 11:25:12PM +0800, Baoquan He wrote: > > > > Hi Kirill, > > > &g

Re: [PATCH 2/2] x86/mm/KASLR: Adjust the vmemmap size according to paging mode

2018-09-03 Thread Baoquan He
On 09/02/18 at 11:52pm, Kirill A. Shutemov wrote: > On Thu, Aug 30, 2018 at 11:25:12PM +0800, Baoquan He wrote: > > Hi Kirill, > > > > I made a new version according to your suggestion, just a little > > different, I didn't make 1TB as default, just calculate with the

Re: [PATCH 2/2] x86/mm/KASLR: Adjust the vmemmap size according to paging mode

2018-08-30 Thread Baoquan He
it was touchde by other people. Any comment about this? I can change accordingly. >From b19955ec5d439f7cb580331c83a27ad5753b06b6 Mon Sep 17 00:00:00 2001 From: Baoquan He Date: Thu, 30 Aug 2018 11:45:13 +0800 Subject: [PATCH] x86/mm/KASLR: Calculate the actual size of vmemmap region Vmemmap region

Re: [PATCH 2/2] x86/mm/KASLR: Adjust the vmemmap size according to paging mode

2018-08-29 Thread Baoquan He
On 08/29/18 at 03:26pm, Kirill A. Shutemov wrote: > On Wed, Aug 29, 2018 at 08:18:56PM +0800, Baoquan He wrote: > > On 08/29/18 at 03:05pm, Kirill A. Shutemov wrote: > > > On Wed, Aug 29, 2018 at 10:17:54AM +0800, Baoquan He wrote: > > > > Vmemmap area has dif

Re: [PATCH 2/2] x86/mm/KASLR: Adjust the vmemmap size according to paging mode

2018-08-29 Thread Baoquan He
On 08/29/18 at 03:05pm, Kirill A. Shutemov wrote: > On Wed, Aug 29, 2018 at 10:17:54AM +0800, Baoquan He wrote: > > Vmemmap area has different base and size depending on paging mode. > > Now we just hardcode its size as 1TB in memory KASLR, it's not > > right fo

Re: [PATCH 2/2] x86/mm/KASLR: Adjust the vmemmap size according to paging mode

2018-08-29 Thread Baoquan He
On 08/29/18 at 03:05pm, Kirill A. Shutemov wrote: > On Wed, Aug 29, 2018 at 10:17:54AM +0800, Baoquan He wrote: > > Vmemmap area has different base and size depending on paging mode. > > Now we just hardcode its size as 1TB in memory KASLR, it's not > > right fo

[PATCH 1/2] x86/mm/KASLR: Fix the wrong calculation of kalsr region initial size

2018-08-28 Thread Baoquan He
igger than 64TB. In fact, here MAX_PHYSMEM_BITS should be used instead. Fix it by by replacing __PHYSICAL_MASK_SHIFT with MAX_PHYSMEM_BITS. Signed-off-by: Baoquan He --- arch/x86/mm/kaslr.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/x86/mm/kaslr.c b/arch/x86/mm/kas

[PATCH 2/2] x86/mm/KASLR: Adjust the vmemmap size according to paging mode

2018-08-28 Thread Baoquan He
Vmemmap area has different base and size depending on paging mode. Now we just hardcode its size as 1TB in memory KASLR, it's not right for 5-level paging mode. Adjust it according to paging mode and use it during memory KASLR. Signed-off-by: Baoquan He --- arch/x86/include/asm

Re: [PATCH v5 4/4] x86/boot/KASLR: Limit kaslr to choosing the immovable memory

2018-08-27 Thread Baoquan He
On 08/27/18 at 01:56pm, Baoquan He wrote: > On 08/07/18 at 02:50pm, Chao Fan wrote: > > If 'CONFIG_MEMORY_HOTREMOVE' specified and the account of immovable > If CONFIG_MEMORY_HOTREMOVE is enabled, > > memory regions is not zero. Calculate the intersection between memory > &g

Re: [PATCH v5 4/4] x86/boot/KASLR: Limit kaslr to choosing the immovable memory

2018-08-27 Thread Baoquan He
On 08/27/18 at 02:28pm, Chao Fan wrote: > >Is it possible to take num_immovable_mem definition out from #ifdef > >CONFIG_MEMORY_HOTREMOVE block and check it here like below? This way, > >one level of indentation can be reduced in the for loop, and code is > >more readable. > > > > I think there

Re: [PATCH v5 4/4] x86/boot/KASLR: Limit kaslr to choosing the immovable memory

2018-08-27 Thread Baoquan He
On 08/27/18 at 01:35pm, Baoquan He wrote: > Is it possible to take num_immovable_mem out from the #ifdef > CONFIG_MEMORY_HOTREMOVE region so that you can check it earlier to see > if the old way need be taken? This way, we can reduce one level of > indentation in the for loop. J

Re: [PATCH v5 4/4] x86/boot/KASLR: Limit kaslr to choosing the immovable memory

2018-08-26 Thread Baoquan He
On 08/07/18 at 02:50pm, Chao Fan wrote: > If 'CONFIG_MEMORY_HOTREMOVE' specified and the account of immovable If CONFIG_MEMORY_HOTREMOVE is enabled, > memory regions is not zero. Calculate the intersection between memory > regions from e820/efi memory table and immovable memory regions. > Or go

Re: [PATCH v5 4/4] x86/boot/KASLR: Limit kaslr to choosing the immovable memory

2018-08-26 Thread Baoquan He
On 08/07/18 at 02:50pm, Chao Fan wrote: > If 'CONFIG_MEMORY_HOTREMOVE' specified and the account of immovable > memory regions is not zero. Calculate the intersection between memory > regions from e820/efi memory table and immovable memory regions. > Or go on the old code. > > Rename

Re: [PATCH v5 3/4] x86/boot/KASLR: Walk srat tables to filter immovable memory

2018-08-26 Thread Baoquan He
On 08/27/18 at 10:56am, Chao Fan wrote: > >> +#ifdef CONFIG_MEMORY_HOTREMOVE > >> +/* > >> + * According to ACPI table, filter the immvoable memory regions > >> + * and store them in immovable_mem[]. > >> + */ > >> +static void handle_immovable_mem(void) > > > >Can we change this function like

Re: [PATCH v5 3/4] x86/boot/KASLR: Walk srat tables to filter immovable memory

2018-08-26 Thread Baoquan He
On 08/07/18 at 02:49pm, Chao Fan wrote: > If 'CONFIG_MEMORY_HOTREMOVE' specified, walk the acpi srat memory > tables, store the immovable memory regions, so that kaslr can get > the information abouth where can be selected or not. > If 'CONFIG_MEMORY_HOTREMOVE' not specified, go on the old code.

Re: [PATCH v5 3/4] x86/boot/KASLR: Walk srat tables to filter immovable memory

2018-08-23 Thread Baoquan He
On 08/07/18 at 02:49pm, Chao Fan wrote: > If 'CONFIG_MEMORY_HOTREMOVE' specified, walk the acpi srat memory > tables, store the immovable memory regions, so that kaslr can get > the information abouth where can be selected or not. > If 'CONFIG_MEMORY_HOTREMOVE' not specified, go on the old code. >

Re: [RESEND] [PATCH 1/2] x86/mm: Add an option to change the padding used for the physical memory mapping.

2018-08-21 Thread Baoquan He
Hi Masa, On 08/21/18 at 09:24am, Masayoshi Mizuma wrote: > From: Masayoshi Mizuma > > There are some exceptional cases that the padding used for the physical > memory mapping section is not enough. > > For example of the cases: > - As Baoquan reported in the following, SGI UV system. >

Re: [PATCH v4 1/4] x86/boot: Add acpitb.h to help parse acpi tables

2018-07-25 Thread Baoquan He
On 07/24/18 at 04:36pm, Chao Fan wrote: > On Tue, Jul 24, 2018 at 02:02:57PM +0800, Baoquan He wrote: > >Hi chao, > > > >On 07/23/18 at 05:29pm, Chao Fan wrote: > >> In order to parse ACPI tables, reuse the head file linux/acpi.h, > >> so that the files

Re: [PATCH v7 4/4] kexec_file: Load kernel at top of system RAM if required

2018-07-25 Thread Baoquan He
On 07/23/18 at 04:34pm, Michal Hocko wrote: > On Thu 19-07-18 23:17:53, Baoquan He wrote: > > Kexec has been a formal feature in our distro, and customers owning > > those kind of very large machine can make use of this feature to speed > > up the reboot process. On uefi ma

Re: [PATCH v4 1/4] x86/boot: Add acpitb.h to help parse acpi tables

2018-07-24 Thread Baoquan He
Hi chao, On 07/23/18 at 05:29pm, Chao Fan wrote: > In order to parse ACPI tables, reuse the head file linux/acpi.h, > so that the files in 'compressed' directory can read ACPI table > by including this head file. > > Signed-off-by: Chao Fan > --- > arch/x86/boot/compressed/acpitb.h | 7 +++

[PATCH] mm/page_alloc: Deprecate kernelcore=nn and movable_core=

2018-07-17 Thread Baoquan He
We can still use 'kernelcore=mirror' or 'movable_node' for the usage of hotplug and movable zone. If somebody shows up with a valid usecase we can reconsider. Suggested-by: Michal Hocko Signed-off-by: Baoquan He --- Documentation/admin-guide/kernel-parameters.txt | 2 ++ mm/page_alloc.c

Re: Bug report about KASLR and ZONE_MOVABLE

2018-07-16 Thread Baoquan He
On 07/16/18 at 05:24pm, Michal Hocko wrote: > On Mon 16-07-18 21:02:02, Baoquan He wrote: > > On 07/16/18 at 01:38pm, Michal Hocko wrote: > > > On Fri 13-07-18 07:52:40, Baoquan He wrote: > > > > Hi Michal, > > > > > > > > On 07/12/18 at 0

Re: Bug report about KASLR and ZONE_MOVABLE

2018-07-16 Thread Baoquan He
On 07/16/18 at 01:38pm, Michal Hocko wrote: > On Fri 13-07-18 07:52:40, Baoquan He wrote: > > Hi Michal, > > > > On 07/12/18 at 02:32pm, Michal Hocko wrote: > [...] > > > I am not able to find the beginning of the email thread right now. Could > > > you s

Re: Bug report about KASLR and ZONE_MOVABLE

2018-07-12 Thread Baoquan He
Hi Michal, On 07/12/18 at 02:32pm, Michal Hocko wrote: > On Thu 12-07-18 14:01:15, Chao Fan wrote: > > On Thu, Jul 12, 2018 at 01:49:49PM +0800, Dou Liyang wrote: > > >Hi Baoquan, > > > > > >At 07/11/2018 08:40 PM, Baoquan He wrote: > >

Re: Bug report about KASLR and ZONE_MOVABLE

2018-07-12 Thread Baoquan He
On 07/12/18 at 09:19am, Chao Fan wrote: > On Wed, Jul 11, 2018 at 08:40:08PM +0800, Baoquan He wrote: > >Please try this v3 patch: > > > >From 9850d3de9c02e570dc7572069a9749a8add4c4c7 Mon Sep 17 00:00:00 2001 > >From: Baoquan He > >Date: Wed, 11 Jul 2018 20:31:5

Re: Bug report about KASLR and ZONE_MOVABLE

2018-07-11 Thread Baoquan He
On 07/11/18 at 06:49pm, Baoquan He wrote: > On 07/11/18 at 06:41pm, Baoquan He wrote: > > diff --git a/mm/page_alloc.c b/mm/page_alloc.c > > index 1521100..fe346b4 100644 > > --- a/mm/page_alloc.c > > +++ b/mm/page_alloc.c > > @@ -667

Re: Bug report about KASLR and ZONE_MOVABLE

2018-07-11 Thread Baoquan He
Please try this v3 patch: >From 9850d3de9c02e570dc7572069a9749a8add4c4c7 Mon Sep 17 00:00:00 2001 From: Baoquan He Date: Wed, 11 Jul 2018 20:31:51 +0800 Subject: [PATCH v3] mm, page_alloc: find movable zone after kernel text In find_zone_movable_pfns_for_nodes(), when try to find the start

Re: Bug report about KASLR and ZONE_MOVABLE

2018-07-11 Thread Baoquan He
On 07/11/18 at 06:41pm, Baoquan He wrote: > Hmm, it's an issue, worth fixing it. Otherwise the size of > movable area will be smaller than we expect when add "kernel_core=" > or "movable_core=". > > Add a check in find_zone_movable_pfns_for_nodes(), and use

Re: Bug report about KASLR and ZONE_MOVABLE

2018-07-11 Thread Baoquan He
ller than we expect when add "kernel_core=" or "movable_core=". Add a check in find_zone_movable_pfns_for_nodes(), and use min() to get the starting address of movable area between aligned '_etext' and start_pfn. It will go to label 'restart' to calculate the 2nd round if no

Re: [PATCH v4 0/3] sparse_init rewrite

2018-07-09 Thread Baoquan He
Hi Andrew, On 07/09/18 at 02:29pm, Andrew Morton wrote: > On Mon, 9 Jul 2018 13:53:09 -0400 Pavel Tatashin > wrote: > > For the ease of review, I split this work so the first patch only adds new > > interfaces, the second patch enables them, and removes the old ones. > > This clashes pretty

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

2018-07-07 Thread Baoquan He
Hi Andrew, Could you pick this series into mm tree so that it can catch 4.18? Thanks Baoquan On 06/28/18 at 02:28pm, Baoquan He wrote: > This is v6 post. > > In sparse_init(), two temporary pointer arrays, usemap_map and map_map > are allocated with the size of NR_MEM_SECTIONS. T

Re: [PATCH] resource: Use 2-factor allocator calls

2018-07-05 Thread Baoquan He
Hi Andrew, Kees, About the implemention of walk_system_ram_res_rev(), it was posted by AKASHI firstly for his arm kexec_file adding, later he dropped it because he took other way and doesn't need walk_system_ram_res_rev() any more in his patchset. Then I found my below patch needs a

[tip:x86/boot] x86/boot/KASLR: Skip specified number of 1GB huge pages when doing physical randomization (KASLR)

2018-07-03 Thread tip-bot for Baoquan He
Commit-ID: 747ff6265db4c2b77e8c7384f8054916a0c1eb39 Gitweb: https://git.kernel.org/tip/747ff6265db4c2b77e8c7384f8054916a0c1eb39 Author: Baoquan He AuthorDate: Mon, 25 Jun 2018 11:16:56 +0800 Committer: Ingo Molnar CommitDate: Tue, 3 Jul 2018 10:50:13 +0200 x86/boot/KASLR: Skip

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

2018-07-03 Thread tip-bot for Baoquan He
Commit-ID: 9b912485e0e74a74e042e4f2dd87f262e46fcdf1 Gitweb: https://git.kernel.org/tip/9b912485e0e74a74e042e4f2dd87f262e46fcdf1 Author: Baoquan He AuthorDate: Mon, 25 Jun 2018 11:16:55 +0800 Committer: Ingo Molnar CommitDate: Tue, 3 Jul 2018 10:50:12 +0200 x86/boot/KASLR: Add two new

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

2018-07-02 Thread Baoquan He
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: [RFC PATCH 0/4] x86/boot/KASLR: Parse ACPI table and limit kaslr in immovable memory.

2018-07-02 Thread Baoquan He
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 v3 1/2] mm/sparse: add sparse_init_nid()

2018-07-01 Thread Baoquan He
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 v3 1/2] mm/sparse: add sparse_init_nid()

2018-07-01 Thread Baoquan He
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()

2018-07-01 Thread Baoquan He
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()

2018-07-01 Thread Baoquan He
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()

2018-07-01 Thread Baoquan He
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()

2018-07-01 Thread Baoquan He
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()

2018-07-01 Thread Baoquan He
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

  1   2   3   4   5   6   7   8   9   10   >