) 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
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
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
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
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
) 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
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
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:
> > >
>
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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:
>
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:
>
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
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
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
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
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.
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
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/
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.
.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
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
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
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
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
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
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
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
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 <
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
.
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
.
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
_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>
_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
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
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
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.
>
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.
>
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
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
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
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
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.
>
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.
>
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()
>
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
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
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
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
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
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
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
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:
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
, 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
, 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
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
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
_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>
_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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
, 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
, 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
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
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
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:
>
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:
>
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-
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-
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
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
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
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
_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>
, 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
701 - 800 of 3124 matches
Mail list logo