Re: [5.6.0-rc7] Kernel crash while running ndctl tests

On 03/24/20 at 03:06pm, Sachin Sant wrote: > > > > On 24-Mar-2020, at 2:45 PM, Aneesh Kumar K.V > > wrote: > > > > Sachin Sant writes: > > > >> While running ndctl[1] tests against 5.6.0-rc7 following crash is > >> encountered. > >> > >> Bisect leads me to commit d41e2f3bd546 > >>

Re: [5.6.0-rc7] Kernel crash while running ndctl tests

Hi Sachin, On 03/24/20 at 11:25am, Sachin Sant wrote: > While running ndctl[1] tests against 5.6.0-rc7 following crash is encountered. > > Bisect leads me to commit d41e2f3bd546 > mm/hotplug: fix hot remove failure in SPARSEMEM|!VMEMMAP case > > Reverting this commit helps and the tests

Re: [PATCH v3 04/27] ocxl: Remove unnecessary externs

On 02/26/20 at 03:20pm, Greg Kurz wrote: > On Wed, 26 Feb 2020 22:15:23 +0800 > 'Baoquan He' wrote: > > > On 02/26/20 at 10:01am, Greg Kurz wrote: > > > On Wed, 26 Feb 2020 19:26:34 +1100 > > > "Alastair D'Silva" wrote: > > > > > &

Re: [PATCH v3 04/27] ocxl: Remove unnecessary externs

On 02/26/20 at 10:01am, Greg Kurz wrote: > On Wed, 26 Feb 2020 19:26:34 +1100 > "Alastair D'Silva" wrote: > > > > -Original Message- > > > From: Baoquan He > > > Sent: Wednesday, 26 February 2020 7:15 PM > > > To: Alastair D'Si

Re: [PATCH v3 04/27] ocxl: Remove unnecessary externs

On 02/21/20 at 02:26pm, Alastair D'Silva wrote: > From: Alastair D'Silva > > Function declarations don't need externs, remove the existing ones > so they are consistent with newer code > > Signed-off-by: Alastair D'Silva > --- > arch/powerpc/include/asm/pnv-ocxl.h | 32

Re: devm_memremap_pages() triggers a kasan_add_zero_shadow() warning

On 08/21/19 at 05:12pm, Qian Cai wrote: > > > Does disabling CONFIG_RANDOMIZE_BASE help? Maybe that workaround has > > > regressed. Effectively we need to find what is causing the kernel to > > > sometimes be placed in the middle of a custom reserved memmap= range. > > > > Yes, disabling KASLR

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

On 07/26/18 at 04:01pm, Michal Hocko wrote: > On Thu 26-07-18 21:37:05, Baoquan He wrote: > > On 07/26/18 at 03:14pm, Michal Hocko wrote: > > > On Thu 26-07-18 15:12:42, Michal Hocko wrote: > > > > On Thu 26-07-18 21:09:04, Baoquan He wrote: > > > > &g

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

On 07/26/18 at 03:14pm, Michal Hocko wrote: > On Thu 26-07-18 15:12:42, Michal Hocko wrote: > > On Thu 26-07-18 21:09:04, Baoquan He wrote: > > > On 07/26/18 at 02:59pm, Michal Hocko wrote: > > > > On Wed 25-07-18 14:48:13, Baoquan He wrote: > > > > &g

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

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 v7 4/4] kexec_file: Load kernel at top of system RAM if required

Hi Andrew, On 07/19/18 at 12:44pm, Andrew Morton wrote: > On Thu, 19 Jul 2018 23:17:53 +0800 Baoquan He wrote: > > > As far as I can tell, the above is the whole reason for the patchset, > > > yes? To avoid confusing users. > > > > > > In fact, it's n

Re: [PATCH v7 1/4] resource: Move reparent_resources() to kernel/resource.c and make it public

