kernel/linux.git/drivers/of/fdt.c, branch v5.15.208

of: fdt: fix off-by-one error in unflatten_dt_nodes()

2022-09-23T12:15:46+00:00

[ Upstream commit 2f945a792f67815abca26fa8a5e863ccf3fa1181 ] Commit 78c44d910d3e ("drivers/of: Fix depth when unflattening devicetree") forgot to fix up the depth check in the loop body in unflatten_dt_nodes() which makes it possible to overflow the nps[] buffer... Found by Linux Verification Center (linuxtesting.org) with the SVACE static analysis tool. Fixes: 78c44d910d3e ("drivers/of: Fix depth when unflattening devicetree") Signed-off-by: Sergey Shtylyov Signed-off-by: Rob Herring Link: https://lore.kernel.org/r/7c354554-006f-6b31-c195-cdfe4caee392@omp.ru Signed-off-by: Sasha Levin

of/fdt: declared return type does not match actual return type

2022-08-17T12:23:59+00:00

[ Upstream commit 7913145afa51bbed9eaf8e5b4ee55fa9884a71e5 ] The commit 649cab56de8e (“of: properly check for error returned by fdt_get_name()”) changed the return value type from bool to int, but forgot to change the return value simultaneously. populate_node was only called in unflatten_dt_nodes, and returns with values greater than or equal to 0 were discarded without further processing. Considering that return 0 usually indicates success, return 0 instead of return true. Fixes: 649cab56de8e (“of: properly check for error returned by fdt_get_name()”) Signed-off-by: Xu Qiang Signed-off-by: Rob Herring Link: https://lore.kernel.org/r/20220801120506.11461-2-xuqiang36@huawei.com Signed-off-by: Sasha Levin

of/fdt: Don't worry about non-memory region overlap for no-map

2022-01-27T10:04:20+00:00

[ Upstream commit da17d6905d29ddcdc04b2fdc37ed8cf1e8437cc8 ] In commit 8a5a75e5e9e5 ("of/fdt: Make sure no-map does not remove already reserved regions") we returned -EBUSY when trying to mark regions as no-map when they intersect with reserved memory. The goal was to find bad no-map reserved memory DT nodes that would unmap the kernel text/data sections. The problem is the reserved memory check will still trigger if the DT has a /memreserve/ that completely subsumes the no-map memory carveouts in the reserved memory node _and_ that region is also not part of the memory reg property. For example in sc7180.dtsi we have the following reserved-memory and memory node: memory@80000000 { /* We expect the bootloader to fill in the size */ reg = <0 0x80000000 0 0>; }; smem_mem: memory@80900000 { reg = <0x0 0x80900000 0x0 0x200000>; no-map; }; and the memreserve filled in by the bootloader is /memreserve/ 0x80800000 0x400000; while the /memory node is transformed into memory@80000000 { /* The bootloader fills in the size, and adds another region */ reg = <0 0x80000000 0 0x00800000>, <0 0x80c00000 0 0x7f200000>; }; The smem region is doubly reserved via /memreserve/ and by not being part of the /memory reg property. This leads to the following warning printed at boot. OF: fdt: Reserved memory: failed to reserve memory for node 'memory@80900000': base 0x0000000080900000, size 2 MiB Otherwise nothing really goes wrong because the smem region is not going to be mapped by the kernel's direct linear mapping given that it isn't part of the memory node. Therefore, let's only consider this to be a problem if we're trying to mark a region as no-map and it is actually memory that we're intending to keep out of the kernel's direct mapping but it's already been reserved. Acked-by: Mike Rapoport Cc: Douglas Anderson Cc: Nicolas Boichat Cc: Quentin Perret Cc: Jan Kiszka Fixes: 8a5a75e5e9e5 ("of/fdt: Make sure no-map does not remove already reserved regions") Signed-off-by: Stephen Boyd Signed-off-by: Rob Herring Link: https://lore.kernel.org/r/20220107194233.2793146-1-swboyd@chromium.org Signed-off-by: Sasha Levin

efi: apply memblock cap after memblock_add()

2022-01-27T10:04:15+00:00

