Re: [PATCH] arm: export memblock_reserve()d regions via /proc/iomem
On Mon, Sep 23, 2019 at 11:42:54PM +0800, Yu Chen wrote: > From: Yu Chen > > On Sat, 21 Sep 2019 15:51:38, Russell King - ARM Linux admin wrote: > > On Sat, Sep 21, 2019 at 09:02:49PM +0800, Yu Chen wrote: > > > From: Yu Chen > > > > > > memblock reserved regions are not reported via /proc/iomem on ARM, kexec's > > > user-space doesn't know about memblock_reserve()d regions and thus > > > possible for kexec to overwrite with the new kernel or initrd. > > > > Many reserved regions come from the kernel allocating memory during > > boot. We don't want to prevent kexec re-using those regions. > > > > > [0.00] Booting Linux on physical CPU 0xf00 > > > [0.00] Linux version 4.9.115-rt93-dirty > > > (yuchen@localhost.localdomain) (gcc version 6.2.0 (ZTE Embsys-TSP V3.07.2 > > > 0) ) #62 SMP PREEMPT Fri Sep 20 10:39:29 CST 2019 > > > [0.00] CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7), > > > cr=30c5387d > > > [0.00] CPU: div instructions available: patching division code > > > [0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing > > > instruction cache > > > [0.00] OF: fdt:Machine model: LS1021A TWR Board > > > [0.00] INITRD: 0x80f7f000+0x03695e40 overlaps in-use memory > > > region - disabling initrd > > > > Is the overlapping region one that is marked as reserved in DT? > > the overlapping region is not reserved in DT. > > > Where is the reserved region that overlaps the initrd coming from? > > I found the reserved region that overlaps the initrd is kernel code & data, > with memblock=debug cmdline start new kerne: > > / # kexec -l uImage-ls1021a --ramdisk=ramdisk-ls1021a --dtb=fdt > --append="root=/ > dev/ram0 rw console=ttyS0,115200 earlyprintk memblock=debug" -d > Try gzip decompression. > Try LZMA decompression. > lzma_decompress_file: read on uImage-ls1021a of 65536 bytes failed > kernel: 0xb6c71008 kernel_size: 0x317ab8 > MEMORY RANGES > 8000-bfff (0) > 80003000-80007fff (1) > 80e0-80ff (1) > 810c45a4-810c4fff (1) > 81ac4000-85159fff (1) > 8515a000-8515 (1) > 8800-8b695fff (1) > 8f00-8f004fff (1) > af709000-af7eafff (1) > af7ed000-afffbfff (1) > afffc000-afffcfff (1) > afffd000-afff (1) > bc00-bfff (1) > zImage header: 0x016f2818 0x 0x00317a78 > zImage size 0x317a78, file size 0x317a78 I see nothing here that suggests either a new kexec or a sufficiently new kernel. Hence, kexec lacks all the information to correctly layout the images in physical memory. The kernel was augmented with additional information around the v4.15 time. See commits: c772568788b5 ARM: add additional table to compressed kernel 429f7a062e3b ARM: decompressor: fix BSS size calculation 99cf8f903148 ARM: better diagnostics with missing/corrupt dtb There may be some others also needed, but I forget now, it was two years ago. For kexec, you need at least 2.0.17 (2.0.16 merged the wrong version of one of my patches.) > kexec_load: entry = 0x80008000 flags = 0x28 > nr_segments = 3 > segment[0].buf = 0xb6c71048 > segment[0].bufsz = 0x317a78 > segment[0].mem = 0x80008000 > segment[0].memsz = 0x318000 > segment[1].buf = 0xb35db048 > segment[1].bufsz = 0x3695e40 > segment[1].mem = 0x80f7f000 > segment[1].memsz = 0x3696000 > segment[2].buf = 0x100b108 > segment[2].bufsz = 0x5090 > segment[2].mem = 0x84615000 > segment[2].memsz = 0x6000 > / # kexec -e > [ 126.583598] kexec_core: Starting new kernel > [ 126.587815] Disabling non-boot CPUs ... > [ 126.626917] CPU1: shutdown > [ 126.656344] Retrying again to check for CPU kill > [ 126.660947] CPU1 killed. > [ 126.687585] Bye! > [0.00] Booting Linux on physical CPU 0xf00 > [0.00] Linux version 4.9.115-rt93-CGEL-V6.02.10.R4-dirty > (yuchen@localhost.localdomain) (gcc version 6.2.0 (ZTE Embsys-TSP V3.07.20) ) > #62 SMP PREEMPT Fri Sep 20 10:39:29 CST 2019 > [0.00] CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7), cr=30c5387d > [0.00] CPU: div instructions available: patching division code > [0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing > instruction cache > [0.00] OF: fdt:Machine model: LS1021A TWR Board > [0.00] memblock_reserve: [0x008020-0x00810c45a3] flags > 0x0 arm_memblock_init+0x44/0x23c > [0.00] INITRD: 0x80f7f000+0x03695e40 overlaps in-use memory region - > disabling initrd > [0.00] memblock_reserve: [0x0080003000-0x0080007fff] flags > 0x0 arm_mm_memblock_reserve+0x2c/0x30 > [0.00] memblock_reserve: [0x0084615000-0x008461a08f] flags > 0x0 early_init_dt_reserve_memory_arch+0x24/0x28 > [0.00] memblock_reserve: [0x008f00-0x008f004fff] flags > 0x0 early_init_dt_reserve_memory_a
Re: [PATCH] arm: export memblock_reserve()d regions via /proc/iomem
From: Yu Chen
On Sat, 21 Sep 2019 15:51:38, Russell King - ARM Linux admin wrote:
> On Sat, Sep 21, 2019 at 09:02:49PM +0800, Yu Chen wrote:
> > From: Yu Chen
> >
> > memblock reserved regions are not reported via /proc/iomem on ARM, kexec's
> > user-space doesn't know about memblock_reserve()d regions and thus
> > possible for kexec to overwrite with the new kernel or initrd.
>
> Many reserved regions come from the kernel allocating memory during
> boot. We don't want to prevent kexec re-using those regions.
>
> > [0.00] Booting Linux on physical CPU 0xf00
> > [0.00] Linux version 4.9.115-rt93-dirty
> > (yuchen@localhost.localdomain) (gcc version 6.2.0 (ZTE Embsys-TSP V3.07.2
> > 0) ) #62 SMP PREEMPT Fri Sep 20 10:39:29 CST 2019
> > [0.00] CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7),
> > cr=30c5387d
> > [0.00] CPU: div instructions available: patching division code
> > [0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing
> > instruction cache
> > [0.00] OF: fdt:Machine model: LS1021A TWR Board
> > [0.00] INITRD: 0x80f7f000+0x03695e40 overlaps in-use memory region
> > - disabling initrd
>
> Is the overlapping region one that is marked as reserved in DT?
the overlapping region is not reserved in DT.
> Where is the reserved region that overlaps the initrd coming from?
I found the reserved region that overlaps the initrd is kernel code & data,
with memblock=debug cmdline start new kerne:
/ # kexec -l uImage-ls1021a --ramdisk=ramdisk-ls1021a --dtb=fdt --append="root=/
dev/ram0 rw console=ttyS0,115200 earlyprintk memblock=debug" -d
Try gzip decompression.
Try LZMA decompression.
lzma_decompress_file: read on uImage-ls1021a of 65536 bytes failed
kernel: 0xb6c71008 kernel_size: 0x317ab8
MEMORY RANGES
8000-bfff (0)
80003000-80007fff (1)
80e0-80ff (1)
810c45a4-810c4fff (1)
81ac4000-85159fff (1)
8515a000-8515 (1)
8800-8b695fff (1)
8f00-8f004fff (1)
af709000-af7eafff (1)
af7ed000-afffbfff (1)
afffc000-afffcfff (1)
afffd000-afff (1)
bc00-bfff (1)
zImage header: 0x016f2818 0x 0x00317a78
zImage size 0x317a78, file size 0x317a78
kexec_load: entry = 0x80008000 flags = 0x28
nr_segments = 3
segment[0].buf = 0xb6c71048
segment[0].bufsz = 0x317a78
segment[0].mem = 0x80008000
segment[0].memsz = 0x318000
segment[1].buf = 0xb35db048
segment[1].bufsz = 0x3695e40
segment[1].mem = 0x80f7f000
segment[1].memsz = 0x3696000
segment[2].buf = 0x100b108
segment[2].bufsz = 0x5090
segment[2].mem = 0x84615000
segment[2].memsz = 0x6000
/ # kexec -e
[ 126.583598] kexec_core: Starting new kernel
[ 126.587815] Disabling non-boot CPUs ...
[ 126.626917] CPU1: shutdown
[ 126.656344] Retrying again to check for CPU kill
[ 126.660947] CPU1 killed.
[ 126.687585] Bye!
[0.00] Booting Linux on physical CPU 0xf00
[0.00] Linux version 4.9.115-rt93-CGEL-V6.02.10.R4-dirty
(yuchen@localhost.localdomain) (gcc version 6.2.0 (ZTE Embsys-TSP V3.07.20) )
#62 SMP PREEMPT Fri Sep 20 10:39:29 CST 2019
[0.00] CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7), cr=30c5387d
[0.00] CPU: div instructions available: patching division code
[0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing
instruction cache
[0.00] OF: fdt:Machine model: LS1021A TWR Board
[0.00] memblock_reserve: [0x008020-0x00810c45a3] flags 0x0
arm_memblock_init+0x44/0x23c
[0.00] INITRD: 0x80f7f000+0x03695e40 overlaps in-use memory region -
disabling initrd
[0.00] memblock_reserve: [0x0080003000-0x0080007fff] flags 0x0
arm_mm_memblock_reserve+0x2c/0x30
[0.00] memblock_reserve: [0x0084615000-0x008461a08f] flags 0x0
early_init_dt_reserve_memory_arch+0x24/0x28
[0.00] memblock_reserve: [0x008f00-0x008f004fff] flags 0x0
early_init_dt_reserve_memory_arch+0x24/0x28
[0.00] memblock_reserve: [0x008840-0x008b695e3f] flags 0x0
early_init_dt_reserve_memory_arch+0x24/0x28
[0.00] memblock_reserve: [0x00bc00-0x00bfff] flags 0x0
memblock_alloc_range_nid+0x78/0x90
...
---[ end Kernel panic - not syncing: VFS: Unable to mount root fs on
unknown-block(1,0)
this overlay region is [0x008020-0x00810c45a3]
Corresponding kernel source code:
264 void __init arm_memblock_init(const struct machine_desc *mdesc)
265 {
266 /* Register the kernel text, kernel data and initrd with memblock.
*/
267 memblock_reserve(__pa(KERNEL_START), KERNEL_END - KERNEL_START);
>
> Thanks.
>
> --
> RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
> FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
> According to speedt
Re: [PATCH] arm: export memblock_reserve()d regions via /proc/iomem
Hi Yu,
I love your patch! Yet something to improve:
[auto build test ERROR on arm/for-next]
[cannot apply to v5.3 next-20190920]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]
url:
https://github.com/0day-ci/linux/commits/Yu-Chen/arm-export-memblock_reserve-d-regions-via-proc-iomem/20190921-214007
base: git://git.armlinux.org.uk/~rmk/linux-arm.git for-next
config: arm-ixp4xx_defconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (GCC) 7.4.0
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
GCC_VERSION=7.4.0 make.cross ARCH=arm
:: branch date: 3 hours ago
:: commit date: 3 hours ago
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot
All errors (new ones prefixed by >>):
arch/arm/kernel/setup.c: In function 'reserve_memblock_reserved_regions':
>> arch/arm/kernel/setup.c:918:18: error: 'num_standard_resources' undeclared
>> (first use in this function); did you mean 'request_standard_resources'?
for (i = 0; i < num_standard_resources; ++i) {
^~
request_standard_resources
arch/arm/kernel/setup.c:918:18: note: each undeclared identifier is reported
only once for each function it appears in
>> arch/arm/kernel/setup.c:919:27: error: 'standard_resources' undeclared
>> (first use in this function); did you mean 'num_standard_resources'?
struct resource *mem = &standard_resources[i];
^~
num_standard_resources
#
https://github.com/0day-ci/linux/commit/4d551f57b6f9f07cdff5690f541f76e78c656c68
git remote add linux-review https://github.com/0day-ci/linux
git remote update linux-review
git checkout 4d551f57b6f9f07cdff5690f541f76e78c656c68
vim +918 arch/arm/kernel/setup.c
^1da177e4c3f41 Linus Torvalds 2005-04-16 913
4d551f57b6f9f0 Yu Chen2019-09-21 914 static int __init
reserve_memblock_reserved_regions(void)
4d551f57b6f9f0 Yu Chen2019-09-21 915 {
4d551f57b6f9f0 Yu Chen2019-09-21 916 u64 i, j;
4d551f57b6f9f0 Yu Chen2019-09-21 917
4d551f57b6f9f0 Yu Chen2019-09-21 @918 for (i = 0; i <
num_standard_resources; ++i) {
4d551f57b6f9f0 Yu Chen2019-09-21 @919 struct resource *mem =
&standard_resources[i];
4d551f57b6f9f0 Yu Chen2019-09-21 920 phys_addr_t r_start,
r_end, mem_size = resource_size(mem);
4d551f57b6f9f0 Yu Chen2019-09-21 921
4d551f57b6f9f0 Yu Chen2019-09-21 922 if
(!memblock_is_region_reserved(mem->start, mem_size))
4d551f57b6f9f0 Yu Chen2019-09-21 923 continue;
4d551f57b6f9f0 Yu Chen2019-09-21 924
4d551f57b6f9f0 Yu Chen2019-09-21 925
for_each_reserved_mem_region(j, &r_start, &r_end) {
4d551f57b6f9f0 Yu Chen2019-09-21 926 resource_size_t
start, end;
4d551f57b6f9f0 Yu Chen2019-09-21 927
4d551f57b6f9f0 Yu Chen2019-09-21 928 start =
max(PFN_PHYS(PFN_DOWN(r_start)), mem->start);
4d551f57b6f9f0 Yu Chen2019-09-21 929 end =
min(PFN_PHYS(PFN_UP(r_end)) - 1, mem->end);
4d551f57b6f9f0 Yu Chen2019-09-21 930
4d551f57b6f9f0 Yu Chen2019-09-21 931 if (start >
mem->end || end < mem->start)
4d551f57b6f9f0 Yu Chen2019-09-21 932
continue;
4d551f57b6f9f0 Yu Chen2019-09-21 933
4d551f57b6f9f0 Yu Chen2019-09-21 934
reserve_region_with_split(mem, start, end, "reserved");
4d551f57b6f9f0 Yu Chen2019-09-21 935 }
4d551f57b6f9f0 Yu Chen2019-09-21 936 }
4d551f57b6f9f0 Yu Chen2019-09-21 937
4d551f57b6f9f0 Yu Chen2019-09-21 938 return 0;
4d551f57b6f9f0 Yu Chen2019-09-21 939 }
4d551f57b6f9f0 Yu Chen2019-09-21 940
arch_initcall(reserve_memblock_reserved_regions);
4d551f57b6f9f0 Yu Chen2019-09-21 941
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
Re: [PATCH] arm: export memblock_reserve()d regions via /proc/iomem
On Sat, Sep 21, 2019 at 09:02:49PM +0800, Yu Chen wrote: > From: Yu Chen > > memblock reserved regions are not reported via /proc/iomem on ARM, kexec's > user-space doesn't know about memblock_reserve()d regions and thus > possible for kexec to overwrite with the new kernel or initrd. Many reserved regions come from the kernel allocating memory during boot. We don't want to prevent kexec re-using those regions. > [ 0.00] Booting Linux on physical CPU 0xf00 > [ 0.00] Linux version 4.9.115-rt93-dirty > (yuchen@localhost.localdomain) (gcc version 6.2.0 (ZTE Embsys-TSP V3.07.2 > 0) ) #62 SMP PREEMPT Fri Sep 20 10:39:29 CST 2019 > [ 0.00] CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7), cr=30c5387d > [ 0.00] CPU: div instructions available: patching division code > [ 0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing > instruction cache > [ 0.00] OF: fdt:Machine model: LS1021A TWR Board > [ 0.00] INITRD: 0x80f7f000+0x03695e40 overlaps in-use memory region - > disabling initrd Is the overlapping region one that is marked as reserved in DT? Where is the reserved region that overlaps the initrd coming from? Thanks. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up According to speedtest.net: 11.9Mbps down 500kbps up