On 07/18/18 at 07:37pm, Andy Shevchenko wrote: > On Wed, Jul 18, 2018 at 7:36 PM, Andy Shevchenko > wrote: > > On Wed, Jul 18, 2018 at 5:49 AM, Baoquan He wrote: > >> reparent_resources() is duplicated in arch/microblaze/pci/pci-common.c > >> and arch/powerp

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

Hi Andrew, On 07/18/18 at 03:33pm, Andrew Morton wrote: > On Wed, 18 Jul 2018 10:49:44 +0800 Baoquan He wrote: > > > For kexec_file loading, if kexec_buf.top_down is 'true', the memory which > > is used to load kernel/initrd/purgatory is supposed to be allocated fr

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

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

[PATCH v7 3/4] resource: add walk_system_ram_res_rev()

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

[PATCH v7 2/4] resource: Use list_head to link sibling resource

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

[PATCH v7 1/4] resource: Move reparent_resources() to kernel/resource.c and make it public

reparent_resources() is duplicated in arch/microblaze/pci/pci-common.c and arch/powerpc/kernel/pci-common.c, so move it to kernel/resource.c so that it's shared. Reviewed-by: Andy Shevchenko Signed-off-by: Baoquan He Cc: Michal Simek Cc: Benjamin Herrenschmidt Cc: Paul Mackerras Cc: Michael

[PATCH v7 0/4] resource: Use list_head to link sibling resource

d 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 He (4): resource: Move reparent_resources() to kernel/resource.c and make it public resource: Use list_head to link sibling resour

Re: [kbuild-all] [PATCH v6 2/4] resource: Use list_head to link sibling resource

On 07/10/18 at 08:59am, Ye Xiaolong wrote: > Hi, > > On 07/08, Baoquan He wrote: > >Hi, > > > >On 07/05/18 at 01:00am, kbuild test robot wrote: > >> Hi Baoquan, > >> > >> I love your patch! Yet something to improve: > >> > >

Re: [PATCH v6 2/4] resource: Use list_head to link sibling resource

On 07/08/18 at 08:48pm, Andy Shevchenko wrote: > On Sun, Jul 8, 2018 at 5:59 AM, Baoquan He wrote: > > On 07/05/18 at 01:00am, kbuild test robot wrote: > > > However, I didn't find below branch. And tried to open it in web > > broswer, also failed. > > W

Re: [PATCH v6 2/4] resource: Use list_head to link sibling resource

please drop us a note to > help improve the system] Thanks for telling. I cloned 0day-ci/linut to my local pc. https://github.com/0day-ci/linux.git However, I didn't find below branch. And tried to open it in web broswer, also failed. > url: > https://github.com/0day-ci/linux/commits/Bao

Re: [PATCH v6 1/4] resource: Move reparent_resources() to kernel/resource.c and make it public

On 07/04/18 at 07:46pm, Andy Shevchenko wrote: > On Wed, Jul 4, 2018 at 7:10 AM, Baoquan He wrote: > > reparent_resources() is duplicated in arch/microblaze/pci/pci-common.c > > and arch/powerpc/kernel/pci-common.c, so move it to kernel/resource.c > > so that it's sha

Re: [PATCH v5 1/4] resource: Move reparent_resources() to kernel/resource.c and make it public

On 07/03/18 at 11:57pm, Andy Shevchenko wrote: > On Tue, Jul 3, 2018 at 5:55 PM, Baoquan He wrote: > > On 06/12/18 at 05:24pm, Andy Shevchenko wrote: > >> On Tue, Jun 12, 2018 at 5:20 PM, Andy Shevchenko > >> wrote: > > >> > I briefly looked at the cod

[PATCH v6 3/4] resource: add walk_system_ram_res_rev()

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

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

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

[PATCH v6 1/4] resource: Move reparent_resources() to kernel/resource.c and make it public