[ Upstream commit b398123bff3bcbc1facb0f29bf6e7b9f1bc55931 ] On arm64, during kdump kernel saves vmcore, it runs into the following bug: ... [ 15.148919] usercopy: Kernel memory exposure attempt detected from SLUB object 'kmem_cache_node' (offset 0, size 4096)! [ 15.159707] ------------[ cut here ]------------ [ 15.164311] kernel BUG at mm/usercopy.c:99! [ 15.168482] Internal error: Oops - BUG: 0 [#1] SMP [ 15.173261] Modules linked in: xfs libcrc32c crct10dif_ce ghash_ce sha2_ce sha256_arm64 sha1_ce sbsa_gwdt ast i2c_algo_bit drm_vram_helper drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops cec drm_ttm_helper ttm drm nvme nvme_core xgene_hwmon i2c_designware_platform i2c_designware_core dm_mirror dm_region_hash dm_log dm_mod overlay squashfs zstd_decompress loop [ 15.206186] CPU: 0 PID: 542 Comm: cp Not tainted 5.16.0-rc4 #1 [ 15.212006] Hardware name: GIGABYTE R272-P30-JG/MP32-AR0-JG, BIOS F12 (SCP: 1.5.20210426) 05/13/2021 [ 15.221125] pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 15.228073] pc : usercopy_abort+0x9c/0xa0 [ 15.232074] lr : usercopy_abort+0x9c/0xa0 [ 15.236070] sp : ffff8000121abba0 [ 15.239371] x29: ffff8000121abbb0 x28: 0000000000003000 x27: 0000000000000000 [ 15.246494] x26: 0000000080000400 x25: 0000ffff885c7000 x24: 0000000000000000 [ 15.253617] x23: 000007ff80400000 x22: ffff07ff80401000 x21: 0000000000000001 [ 15.260739] x20: 0000000000001000 x19: ffff07ff80400000 x18: ffffffffffffffff [ 15.267861] x17: 656a626f2042554c x16: 53206d6f72662064 x15: 6574636574656420 [ 15.274983] x14: 74706d6574746120 x13: 2129363930342065 x12: 7a6973202c302074 [ 15.282105] x11: ffffc8b041d1b148 x10: 00000000ffff8000 x9 : ffffc8b04012812c [ 15.289228] x8 : 00000000ffff7fff x7 : ffffc8b041d1b148 x6 : 0000000000000000 [ 15.296349] x5 : 0000000000000000 x4 : 0000000000007fff x3 : 0000000000000000 [ 15.303471] x2 : 0000000000000000 x1 : ffff07ff8c064800 x0 : 000000000000006b [ 15.310593] Call trace: [ 15.313027] usercopy_abort+0x9c/0xa0 [ 15.316677] __check_heap_object+0xd4/0xf0 [ 15.320762] __check_object_size.part.0+0x160/0x1e0 [ 15.325628] __check_object_size+0x2c/0x40 [ 15.329711] copy_oldmem_page+0x7c/0x140 [ 15.333623] read_from_oldmem.part.0+0xfc/0x1c0 [ 15.338142] __read_vmcore.constprop.0+0x23c/0x350 [ 15.342920] read_vmcore+0x28/0x34 [ 15.346309] proc_reg_read+0xb4/0xf0 [ 15.349871] vfs_read+0xb8/0x1f0 [ 15.353088] ksys_read+0x74/0x100 [ 15.356390] __arm64_sys_read+0x28/0x34 ... This bug introduced by commit b261dba2fdb2 ("arm64: kdump: Remove custom linux,usable-memory-range handling"), which moves memblock_cap_memory_range() to fdt, but it breaches the rules that memblock_cap_memory_range() should come after memblock_add() etc as said in commit e888fa7bb882 ("memblock: Check memory add/cap ordering"). As a consequence, the virtual address set up by copy_oldmem_page() does not bail out from the test of virt_addr_valid() in check_heap_object(), and finally hits the BUG_ON(). Since memblock allocator has no idea about when the memblock is fully populated, while efi_init() is aware, so tackling this issue by calling the interface early_init_dt_check_for_usable_mem_range() exposed by of/fdt. Fixes: b261dba2fdb2 ("arm64: kdump: Remove custom linux,usable-memory-range handling") Signed-off-by: Pingfan Liu Cc: Rob Herring Cc: Zhen Lei Cc: Catalin Marinas Cc: Will Deacon Cc: Andrew Morton Cc: Mike Rapoport Cc: Geert Uytterhoeven Cc: Frank Rowand Cc: Ard Biesheuvel Cc: Nick Terrell Cc: linux-arm-kernel@lists.infradead.org To: devicetree@vger.kernel.org To: linux-efi@vger.kernel.org Acked-by: Ard Biesheuvel Signed-off-by: Rob Herring Link: https://lore.kernel.org/r/20211215021348.8766-1-kernelfans@gmail.com Signed-off-by: Sasha Levin

of: fdt: Aggregate the processing of "linux,usable-memory-range"

2022-01-27T10:04:15+00:00

[ Upstream commit 8347b41748c3019157312fbe7f8a6792ae396eb7 ] Currently, we parse the "linux,usable-memory-range" property in early_init_dt_scan_chosen(), to obtain the specified memory range of the crash kernel. We then reserve the required memory after early_init_dt_scan_memory() has identified all available physical memory. Because the two pieces of code are separated far, the readability and maintainability are reduced. So bring them together. Suggested-by: Rob Herring Signed-off-by: Zhen Lei (change the prototype of early_init_dt_check_for_usable_mem_range(), in order to use it outside) Signed-off-by: Pingfan Liu Tested-by: Dave Kleikamp Acked-by: John Donnelly Reviewed-by: Rob Herring Cc: Catalin Marinas Cc: Will Deacon Cc: linux-arm-kernel@lists.infradead.org To: devicetree@vger.kernel.org To: linux-efi@vger.kernel.org Signed-off-by: Rob Herring Signed-off-by: Sasha Levin

of: fdt: Rename reserve_elfcorehdr() to fdt_reserve_elfcorehdr()

2021-08-25T18:13:31+00:00

On ia64/allmodconfig: drivers/of/fdt.c:609:20: error: conflicting types for 'reserve_elfcorehdr'; have 'void(void)' 609 | static void __init reserve_elfcorehdr(void) | ^~~~~~~~~~~~~~~~~~ arch/ia64/include/asm/meminit.h:43:12: note: previous declaration of 'reserve_elfcorehdr' with type 'int(u64 *, u64 *)' {aka 'int(long long unsigned int *, long long unsigned int *)'} 43 | extern int reserve_elfcorehdr(u64 *start, u64 *end); | ^~~~~~~~~~~~~~~~~~ Fix this by prefixing the FDT function name with "fdt_". Fixes: f7e7ce93aac13118 ("of: fdt: Add generic support for handling elf core headers property") Reported-by: kernel test robot Signed-off-by: Geert Uytterhoeven Link: https://lore.kernel.org/r/f6eabbbce0fba6da3da0264c1e1cf23c01173999.1629884393.git.geert+renesas@glider.be Signed-off-by: Rob Herring

of: fdt: Use IS_ENABLED(CONFIG_BLK_DEV_INITRD) instead of #ifdef

2021-08-24T22:09:01+00:00

Replace the conditional compilation using "#ifdef CONFIG_BLK_DEV_INITRD" by a check for "IS_ENABLED(CONFIG_BLK_DEV_INITRD)", to increase compile coverage and to simplify the code. Signed-off-by: Geert Uytterhoeven Signed-off-by: Rob Herring Link: https://lore.kernel.org/r/604c13747f09d800da6a7c12f661e1ec146f1dfd.1628670468.git.geert+renesas@glider.be

of: fdt: Add generic support for handling usable memory range property

2021-08-24T22:09:01+00:00

Add support for handling the "linux,usable-memory-range" property in the "/chosen" node to the FDT core code. This can co-exist safely with the architecture-specific handling, until the latter has been removed. Signed-off-by: Geert Uytterhoeven Signed-off-by: Rob Herring Link: https://lore.kernel.org/r/3bd69bada93ee59b7d23c38b3527fc1654e19343.1628670468.git.geert+renesas@glider.be

of: fdt: Add generic support for handling elf core headers property

2021-08-24T22:09:01+00:00

There are two methods to specify the location of the elf core headers: using the "elfcorehdr=" kernel parameter, as handled by generic code in kernel/crash_dump.c, or using the "linux,elfcorehdr" property under the "/chosen" node in the Device Tree, as handled by architecture-specific code in arch/arm64/mm/init.c. Extend support for "linux,elfcorehdr" to all platforms supporting DT by adding platform-agnostic handling for handling this property to the FDT core code. This can co-exist safely with the architecture-specific handling, until the latter has been removed. This requires moving the call to of_scan_flat_dt() up, as the code scanning the "/chosen" node now needs to be aware of the values of "#address-cells" and "#size-cells". Signed-off-by: Geert Uytterhoeven Signed-off-by: Rob Herring Link: https://lore.kernel.org/r/c7e46e50aaf87ef49bdaa61358d25b122f32b7df.1628670468.git.geert+renesas@glider.be

of: fdt: Remove weak early_init_dt_mark_hotplug_memory_arch()

2021-08-15T14:56:03+00:00

Commit 41a9ada3e6b4253f ("of/fdt: mark hotpluggable memory") introduced two (for systems with and without memblock) weak versions of early_init_dt_mark_hotplug_memory_arch(), that could be overridden by an architecture-specific version. However, no overrides ever emerged. Later, commit aca52c3983891060 ("mm: remove CONFIG_HAVE_MEMBLOCK") removed the non-memblock version. Remove early_init_dt_mark_hotplug_memory_arch(), and replace it by a direct call to memblock_mark_hotplug(). Signed-off-by: Geert Uytterhoeven Link: https://lore.kernel.org/r/1a61f75ec50d3c2922fcdbe33337266a58a4125f.1628671960.git.geert+renesas@glider.be Signed-off-by: Rob Herring