Revision tags: v6.6.25, v6.6.24, v6.6.23, v6.6.16, v6.6.15, v6.6.14, v6.6.13, v6.6.12, v6.6.11, v6.6.10, v6.6.9, v6.6.8, v6.6.7, v6.6.6, v6.6.5, v6.6.4, v6.6.3, v6.6.2, v6.5.11, v6.6.1, v6.5.10, v6.6, v6.5.9, v6.5.8, v6.5.7, v6.5.6, v6.5.5, v6.5.4, v6.5.3, v6.5.2, v6.1.51, v6.5.1, v6.1.50, v6.5, v6.1.49, v6.1.48, v6.1.46, v6.1.45, v6.1.44, v6.1.43, v6.1.42, v6.1.41, v6.1.40, v6.1.39, v6.1.38, v6.1.37, v6.1.36, v6.4, v6.1.35, v6.1.34, v6.1.33, v6.1.32, v6.1.31, v6.1.30, v6.1.29, v6.1.28, v6.1.27, v6.1.26 |
|
#
b4132818 |
| 24-Apr-2023 |
Lucas Tanure <tanure@linux.com> |
of: fdt: Scan /memreserve/ last
Change the scanning /memreserve/ and /reserved-memory node order to fix Kernel panic on Khadas Vim3 Board.
If /memreserve/ goes first, the memory is reserved, but no
of: fdt: Scan /memreserve/ last
Change the scanning /memreserve/ and /reserved-memory node order to fix Kernel panic on Khadas Vim3 Board.
If /memreserve/ goes first, the memory is reserved, but nomap can't be applied to the region. So the memory won't be used by Linux, but it is still present in the linear map as normal memory, which allows speculation. Legitimate access to adjacent pages will cause the CPU to end up prefetching into them leading to Kernel panic.
So /reserved-memory node should go first, as it has a more updated description of the memory regions and can apply flags, like nomap.
Link: https://lore.kernel.org/all/CAJX_Q+1Tjc+-TjZ6JW9X0NxEdFe=82a9626yL63j7uVD4LpxEA@mail.gmail.com/ Signed-off-by: Lucas Tanure <tanure@linux.com> Link: https://lore.kernel.org/r/20230424113846.46382-1-tanure@linux.com Signed-off-by: Rob Herring <robh@kernel.org>
show more ...
|
Revision tags: v6.3, v6.1.25, v6.1.24, v6.1.23, v6.1.22 |
|
#
3335068f |
| 24-Mar-2023 |
Alexandre Ghiti <alexghiti@rivosinc.com> |
riscv: Use PUD/P4D/PGD pages for the linear mapping
During the early page table creation, we used to set the mapping for PAGE_OFFSET to the kernel load address: but the kernel load address is always
riscv: Use PUD/P4D/PGD pages for the linear mapping
During the early page table creation, we used to set the mapping for PAGE_OFFSET to the kernel load address: but the kernel load address is always offseted by PMD_SIZE which makes it impossible to use PUD/P4D/PGD pages as this physical address is not aligned on PUD/P4D/PGD size (whereas PAGE_OFFSET is).
But actually we don't have to establish this mapping (ie set va_pa_offset) that early in the boot process because:
- first, setup_vm installs a temporary kernel mapping and among other things, discovers the system memory, - then, setup_vm_final creates the final kernel mapping and takes advantage of the discovered system memory to create the linear mapping.
During the first phase, we don't know the start of the system memory and then until the second phase is finished, we can't use the linear mapping at all and phys_to_virt/virt_to_phys translations must not be used because it would result in a different translation from the 'real' one once the final mapping is installed.
So here we simply delay the initialization of va_pa_offset to after the system memory discovery. But to make sure noone uses the linear mapping before, we add some guard in the DEBUG_VIRTUAL config.
Finally we can use PUD/P4D/PGD hugepages when possible, which will result in a better TLB utilization.
Note that: - this does not apply to rv32 as the kernel mapping lies in the linear mapping. - we rely on the firmware to protect itself using PMP.
Signed-off-by: Alexandre Ghiti <alexghiti@rivosinc.com> Acked-by: Rob Herring <robh@kernel.org> # DT bits Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Reviewed-by: Anup Patel <anup@brainfault.org> Tested-by: Anup Patel <anup@brainfault.org> Link: https://lore.kernel.org/r/20230324155421.271544-4-alexghiti@rivosinc.com Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
show more ...
|
Revision tags: v6.1.21, v6.1.20, v6.1.19, v6.1.18, v6.1.17, v6.1.16, v6.1.15, v6.1.14, v6.1.13, v6.2, v6.1.12, v6.1.11, v6.1.10, v6.1.9 |
|
#
8ef852f1 |
| 24-Jan-2023 |
Isaac J. Manjarres <isaacmanjarres@google.com> |
Revert "mm: kmemleak: alloc gray object for reserved region with direct map"
This reverts commit 972fa3a7c17c9d60212e32ecc0205dc585b1e769.
Kmemleak operates by periodically scanning memory regions
Revert "mm: kmemleak: alloc gray object for reserved region with direct map"
This reverts commit 972fa3a7c17c9d60212e32ecc0205dc585b1e769.
Kmemleak operates by periodically scanning memory regions for pointers to allocated memory blocks to determine if they are leaked or not. However, reserved memory regions can be used for DMA transactions between a device and a CPU, and thus, wouldn't contain pointers to allocated memory blocks, making them inappropriate for kmemleak to scan. Thus, revert this commit.
Link: https://lkml.kernel.org/r/20230124230254.295589-1-isaacmanjarres@google.com Fixes: 972fa3a7c17c9 ("mm: kmemleak: alloc gray object for reserved region with direct map") Signed-off-by: Isaac J. Manjarres <isaacmanjarres@google.com> Acked-by: Catalin Marinas <catalin.marinas@arm.com> Cc: Calvin Zhang <calvinzhang.cool@gmail.com> Cc: Frank Rowand <frowand.list@gmail.com> Cc: Rob Herring <robh+dt@kernel.org> Cc: Saravana Kannan <saravanak@google.com> Cc: <stable@vger.kernel.org> [5.17+] Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
show more ...
|
Revision tags: v6.1.8, v6.1.7, v6.1.6, v6.1.5, v6.0.19, v6.0.18, v6.1.4, v6.1.3, v6.0.17 |
|
#
064e32dc |
| 03-Jan-2023 |
Rob Herring <robh@kernel.org> |
of: fdt: Honor CONFIG_CMDLINE* even without /chosen node, take 2
I do not read a strict requirement on /chosen node in either ePAPR or in Documentation/devicetree. Help text for CONFIG_CMDLINE and C
of: fdt: Honor CONFIG_CMDLINE* even without /chosen node, take 2
I do not read a strict requirement on /chosen node in either ePAPR or in Documentation/devicetree. Help text for CONFIG_CMDLINE and CONFIG_CMDLINE_EXTEND doesn't make their behavior explicitly dependent on the presence of /chosen or the presense of /chosen/bootargs.
However the early check for /chosen and bailing out in early_init_dt_scan_chosen() skips CONFIG_CMDLINE handling which is not really related to /chosen node or the particular method of passing cmdline from bootloader.
This leads to counterintuitive combinations (assuming CONFIG_CMDLINE_EXTEND=y):
a) bootargs="foo", CONFIG_CMDLINE="bar" => cmdline=="foo bar" b) /chosen missing, CONFIG_CMDLINE="bar" => cmdline=="" c) bootargs="", CONFIG_CMDLINE="bar" => cmdline==" bar"
Rework early_init_dt_scan_chosen() so that the cmdline config options are always handled.
[commit msg written by Alexander Sverdlin]
Cc: Alexander Sverdlin <alexander.sverdlin@gmail.com> Cc: Linus Walleij <linus.walleij@linaro.org> Cc: Arnd Bergmann <arnd@arndb.de> Tested-by: Geoff Levand <geoff@infradead.org> Reviewed-by: Alexander Sverdlin <alexander.sverdlin@gmail.com> Link: https://lore.kernel.org/r/20230103-dt-cmdline-fix-v1-2-7038e88b18b6@kernel.org Signed-off-by: Rob Herring <robh@kernel.org>
show more ...
|
#
bd0ddcfc |
| 03-Jan-2023 |
Rob Herring <robh@kernel.org> |
Revert "of: fdt: Honor CONFIG_CMDLINE* even without /chosen node"
This reverts commit a7d550f82b445cf218b47a2c1a9c56e97ecb8c7a.
Some arches (PPC at least) don't call early_init_dt_scan_nodes(), so
Revert "of: fdt: Honor CONFIG_CMDLINE* even without /chosen node"
This reverts commit a7d550f82b445cf218b47a2c1a9c56e97ecb8c7a.
Some arches (PPC at least) don't call early_init_dt_scan_nodes(), so moving the cmdline processing there breaks them.
Reported-by: Geoff Levand <geoff@infradead.org> Cc: Alexander Sverdlin <alexander.sverdlin@gmail.com> Tested-by: Geoff Levand <geoff@infradead.org> Reviewed-by: Alexander Sverdlin <alexander.sverdlin@gmail.com> Link: https://lore.kernel.org/r/20230103-dt-cmdline-fix-v1-1-7038e88b18b6@kernel.org Signed-off-by: Rob Herring <robh@kernel.org>
show more ...
|
Revision tags: v6.1.2, v6.0.16 |
|
#
2a12187d |
| 23-Dec-2022 |
Andreas Rammhold <andreas@rammhold.de> |
of/fdt: run soc memory setup when early_init_dt_scan_memory fails
If memory has been found early_init_dt_scan_memory now returns 1. If it hasn't found any memory it will return 0, allowing other mem
of/fdt: run soc memory setup when early_init_dt_scan_memory fails
If memory has been found early_init_dt_scan_memory now returns 1. If it hasn't found any memory it will return 0, allowing other memory setup mechanisms to carry on.
Previously early_init_dt_scan_memory always returned 0 without distinguishing between any kind of memory setup being done or not. Any code path after the early_init_dt_scan memory call in the ramips plat_mem_setup code wouldn't be executed anymore. Making early_init_dt_scan_memory the only way to initialize the memory.
Some boards, including my mt7621 based Cudy X6 board, depend on memory initialization being done via the soc_info.mem_detect function pointer. Those wouldn't be able to obtain memory and panic the kernel during early bootup with the message "early_init_dt_alloc_memory_arch: Failed to allocate 12416 bytes align=0x40".
Fixes: 1f012283e936 ("of/fdt: Rework early_init_dt_scan_memory() to call directly") Cc: stable@vger.kernel.org Signed-off-by: Andreas Rammhold <andreas@rammhold.de> Link: https://lore.kernel.org/r/20221223112748.2935235-1-andreas@rammhold.de Signed-off-by: Rob Herring <robh@kernel.org>
show more ...
|
Revision tags: v6.1.1, v6.0.15, v6.0.14, v6.0.13 |
|
#
a7d550f8 |
| 11-Dec-2022 |
Alexander Sverdlin <alexander.sverdlin@gmail.com> |
of: fdt: Honor CONFIG_CMDLINE* even without /chosen node
I do not read a strict requirement on /chosen node in either ePAPR or in Documentation/devicetree. Help text for CONFIG_CMDLINE and CONFIG_CM
of: fdt: Honor CONFIG_CMDLINE* even without /chosen node
I do not read a strict requirement on /chosen node in either ePAPR or in Documentation/devicetree. Help text for CONFIG_CMDLINE and CONFIG_CMDLINE_EXTEND doesn't make their behavior explicitly dependent on the presence of /chosen or the presense of /chosen/bootargs.
However the early check for /chosen and bailing out in early_init_dt_scan_chosen() skips CONFIG_CMDLINE handling which is not really related to /chosen node or the particular method of passing cmdline from bootloader.
This leads to counterintuitive combinations (assuming CONFIG_CMDLINE_EXTEND=y):
a) bootargs="foo", CONFIG_CMDLINE="bar" => cmdline=="foo bar" b) /chosen missing, CONFIG_CMDLINE="bar" => cmdline=="" c) bootargs="", CONFIG_CMDLINE="bar" => cmdline==" bar"
Move CONFIG_CMDLINE handling outside of early_init_dt_scan_chosen() so that cases b and c above result in the same cmdline.
Signed-off-by: Alexander Sverdlin <alexander.sverdlin@gmail.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Arnd Bergmann <arnd@arndb.de> Link: https://lore.kernel.org/r/11af73e05bad75e4ef49067515e3214f6d944b3d.camel@gmail.com Signed-off-by: Rob Herring <robh@kernel.org>
show more ...
|
Revision tags: v6.1, v6.0.12, v6.0.11, v6.0.10, v5.15.80, v6.0.9, v5.15.79, v6.0.8, v5.15.78, v6.0.7, v5.15.77, v5.15.76, v6.0.6, v6.0.5, v5.15.75, v6.0.4, v6.0.3, v6.0.2, v5.15.74, v5.15.73, v6.0.1, v5.15.72, v6.0, v5.15.71 |
|
#
17005609 |
| 27-Sep-2022 |
Yuan Can <yuancan@huawei.com> |
of: fdt: Remove unused struct fdt_scan_status
After commit bba04d965d06("of/fdt: remove unused of_scan_flat_dt_by_path"), no one use struct fdt_scan_status, so remove it.
Signed-off-by: Yuan Can <y
of: fdt: Remove unused struct fdt_scan_status
After commit bba04d965d06("of/fdt: remove unused of_scan_flat_dt_by_path"), no one use struct fdt_scan_status, so remove it.
Signed-off-by: Yuan Can <yuancan@huawei.com> Reviewed-by: Frank Rowand <frank.rowand@sony.com> Link: https://lore.kernel.org/r/20220927133739.98493-1-yuancan@huawei.com Signed-off-by: Rob Herring <robh@kernel.org>
show more ...
|
Revision tags: v5.15.70, v5.15.69, v5.15.68 |
|
#
d5e3050c |
| 08-Sep-2022 |
Marek Bykowski <marek.bykowski@gmail.com> |
of/fdt: Don't calculate initrd size from DT if start > end
If the properties 'linux,initrd-start' and 'linux,initrd-end' of the chosen node populated from the bootloader, eg. U-Boot, are so that sta
of/fdt: Don't calculate initrd size from DT if start > end
If the properties 'linux,initrd-start' and 'linux,initrd-end' of the chosen node populated from the bootloader, eg. U-Boot, are so that start > end, then the phys_initrd_size calculated from end - start is negative that subsequently gets converted to a high positive value for being unsigned long long. Then, the memory region with the (invalid) size is added to the bootmem and attempted being paged in paging_init() that results in the kernel fault.
For example, on the FVP ARM64 system I'm running, the U-Boot populates the 'linux,initrd-start' with 8800_0000 and 'linux,initrd-end' with 0. The phys_initrd_size calculated is then ffff_ffff_7800_0000 (= 0 - 8800_0000 = -8800_0000 + ULLONG_MAX + 1). paging_init() then attempts to map the address 8800_0000 + ffff_ffff_7800_0000 and oops'es as below.
It should be stressed, it is generally a fault of the bootloader's with the kernel relying on it, however we should not allow the bootloader's misconfiguration to lead to the kernel oops. Not only the kernel should be bullet proof against it but also finding the root cause of the paging fault spanning over the bootloader, DT, and kernel may happen is not so easy.
Unable to handle kernel paging request at virtual address fffffffefe43c000 Mem abort info: ESR = 0x96000007 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 Data abort info: ISV = 0, ISS = 0x00000007 CM = 0, WnR = 0 swapper pgtable: 4k pages, 39-bit VAs, pgdp=0000000080e3d000 [fffffffefe43c000] pgd=0000000080de9003, pud=0000000080de9003 Unable to handle kernel paging request at virtual address ffffff8000de9f90 Mem abort info: ESR = 0x96000005 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 Data abort info: ISV = 0, ISS = 0x00000005 CM = 0, WnR = 0 swapper pgtable: 4k pages, 39-bit VAs, pgdp=0000000080e3d000 [ffffff8000de9f90] pgd=0000000000000000, pud=0000000000000000 Internal error: Oops: 96000005 [#1] PREEMPT SMP Modules linked in: CPU: 0 PID: 0 Comm: swapper Not tainted 5.4.51-yocto-standard #1 Hardware name: FVP Base (DT) pstate: 60000085 (nZCv daIf -PAN -UAO) pc : show_pte+0x12c/0x1b4 lr : show_pte+0x100/0x1b4 sp : ffffffc010ce3b30 x29: ffffffc010ce3b30 x28: ffffffc010ceed80 x27: fffffffefe43c000 x26: fffffffefe43a028 x25: 0000000080bf0000 x24: 0000000000000025 x23: ffffffc010b8d000 x22: ffffffc010e3d000 x23: ffffffc010b8d000 x22: ffffffc010e3d000 x21: 0000000080de9000 x20: ffffff7f80000f90 x19: fffffffefe43c000 x18: 0000000000000030 x17: 0000000000001400 x16: 0000000000001c00 x15: ffffffc010cef1b8 x14: ffffffffffffffff x13: ffffffc010df1f40 x12: ffffffc010df1b70 x11: ffffffc010ce3b30 x10: ffffffc010ce3b30 x9 : 00000000ffffffc8 x8 : 0000000000000000 x7 : 000000000000000f x6 : ffffffc010df16e8 x5 : 0000000000000000 x4 : 0000000000000000 x3 : 00000000ffffffff x2 : 0000000000000000 x1 : 0000008080000000 x0 : ffffffc010af1d68 Call trace: show_pte+0x12c/0x1b4 die_kernel_fault+0x54/0x78 __do_kernel_fault+0x11c/0x128 do_translation_fault+0x58/0xac do_mem_abort+0x50/0xb0 el1_da+0x1c/0x90 __create_pgd_mapping+0x348/0x598 paging_init+0x3f0/0x70d0 setup_arch+0x2c0/0x5d4 start_kernel+0x94/0x49c Code: 92748eb5 900052a0 9135a000 cb010294 (f8756a96)
Signed-off-by: Marek Bykowski <marek.bykowski@gmail.com> Link: https://lore.kernel.org/r/20220909023358.76881-1-marek.bykowski@gmail.com Signed-off-by: Rob Herring <robh@kernel.org>
show more ...
|
Revision tags: v5.15.67, v5.15.66, v5.15.65, v5.15.64, v5.15.63, v5.15.62 |
|
#
7a12dd07 |
| 18-Aug-2022 |
Wolfram Sang <wsa+renesas@sang-engineering.com> |
of: move from strlcpy with unused retval to strscpy
Follow the advice of the below link and prefer 'strscpy' in this subsystem. Conversion is 1:1 because the return value is not used. Generated by a
of: move from strlcpy with unused retval to strscpy
Follow the advice of the below link and prefer 'strscpy' in this subsystem. Conversion is 1:1 because the return value is not used. Generated by a coccinelle script.
Link: https://lore.kernel.org/r/CAHk-=wgfRnXz0W3D37d01q3JFkr_i_uTL=V6A6G1oUZcprmknw@mail.gmail.com/ Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Signed-off-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20220818210054.7157-1-wsa+renesas@sang-engineering.com
show more ...
|
Revision tags: v5.15.61 |
|
#
2f945a79 |
| 13-Aug-2022 |
Sergey Shtylyov <s.shtylyov@omp.ru> |
of: fdt: fix off-by-one error in unflatten_dt_nodes()
Commit 78c44d910d3e ("drivers/of: Fix depth when unflattening devicetree") forgot to fix up the depth check in the loop body in unflatten_dt_nod
of: fdt: fix off-by-one error in unflatten_dt_nodes()
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 <s.shtylyov@omp.ru> Signed-off-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/7c354554-006f-6b31-c195-cdfe4caee392@omp.ru
show more ...
|
Revision tags: v5.15.60, v5.15.59 |
|
#
7913145a |
| 01-Aug-2022 |
Xu Qiang <xuqiang36@huawei.com> |
of/fdt: declared return type does not match actual return type
The commit 649cab56de8e (“of: properly check for error returned by fdt_get_name()”) changed the return value type from bool to int, but
of/fdt: declared return type does not match actual return type
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 <xuqiang36@huawei.com> Signed-off-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20220801120506.11461-2-xuqiang36@huawei.com
show more ...
|
Revision tags: v5.19, v5.15.58, v5.15.57 |
|
#
f8a855ed |
| 22-Jul-2022 |
Peter Collingbourne <pcc@google.com> |
of/fdt: Clean up early_init_dt_reserve_memory_arch()
As of commit 18250b43f7b6 ("of: fdt: Remove early_init_dt_reserve_memory_arch() override capability") this is no longer an arch hook, so rename i
of/fdt: Clean up early_init_dt_reserve_memory_arch()
As of commit 18250b43f7b6 ("of: fdt: Remove early_init_dt_reserve_memory_arch() override capability") this is no longer an arch hook, so rename it to remove the confusing _arch suffix. Also remove some unnecessary indirection from all but one of the callers by calling memblock_reserve() directly instead.
Signed-off-by: Peter Collingbourne <pcc@google.com> Link: https://linux-review.googlesource.com/id/I3362bdd92ae6e47e8f5bac01aa228d32f9d01aad Signed-off-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20220723015331.1607029-1-pcc@google.com
show more ...
|
Revision tags: v5.15.56, v5.15.55, v5.15.54, v5.15.53, v5.15.52, v5.15.51 |
|
#
65e20e8c |
| 28-Jun-2022 |
Michael Walle <michael@walle.cc> |
earlycon: prevent multiple register_console()
If the earlycon parameter is given twice, the kernel will spit out a WARN() in register_console() because it was already registered. The non-dt variant
earlycon: prevent multiple register_console()
If the earlycon parameter is given twice, the kernel will spit out a WARN() in register_console() because it was already registered. The non-dt variant setup_earlycon() already handles that gracefully. The dt variant of_setup_earlycon() doesn't. Add the check there and add the -EALREADY handling in early_init_dt_scan_chosen_stdout().
FWIW, this doesn't happen if CONFIG_ACPI_SPCR_TABLE is set. In that case the registration is delayed until after earlycon parameter(s) are parsed.
Reviewed-by: Rob Herring <robh@kernel.org> Signed-off-by: Michael Walle <michael@walle.cc> Link: https://lore.kernel.org/r/20220628120705.200617-1-michael@walle.cc Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
#
6991cd74 |
| 28-Jun-2022 |
Vincent Whitchurch <vincent.whitchurch@axis.com> |
of: reserved-memory: Print allocation/reservation failures as error
If the allocation/reservation of reserved-memory fails, it is normally an error, so print it as an error so that it doesn't get hi
of: reserved-memory: Print allocation/reservation failures as error
If the allocation/reservation of reserved-memory fails, it is normally an error, so print it as an error so that it doesn't get hidden from the console due to the loglevel. Also make the allocation failure include the size just like the reservation failure.
Signed-off-by: Vincent Whitchurch <vincent.whitchurch@axis.com> Signed-off-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20220628113540.2790835-1-vincent.whitchurch@axis.com
show more ...
|
Revision tags: v5.15.50, v5.15.49, v5.15.48, v5.15.47 |
|
#
c200d900 |
| 10-Jun-2022 |
Patrick Wang <patrick.wang.shcn@gmail.com> |
mm: kmemleak: remove kmemleak_not_leak_phys() and the min_count argument to kmemleak_alloc_phys()
Patch series "mm: kmemleak: store objects allocated with physical address separately and check when
mm: kmemleak: remove kmemleak_not_leak_phys() and the min_count argument to kmemleak_alloc_phys()
Patch series "mm: kmemleak: store objects allocated with physical address separately and check when scan", v4.
The kmemleak_*_phys() interface uses "min_low_pfn" and "max_low_pfn" to check address. But on some architectures, kmemleak_*_phys() is called before those two variables initialized. The following steps will be taken:
1) Add OBJECT_PHYS flag and rbtree for the objects allocated with physical address 2) Store physical address in objects if allocated with OBJECT_PHYS 3) Check the boundary when scan instead of in kmemleak_*_phys()
This patch set will solve: https://lore.kernel.org/r/20220527032504.30341-1-yee.lee@mediatek.com https://lore.kernel.org/r/9dd08bb5-f39e-53d8-f88d-bec598a08c93@gmail.com
v3: https://lore.kernel.org/r/20220609124950.1694394-1-patrick.wang.shcn@gmail.com v2: https://lore.kernel.org/r/20220603035415.1243913-1-patrick.wang.shcn@gmail.com v1: https://lore.kernel.org/r/20220531150823.1004101-1-patrick.wang.shcn@gmail.com
This patch (of 4):
Remove the unused kmemleak_not_leak_phys() function. And remove the min_count argument to kmemleak_alloc_phys() function, assume it's 0.
Link: https://lkml.kernel.org/r/20220611035551.1823303-1-patrick.wang.shcn@gmail.com Link: https://lkml.kernel.org/r/20220611035551.1823303-2-patrick.wang.shcn@gmail.com Signed-off-by: Patrick Wang <patrick.wang.shcn@gmail.com> Suggested-by: Catalin Marinas <catalin.marinas@arm.com> Reviewed-by: Catalin Marinas <catalin.marinas@arm.com> Cc: Yee Lee <yee.lee@mediatek.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
show more ...
|
Revision tags: v5.15.46, v5.15.45, v5.15.44, v5.15.43, v5.15.42, v5.18, v5.15.41 |
|
#
df5cd369 |
| 17-May-2022 |
Andre Przywara <andre.przywara@arm.com> |
of/fdt: Ignore disabled memory nodes
When we boot a machine using a devicetree, the generic DT code goes through all nodes with a 'device_type = "memory"' property, and collects all memory banks men
of/fdt: Ignore disabled memory nodes
When we boot a machine using a devicetree, the generic DT code goes through all nodes with a 'device_type = "memory"' property, and collects all memory banks mentioned there. However it does not check for the status property, so any nodes which are explicitly "disabled" will still be added as a memblock. This ends up badly for QEMU, when booting with secure firmware on arm/arm64 machines, because QEMU adds a node describing secure-only memory: =================== secram@e000000 { secure-status = "okay"; status = "disabled"; reg = <0x00 0xe000000 0x00 0x1000000>; device_type = "memory"; }; ===================
The kernel will eventually use that memory block (which is located below the main DRAM bank), but accesses to that will be answered with an SError: =================== [ 0.000000] Internal error: synchronous external abort: 96000050 [#1] PREEMPT SMP [ 0.000000] Modules linked in: [ 0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 5.18.0-rc6-00014-g10c8acb8b679 #524 [ 0.000000] Hardware name: linux,dummy-virt (DT) [ 0.000000] pstate: 200000c5 (nzCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 0.000000] pc : new_slab+0x190/0x340 [ 0.000000] lr : new_slab+0x184/0x340 [ 0.000000] sp : ffff80000a4b3d10 .... ================== The actual crash location and call stack will be somewhat random, and depend on the specific allocation of that physical memory range.
As the DT spec[1] explicitly mentions standard properties, add a simple check to skip over disabled memory nodes, so that we only use memory that is meant for non-secure code to use.
That fixes booting a QEMU arm64 VM with EL3 enabled ("secure=on"), when not using UEFI. In this case the QEMU generated DT will be handed on to the kernel, which will see the secram node. This issue is reproducible when using TF-A together with U-Boot as firmware, then booting with the "booti" command.
When using U-Boot as an UEFI provider, the code there [2] explicitly filters for disabled nodes when generating the UEFI memory map, so we are safe. EDK/2 only reads the first bank of the first DT memory node [3] to learn about memory, so we got lucky there.
[1] https://github.com/devicetree-org/devicetree-specification/blob/main/source/chapter3-devicenodes.rst#memory-node (after the table) [2] https://source.denx.de/u-boot/u-boot/-/blob/master/lib/fdtdec.c#L1061-1063 [3] https://github.com/tianocore/edk2/blob/master/ArmVirtPkg/PrePi/FdtParser.c
Reported-by: Ross Burton <ross.burton@arm.com> Signed-off-by: Andre Przywara <andre.przywara@arm.com> Signed-off-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20220517101410.3493781-1-andre.przywara@arm.com
show more ...
|
Revision tags: v5.15.40, v5.15.39, v5.15.38 |
|
#
fb319e77 |
| 06-May-2022 |
Chen Zhou <chenzhou10@huawei.com> |
of: fdt: Add memory for devices by DT property "linux,usable-memory-range"
When reserving crashkernel in high memory, some low memory is reserved for crash dump kernel devices and never mapped by th
of: fdt: Add memory for devices by DT property "linux,usable-memory-range"
When reserving crashkernel in high memory, some low memory is reserved for crash dump kernel devices and never mapped by the first kernel. This memory range is advertised to crash dump kernel via DT property under /chosen, linux,usable-memory-range = <BASE1 SIZE1 [BASE2 SIZE2]>
We reused the DT property linux,usable-memory-range and made the low memory region as the second range "BASE2 SIZE2", which keeps compatibility with existing user-space and older kdump kernels.
Crash dump kernel reads this property at boot time and call memblock_add() to add the low memory region after memblock_cap_memory_range() has been called.
Signed-off-by: Chen Zhou <chenzhou10@huawei.com> Co-developed-by: Zhen Lei <thunder.leizhen@huawei.com> Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com> Reviewed-by: Rob Herring <robh@kernel.org> Tested-by: Dave Kleikamp <dave.kleikamp@oracle.com> Acked-by: Baoquan He <bhe@redhat.com> Link: https://lore.kernel.org/r/20220506114402.365-5-thunder.leizhen@huawei.com Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
show more ...
|
Revision tags: v5.15.37, v5.15.36, v5.15.35, v5.15.34, v5.15.33, v5.15.32, v5.15.31, v5.17, v5.15.30, v5.15.29, v5.15.28, v5.15.27, v5.15.26, v5.15.25, v5.15.24, v5.15.23, v5.15.22, v5.15.21, v5.15.20, v5.15.19, v5.15.18 |
|
#
132507ed |
| 27-Jan-2022 |
Nikhil Gupta <nikhil.gupta@nxp.com> |
of/fdt: move elfcorehdr reservation early for crash dump kernel
elfcorehdr_addr is fixed address passed to Second kernel which may be conflicted with potential reserved memory in Second kernel,so fd
of/fdt: move elfcorehdr reservation early for crash dump kernel
elfcorehdr_addr is fixed address passed to Second kernel which may be conflicted with potential reserved memory in Second kernel,so fdt_reserve_elfcorehdr() ahead of fdt_init_reserved_mem() can relieve this situation.
Signed-off-by: Nikhil Gupta <nikhil.gupta@nxp.com> Signed-off-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20220128042321.15228-1-nikhil.gupta@nxp.com
show more ...
|
Revision tags: v5.15.17, v5.4.173, v5.15.16, v5.15.15 |
|
#
972fa3a7 |
| 14-Jan-2022 |
Calvin Zhang <calvinzhang.cool@gmail.com> |
mm: kmemleak: alloc gray object for reserved region with direct map
Reserved regions with direct mapping may contain references to other regions. CMA region with fixed location is reserved without
mm: kmemleak: alloc gray object for reserved region with direct map
Reserved regions with direct mapping may contain references to other regions. CMA region with fixed location is reserved without creating kmemleak_object for it.
So add them as gray kmemleak objects.
Link: https://lkml.kernel.org/r/20211123090641.3654006-1-calvinzhang.cool@gmail.com Signed-off-by: Calvin Zhang <calvinzhang.cool@gmail.com> Cc: Rob Herring <robh+dt@kernel.org> Cc: Frank Rowand <frowand.list@gmail.com> Cc: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
show more ...
|
Revision tags: v5.16 |
|
#
da17d690 |
| 07-Jan-2022 |
Stephen Boyd <swboyd@chromium.org> |
of/fdt: Don't worry about non-memory region overlap for no-map
In commit 8a5a75e5e9e5 ("of/fdt: Make sure no-map does not remove already reserved regions") we returned -EBUSY when trying to mark reg
of/fdt: Don't worry about non-memory region overlap for no-map
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 <rppt@kernel.org> Cc: Douglas Anderson <dianders@chromium.org> Cc: Nicolas Boichat <drinkcat@chromium.org> Cc: Quentin Perret <qperret@google.com> Cc: Jan Kiszka <jan.kiszka@siemens.com> Fixes: 8a5a75e5e9e5 ("of/fdt: Make sure no-map does not remove already reserved regions") Signed-off-by: Stephen Boyd <swboyd@chromium.org> Signed-off-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20220107194233.2793146-1-swboyd@chromium.org
show more ...
|
Revision tags: v5.15.10, v5.15.9 |
|
#
b398123b |
| 14-Dec-2021 |
Pingfan Liu <kernelfans@gmail.com> |
efi: apply memblock cap after memblock_add()
On arm64, during kdump kernel saves vmcore, it runs into the following bug: ... [ 15.148919] usercopy: Kernel memory exposure attempt detected from SLU
efi: apply memblock cap after memblock_add()
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 <kernelfans@gmail.com> Cc: Rob Herring <robh+dt@kernel.org> Cc: Zhen Lei <thunder.leizhen@huawei.com> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Will Deacon <will@kernel.org> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Mike Rapoport <rppt@kernel.org> Cc: Geert Uytterhoeven <geert+renesas@glider.be> Cc: Frank Rowand <frowand.list@gmail.com> Cc: Ard Biesheuvel <ardb@kernel.org> Cc: Nick Terrell <terrelln@fb.com> Cc: linux-arm-kernel@lists.infradead.org To: devicetree@vger.kernel.org To: linux-efi@vger.kernel.org Acked-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20211215021348.8766-1-kernelfans@gmail.com
show more ...
|
Revision tags: v5.15.8 |
|
#
8347b417 |
| 13-Dec-2021 |
Zhen Lei <thunder.leizhen@huawei.com> |
of: fdt: Aggregate the processing of "linux,usable-memory-range"
Currently, we parse the "linux,usable-memory-range" property in early_init_dt_scan_chosen(), to obtain the specified memory range of
of: fdt: Aggregate the processing of "linux,usable-memory-range"
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 <robh@kernel.org> Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com> (change the prototype of early_init_dt_check_for_usable_mem_range(), in order to use it outside) Signed-off-by: Pingfan Liu <kernelfans@gmail.com> Tested-by: Dave Kleikamp <dave.kleikamp@oracle.com> Acked-by: John Donnelly <john.p.donnelly@oracle.com> Reviewed-by: Rob Herring <robh@kernel.org> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Will Deacon <will@kernel.org> Cc: linux-arm-kernel@lists.infradead.org To: devicetree@vger.kernel.org To: linux-efi@vger.kernel.org Signed-off-by: Rob Herring <robh@kernel.org>
show more ...
|
#
1f012283 |
| 15-Dec-2021 |
Rob Herring <robh@kernel.org> |
of/fdt: Rework early_init_dt_scan_memory() to call directly
Use of the of_scan_flat_dt() function predates libfdt and is discouraged as libfdt provides a nicer set of APIs. Rework early_init_dt_scan
of/fdt: Rework early_init_dt_scan_memory() to call directly
Use of the of_scan_flat_dt() function predates libfdt and is discouraged as libfdt provides a nicer set of APIs. Rework early_init_dt_scan_memory() to be called directly and use libfdt.
Cc: John Crispin <john@phrozen.org> Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de> Cc: Michael Ellerman <mpe@ellerman.id.au> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Paul Mackerras <paulus@samba.org> Cc: Frank Rowand <frowand.list@gmail.com> Cc: linux-mips@vger.kernel.org Cc: linuxppc-dev@lists.ozlabs.org Reviewed-by: Frank Rowand <frank.rowand@sony.com> Signed-off-by: Rob Herring <robh@kernel.org> Tested-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20211215150102.1303588-1-robh@kernel.org
show more ...
|
Revision tags: v5.15.7, v5.15.6, v5.15.5, v5.15.4, v5.15.3 |
|
#
d665881d |
| 18-Nov-2021 |
Rob Herring <robh@kernel.org> |
of/fdt: Rework early_init_dt_scan_root() to call directly
Use of the of_scan_flat_dt() function predates libfdt and is discouraged as libfdt provides a nicer set of APIs. Rework early_init_dt_scan_r
of/fdt: Rework early_init_dt_scan_root() to call directly
Use of the of_scan_flat_dt() function predates libfdt and is discouraged as libfdt provides a nicer set of APIs. Rework early_init_dt_scan_root() to be called directly and use libfdt.
Cc: Michael Ellerman <mpe@ellerman.id.au> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Paul Mackerras <paulus@samba.org> Cc: Frank Rowand <frowand.list@gmail.com> Cc: linuxppc-dev@lists.ozlabs.org Signed-off-by: Rob Herring <robh@kernel.org> Reviewed-by: Frank Rowand <frank.rowand@sony.com> Link: https://lore.kernel.org/r/20211118181213.1433346-3-robh@kernel.org
show more ...
|