reparent_resources() is duplicated in arch/microblaze/pci/pci-common.c and arch/powerpc/kernel/pci-common.c, so move it to kernel/resource.c so that it's shared. Signed-off-by: Baoquan He --- arch/microblaze/pci/pci-common.c | 37 - arch/powerpc/kernel/pci

[PATCH v6 2/4] resource: Use list_head to link sibling resource

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

[PATCH v6 0/4] resource: Use list_head to link sibling resource

link resouce siblings. Baoquan He (4): resource: Move reparent_resources() to kernel/resource.c and make it public 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/arm/plat-sam

Re: [PATCH v5 1/4] resource: Move reparent_resources() to kernel/resource.c and make it public

Hi Andy, On 06/12/18 at 05:24pm, Andy Shevchenko wrote: > On Tue, Jun 12, 2018 at 5:20 PM, Andy Shevchenko > wrote: > >> Hmm, I just copied it from arch/powerpc/kernel/pci-common.c. The > >> function interface expects an integer returned value, not sure what a > >> real error codes look like,

Re: [PATCH v5 2/4] resource: Use list_head to link sibling resource

On 06/12/18 at 05:10pm, Julia Lawall wrote: > This looks wrong. After a list iterator, the index variable points to a > dummy structure. > > julia > > url: > https://github.com/0day-ci/linux/commits/Baoquan-He/resource-Use-list_head-to-link-sibling-resource/20180612-1

Re: [PATCH v5 1/4] resource: Move reparent_resources() to kernel/resource.c and make it public

On 06/12/18 at 11:29am, Andy Shevchenko wrote: > On Tue, Jun 12, 2018 at 6:28 AM, Baoquan He wrote: > > reparent_resources() is duplicated in arch/microblaze/pci/pci-common.c > > and arch/powerpc/kernel/pci-common.c, so move it to kernel/resource.c > > so that it's shared

Re: [PATCH v5 1/4] resource: Move reparent_resources() to kernel/resource.c and make it public

On 06/12/18 at 11:29am, Andy Shevchenko wrote: > On Tue, Jun 12, 2018 at 6:28 AM, Baoquan He wrote: > > reparent_resources() is duplicated in arch/microblaze/pci/pci-common.c > > and arch/powerpc/kernel/pci-common.c, so move it to kernel/resource.c > > so that it's shared

Re: [PATCH v5 1/4] resource: Move reparent_resources() to kernel/resource.c and make it public

On 06/12/18 at 11:28am, Baoquan He wrote: > reparent_resources() is duplicated in arch/microblaze/pci/pci-common.c > and arch/powerpc/kernel/pci-common.c, so move it to kernel/resource.c > so that it's shared. Later its code also need be updated using list_head > to replace singly

[PATCH v5 1/4] resource: Move reparent_resources() to kernel/resource.c and make it public

reparent_resources() is duplicated in arch/microblaze/pci/pci-common.c and arch/powerpc/kernel/pci-common.c, so move it to kernel/resource.c so that it's shared. Later its code also need be updated using list_head to replace singly linked list. Signed-off-by: Baoquan He Cc: Michal Simek Cc

[PATCH v5 2/4] resource: Use list_head to link sibling resource

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

[PATCH v5 0/4] resource: Use list_head to link sibling resource

is suggested by Andrew. Rewrite walk_system_ram_res_rev() after list_head is taken to link resouce siblings. Baoquan He (4): resource: Move reparent_resources() to kernel/resource.c and make it public resource: Use list_head to link sibling resource resource: add walk_system

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

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

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

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

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

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

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

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

[PATCH v4 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 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 v3 1/3] resource: Use list_head to link sibling resource

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

nux-foundation.org> Signed-off-by: Baoquan He <b...@redhat.com> Cc: Patrik Jakobsson <patrik.r.jakobs...@gmail.com> Cc: David Airlie <airl...@linux.ie> Cc: "K. Y. Srinivasan" <k...@microsoft.com> Cc: Haiyang Zhang <haiya...@microsoft.com> Cc: Stephen Hemminge

Re: KASLR causes intermittent boot failures on some systems

Hi, The root cause has been found out finally. It's caused by code bug in sync_global_pgds which is wrong for loop count calculation. Will post patch. Thanks Baoquan On 04/07/17 at 10:41am, Jeff Moyer wrote: > Hi, > > commit 021182e52fe01 ("x86/mm: Enable KASLR for physical mapping memory >

Re: KASLR causes intermittent boot failures on some systems

On 04/24/17 at 01:52pm, Dan Williams wrote: > On Mon, Apr 24, 2017 at 1:37 PM, Thomas Garnier <thgar...@google.com> wrote: > > ) > > > > On Thu, Apr 20, 2017 at 6:26 AM, Baoquan He <b...@redhat.com> wrote: > >> On 04/19/17 at 07:27am, Thomas Garnier wr

Re: KASLR causes intermittent boot failures on some systems

On 04/19/17 at 07:34am, Dan Williams wrote: > On Wed, Apr 19, 2017 at 7:27 AM, Thomas Garnier <thgar...@google.com> wrote: > > On Wed, Apr 19, 2017 at 6:36 AM, Baoquan He <b...@redhat.com> wrote: > >> Hi all, > >> > >> I login in Jeff's syst

Re: KASLR causes intermittent boot failures on some systems

On 04/19/17 at 07:27am, Thomas Garnier wrote: > On Wed, Apr 19, 2017 at 6:36 AM, Baoquan He <b...@redhat.com> wrote: > > Hi all, > > > > I login in Jeff's system, and added debug code, no clue found. However > > DaveY found he disabled page_offset randomization

Re: KASLR causes intermittent boot failures on some systems

Hi Dan, Thanks! On 04/08/17 at 12:02am, Dan Williams wrote: > > I got below problem when configure ndctl, didn't find a package named > > libkmod: > > > > ~ > > configure: error: Package requirements (libkmod) were not met: > > > > No package 'libkmod' found > > kmod-devel provides that

Re: [PATCH v5] x86: fix kaslr and memmap collision

Add Kees to let him have a look at this too. On 01/05/17 at 05:21pm, Baoquan He wrote: > On 01/04/17 at 11:29am, Dave Jiang wrote: > > CONFIG_RANDOMIZE_BASE relocates the kernel to a random base address. > > However it does not take into account the memmap= parameter passed in from

Re: [PATCH v5] x86: fix kaslr and memmap collision

On 01/04/17 at 11:29am, Dave Jiang wrote: > CONFIG_RANDOMIZE_BASE relocates the kernel to a random base address. > However it does not take into account the memmap= parameter passed in from > the kernel cmdline. This results in the kernel sometimes being put in > the middle of memmap. Teaching

Re: [PATCH v4] x86: fix kaslr and memmap collision

Hi Dave, I have several concerns, please see the inline comments. On 01/03/17 at 01:48pm, Dave Jiang wrote: > CONFIG_RANDOMIZE_BASE relocates the kernel to a random base address. > However it does not take into account the memmap= parameter passed in from > the kernel cmdline. This results in

Re: [PATCH] x86: fix kaslr and memmap collision

On 01/03/17 at 01:15pm, Dave Jiang wrote: > > > On 01/03/2017 11:24 AM, Dan Williams wrote: > > On Tue, Jan 3, 2017 at 12:31 AM, Baoquan He <b...@redhat.com> wrote: > >> Hi Dan, > >> > >> On 11/22/16 at 09:26am, Dan Williams wrote: > >>&g

Re: [PATCH] x86: fix kaslr and memmap collision

Hi Dan, On 11/22/16 at 09:26am, Dan Williams wrote: > [ replying for Dave since he's offline today and tomorrow ] > > On Tue, Nov 22, 2016 at 12:47 AM, Ingo Molnar wrote: > > > > * Dave Jiang wrote: > > > >> CONFIG_RANDOMIZE_BASE relocates the kernel to