summaryrefslogtreecommitdiff
path: root/arch
AgeCommit message (Collapse)AuthorFilesLines
11 daysARM/ARM64: configs: tizen: drop DM_BOWMarek Szyprowski4-4/+0
dm-bow kernel module has been moved to external linux-tizen-modules repository, so drop it from Tizen's defconfig. Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> Change-Id: I76c0a73cd9f9ce6291419a21b352886e7098df70
11 daysARM/ARM64: configs: tizen: drop TIZEN_INFORM_REBOOTMarek Szyprowski4-8/+0
Tizen specific inform-reboot module has been moved to external linux-tizen-modules repository, so drop it from Tizen's defconfig. Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> Change-Id: Ied86f6cd4c47dd6f562a3eaa7e672d3121e50abf
11 daysARM64: configs: tizen: Adjust for mipi csi camera of rpi5Seung-Woo Kim2-4/+8
To use mipi csi camera in rpi5, it is required dw i2c for the rpi5 board. Also, to support mipi csi of rpi5, pisp_be. Adjust for mipi csi camera of rpi5 and build camera sensors as module because they are only used when connected. Change-Id: I9b59b0f3816ba6a7801028162870566e262f23f5 Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
11 daysARM/ARM64: configs: tizen: Enable ASHMEMSeung-Woo Kim4-0/+4
Enable CONFIG_ASHMEM for waydroid in a container. This brings ashmem back partially from the commit e0df7c69e65a ("arm/arm64: tizen_bcm2711_defconfig: Add configs for waydroid"). Change-Id: I44287862f791231f066c0e11b57326b9abb9de1c Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
11 daysARM/ARM64: configs: tizen: Sync from non-rt to rt and with savedefconfigSeung-Woo Kim3-8/+34
After some config commits, non-rt and rt defconfigs have different configs. Sync from non-rt to rt defconfig. Also, sync with minimized defconfig made with "make savedefconfig". Change-Id: I047268bf8e345228b4487433000d511e805d56f1 Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
11 daysARM: dts: bcm2711-rpi-4-b: add a brcmf wifi nodeJaehoon Chung1-0/+7
Add brcmf wifi node to use a below property. - brcm,featuer-disable "0x2000" is a bit to disable "sup_wpa" feature. Tizen doesn't need to use this feature. So disable it by default. Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com> Signed-off-by: Hoegeun Kwon <hoegeun.kwon@samsung.com> (cherry-picked from commit 23eaf8308aa4cc22a4002ae67dd5736f183e0b7d) Change-Id: Ifc39b6ce7d71caca0efe48a9659d41e6da5081f5
11 daystizen_bcm2711_defconfig: enable rpivid driver for h265 video decoderMarek Szyprowski2-0/+2
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> Change-Id: I7e8bfa1d197b96a2547ee0e53eec5c18d2520f63
11 daystizen_bcm2711_defconfig: enable drivers for RPi5 boardMarek Szyprowski1-2/+24
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> Change-Id: Ie9a0abcd3e1f077e1cee4c9bf45a0d22d406bf41
11 daysoverlays: Add dwc2-tizen-overlayHoegeun Kwon2-0/+15
Add g-extcon-always-on value, Set extcon state for dwc2 cable as always true. Signed-off-by: Dongwoo Lee <dwoo08.lee@samsung.com> Signed-off-by: Hoegeun Kwon <hoegeun.kwon@samsung.com> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> Change-Id: Ibd209a402978343eeb6af3d4597a80d48f53f019
11 daysARM/ARM64: configs: Add the intial tizen defconfig for RPI4Jaehoon Chung4-0/+1944
Add the intial tizen defconfig for RPI4. These defconfigs were taken from tizen branch (v5.15 kernel) and manually adjusted for the options changed/moved in v6.6 kernel, then saved with savedefconfig. Change-Id: Ief4c89e7cedc14d15995e6efd444fbb70ddc9c03 Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
11 daysLinux 6.6.58-rt45Jaehoon Chung17-56/+187
Apply Linux 6.6.58-rt45 patches. This is based on patche-6.6.58-rt45.patch.gz. Change-Id: Ic3c53835f040de2aac9af4e919c8d8e8fb0fd8fc Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com>
2024-11-08Merge remote-tracking branch 'stable/linux-6.6.y' into rpi-6.6.yDom Cobley9-20/+78
2024-11-08arm64: dts: imx8ulp: correct the flexspi compatible stringHaibo Chen1-1/+1
commit 409dc5196d5b6eb67468a06bf4d2d07d7225a67b upstream. The flexspi on imx8ulp only has 16 LUTs, and imx8mm flexspi has 32 LUTs, so correct the compatible string here, otherwise will meet below error: [ 1.119072] ------------[ cut here ]------------ [ 1.123926] WARNING: CPU: 0 PID: 1 at drivers/spi/spi-nxp-fspi.c:855 nxp_fspi_exec_op+0xb04/0xb64 [ 1.133239] Modules linked in: [ 1.136448] CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.11.0-rc6-next-20240902-00001-g131bf9439dd9 #69 [ 1.146821] Hardware name: NXP i.MX8ULP EVK (DT) [ 1.151647] pstate: 40000005 (nZcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 1.158931] pc : nxp_fspi_exec_op+0xb04/0xb64 [ 1.163496] lr : nxp_fspi_exec_op+0xa34/0xb64 [ 1.168060] sp : ffff80008002b2a0 [ 1.171526] x29: ffff80008002b2d0 x28: 0000000000000000 x27: 0000000000000000 [ 1.179002] x26: ffff2eb645542580 x25: ffff800080610014 x24: ffff800080610000 [ 1.186480] x23: ffff2eb645548080 x22: 0000000000000006 x21: ffff2eb6455425e0 [ 1.193956] x20: 0000000000000000 x19: ffff80008002b5e0 x18: ffffffffffffffff [ 1.201432] x17: ffff2eb644467508 x16: 0000000000000138 x15: 0000000000000002 [ 1.208907] x14: 0000000000000000 x13: ffff2eb6400d8080 x12: 00000000ffffff00 [ 1.216378] x11: 0000000000000000 x10: ffff2eb6400d8080 x9 : ffff2eb697adca80 [ 1.223850] x8 : ffff2eb697ad3cc0 x7 : 0000000100000000 x6 : 0000000000000001 [ 1.231324] x5 : 0000000000000000 x4 : 0000000000000000 x3 : 00000000000007a6 [ 1.238795] x2 : 0000000000000000 x1 : 00000000000001ce x0 : 00000000ffffff92 [ 1.246267] Call trace: [ 1.248824] nxp_fspi_exec_op+0xb04/0xb64 [ 1.253031] spi_mem_exec_op+0x3a0/0x430 [ 1.257139] spi_nor_read_id+0x80/0xcc [ 1.261065] spi_nor_scan+0x1ec/0xf10 [ 1.264901] spi_nor_probe+0x108/0x2fc [ 1.268828] spi_mem_probe+0x6c/0xbc [ 1.272574] spi_probe+0x84/0xe4 [ 1.275958] really_probe+0xbc/0x29c [ 1.279713] __driver_probe_device+0x78/0x12c [ 1.284277] driver_probe_device+0xd8/0x15c [ 1.288660] __device_attach_driver+0xb8/0x134 [ 1.293316] bus_for_each_drv+0x88/0xe8 [ 1.297337] __device_attach+0xa0/0x190 [ 1.301353] device_initial_probe+0x14/0x20 [ 1.305734] bus_probe_device+0xac/0xb0 [ 1.309752] device_add+0x5d0/0x790 [ 1.313408] __spi_add_device+0x134/0x204 [ 1.317606] of_register_spi_device+0x3b4/0x590 [ 1.322348] spi_register_controller+0x47c/0x754 [ 1.327181] devm_spi_register_controller+0x4c/0xa4 [ 1.332289] nxp_fspi_probe+0x1cc/0x2b0 [ 1.336307] platform_probe+0x68/0xc4 [ 1.340145] really_probe+0xbc/0x29c [ 1.343893] __driver_probe_device+0x78/0x12c [ 1.348457] driver_probe_device+0xd8/0x15c [ 1.352838] __driver_attach+0x90/0x19c [ 1.356857] bus_for_each_dev+0x7c/0xdc [ 1.360877] driver_attach+0x24/0x30 [ 1.364624] bus_add_driver+0xe4/0x208 [ 1.368552] driver_register+0x5c/0x124 [ 1.372573] __platform_driver_register+0x28/0x34 [ 1.377497] nxp_fspi_driver_init+0x1c/0x28 [ 1.381888] do_one_initcall+0x80/0x1c8 [ 1.385908] kernel_init_freeable+0x1c4/0x28c [ 1.390472] kernel_init+0x20/0x1d8 [ 1.394138] ret_from_fork+0x10/0x20 [ 1.397885] ---[ end trace 0000000000000000 ]--- [ 1.407908] ------------[ cut here ]------------ Fixes: ef89fd56bdfc ("arm64: dts: imx8ulp: add flexspi node") Cc: stable@kernel.org Signed-off-by: Haibo Chen <haibo.chen@nxp.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-11-08x86/traps: move kmsan check after instrumentation_beginSabyrzhan Tasbolatov1-6/+6
[ Upstream commit 1db272864ff250b5e607283eaec819e1186c8e26 ] During x86_64 kernel build with CONFIG_KMSAN, the objtool warns following: AR built-in.a AR vmlinux.a LD vmlinux.o vmlinux.o: warning: objtool: handle_bug+0x4: call to kmsan_unpoison_entry_regs() leaves .noinstr.text section OBJCOPY modules.builtin.modinfo GEN modules.builtin MODPOST Module.symvers CC .vmlinux.export.o Moving kmsan_unpoison_entry_regs() _after_ instrumentation_begin() fixes the warning. There is decode_bug(regs->ip, &imm) is left before KMSAN unpoisoining, but it has the return condition and if we include it after instrumentation_begin() it results the warning "return with instrumentation enabled", hence, I'm concerned that regs will not be KMSAN unpoisoned if `ud_type == BUG_NONE` is true. Link: https://lkml.kernel.org/r/20241016152407.3149001-1-snovitoll@gmail.com Fixes: ba54d194f8da ("x86/traps: avoid KMSAN bugs originating from handle_bug()") Signed-off-by: Sabyrzhan Tasbolatov <snovitoll@gmail.com> Reviewed-by: Alexander Potapenko <glider@google.com> Cc: Borislav Petkov (AMD) <bp@alien8.de> Cc: Dave Hansen <dave.hansen@linux.intel.com> Cc: Ingo Molnar <mingo@redhat.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-11-08x86/traps: Enable UBSAN traps on x86Gatlin Newhouse2-5/+66
[ Upstream commit 7424fc6b86c8980a87169e005f5cd4438d18efe6 ] Currently ARM64 extracts which specific sanitizer has caused a trap via encoded data in the trap instruction. Clang on x86 currently encodes the same data in the UD1 instruction but x86 handle_bug() and is_valid_bugaddr() currently only look at UD2. Bring x86 to parity with ARM64, similar to commit 25b84002afb9 ("arm64: Support Clang UBSAN trap codes for better reporting"). See the llvm links for information about the code generation. Enable the reporting of UBSAN sanitizer details on x86 compiled with clang when CONFIG_UBSAN_TRAP=y by analysing UD1 and retrieving the type immediate which is encoded by the compiler after the UD1. [ tglx: Simplified it by moving the printk() into handle_bug() ] Signed-off-by: Gatlin Newhouse <gatlin.newhouse@gmail.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org> Cc: Kees Cook <keescook@chromium.org> Link: https://lore.kernel.org/all/20240724000206.451425-1-gatlin.newhouse@gmail.com Link: https://github.com/llvm/llvm-project/commit/c5978f42ec8e9#diff-bb68d7cd885f41cfc35843998b0f9f534adb60b415f647109e597ce448e92d9f Link: https://github.com/llvm/llvm-project/blob/main/llvm/lib/Target/X86/X86InstrSystem.td#L27 Stable-dep-of: 1db272864ff2 ("x86/traps: move kmsan check after instrumentation_begin") Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-11-08riscv: Remove duplicated GET_RMChunyan Zhang1-2/+0
[ Upstream commit 164f66de6bb6ef454893f193c898dc8f1da6d18b ] The macro GET_RM defined twice in this file, one can be removed. Reviewed-by: Alexandre Ghiti <alexghiti@rivosinc.com> Signed-off-by: Chunyan Zhang <zhangchunyan@iscas.ac.cn> Fixes: 956d705dd279 ("riscv: Unaligned load/store handling for M_MODE") Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20241008094141.549248-3-zhangchunyan@iscas.ac.cn Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-11-08riscv: Remove unused GENERATING_ASM_OFFSETSChunyan Zhang1-2/+0
[ Upstream commit 46d4e5ac6f2f801f97bcd0ec82365969197dc9b1 ] The macro is not used in the current version of kernel, it looks like can be removed to avoid a build warning: ../arch/riscv/kernel/asm-offsets.c: At top level: ../arch/riscv/kernel/asm-offsets.c:7: warning: macro "GENERATING_ASM_OFFSETS" is not used [-Wunused-macros] 7 | #define GENERATING_ASM_OFFSETS Fixes: 9639a44394b9 ("RISC-V: Provide a cleaner raw_smp_processor_id()") Cc: stable@vger.kernel.org Reviewed-by: Alexandre Ghiti <alexghiti@rivosinc.com> Tested-by: Alexandre Ghiti <alexghiti@rivosinc.com> Signed-off-by: Chunyan Zhang <zhangchunyan@iscas.ac.cn> Link: https://lore.kernel.org/r/20241008094141.549248-2-zhangchunyan@iscas.ac.cn Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-11-08riscv: Use '%u' to format the output of 'cpu'WangYuli1-1/+1
[ Upstream commit e0872ab72630dada3ae055bfa410bf463ff1d1e0 ] 'cpu' is an unsigned integer, so its conversion specifier should be %u, not %d. Suggested-by: Wentao Guan <guanwentao@uniontech.com> Suggested-by: Maciej W. Rozycki <macro@orcam.me.uk> Link: https://lore.kernel.org/all/alpine.DEB.2.21.2409122309090.40372@angie.orcam.me.uk/ Signed-off-by: WangYuli <wangyuli@uniontech.com> Reviewed-by: Charlie Jenkins <charlie@rivosinc.com> Tested-by: Charlie Jenkins <charlie@rivosinc.com> Fixes: f1e58583b9c7 ("RISC-V: Support cpu hotplug") Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/4C127DEECDA287C8+20241017032010.96772-1-wangyuli@uniontech.com Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-11-08riscv: efi: Set NX compat flag in PE/COFF headerHeinrich Schuchardt1-1/+1
[ Upstream commit d41373a4b910961df5a5e3527d7bde6ad45ca438 ] The IMAGE_DLLCHARACTERISTICS_NX_COMPAT informs the firmware that the EFI binary does not rely on pages that are both executable and writable. The flag is used by some distro versions of GRUB to decide if the EFI binary may be executed. As the Linux kernel neither has RWX sections nor needs RWX pages for relocation we should set the flag. Cc: Ard Biesheuvel <ardb@kernel.org> Cc: <stable@vger.kernel.org> Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> Reviewed-by: Emil Renner Berthing <emil.renner.berthing@canonical.com> Fixes: cb7d2dd5612a ("RISC-V: Add PE/COFF header for EFI stub") Acked-by: Ard Biesheuvel <ardb@kernel.org> Link: https://lore.kernel.org/r/20240929140233.211800-1-heinrich.schuchardt@canonical.com Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-11-08riscv: vdso: Prevent the compiler from inserting calls to memset()Alexandre Ghiti1-0/+1
[ Upstream commit bf40167d54d55d4b54d0103713d86a8638fb9290 ] The compiler is smart enough to insert a call to memset() in riscv_vdso_get_cpus(), which generates a dynamic relocation. So prevent this by using -fno-builtin option. Fixes: e2c0cdfba7f6 ("RISC-V: User-facing API") Cc: stable@vger.kernel.org Signed-off-by: Alexandre Ghiti <alexghiti@rivosinc.com> Reviewed-by: Guo Ren <guoren@kernel.org> Link: https://lore.kernel.org/r/20241016083625.136311-2-alexghiti@rivosinc.com Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-11-08RISC-V: ACPI: fix early_ioremap to early_memremapYunhui Cui1-2/+2
commit 1966db682f064172891275cb951aa8c98a0a809b upstream. When SVPBMT is enabled, __acpi_map_table() will directly access the data in DDR through the IO attribute, rather than through hardware cache consistency, resulting in incorrect data in the obtained ACPI table. The log: ACPI: [ACPI:0x18] Invalid zero length. We do not assume whether the bootloader flushes or not. We should access in a cacheable way instead of maintaining cache consistency by software. Fixes: 3b426d4b5b14 ("RISC-V: ACPI : Fix for usage of pointers in different address space") Cc: stable@vger.kernel.org Reviewed-by: Alexandre Ghiti <alexghiti@rivosinc.com> Signed-off-by: Yunhui Cui <cuiyunhui@bytedance.com> Reviewed-by: Sunil V L <sunilvl@ventanamicro.com> Link: https://lore.kernel.org/r/20241014130141.86426-1-cuiyunhui@bytedance.com Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-11-08configs: Switch default cpufreq governor to ondemandDom Cobley6-18/+12
Historically we have booted in powersave mode, and switched to ondemand with the /etc/init.d/raspi-config scipt if the shift key is not pressed. This was intended to protect users from an unsafe overclock, or inadequate power supply. But there's little evedence that this option is benefitting anyone, and we can boot faster without it. Signed-off-by: Dom Cobley <popcornmix@gmail.com>
2024-11-08Revert "dts: rp1: Disable DMA usage for UART0"Phil Elwell1-3/+3
This reverts commit cc63d552b9aab92fb581dfb08267d5af697f477b.
2024-11-06DTS: rp1: set enhanced FS NAK quirk for usb3 controllersJonathan Bell1-0/+2
There seem to be only benefits, and no downsides. Signed-off-by: Jonathan Bell <jonathan@raspberrypi.com>
2024-11-05dts: 2712: Drop some numa options from bootargsDom Cobley1-1/+1
iommu_dma_numa_policy=interleave is not valid in the current tree It generates an unknown setting will be passed to usespace warning system_heap.max_order=0 is wanted when numa is enabled, but may not be when it is disabled. Add it on firmware side when we know if numa=fake=<n> is used. Signed-off-by: Dom Cobley <popcornmix@gmail.com>
2024-11-02dtoverlay: Add a dtoverlay for pwm-gpioTim Gover3-0/+45
Signed-off-by: Tim Gover <tim.gover@raspberrypi.com>
2024-11-02config: bcm2711_defconfig/bcm2712_defconfig: Enable CONFIG_PWM_GPIOTim Gover6-0/+6
Enable the PWM GPIO module in Raspberry Pi kernels. Signed-off-by: Tim Gover <tim.gover@raspberrypi.com>
2024-11-01configs: Regenerate defconfigsPhil Elwell6-8/+2
Signed-off-by: Phil Elwell <phil@raspberrypi.com>
2024-11-01Merge remote-tracking branch 'stable/linux-6.6.y' into rpi-6.6.yDom Cobley16-35/+62
2024-11-01LoongArch: Make KASAN usable for variable cpu_vabitsHuacai Chen1-1/+1
commit 3c252263be801f937f56b4bcd8e8e2b5307c1ce5 upstream. Currently, KASAN on LoongArch assume the CPU VA bits is 48, which is true for Loongson-3 series, but not for Loongson-2 series (only 40 or lower), this patch fix that issue and make KASAN usable for variable cpu_vabits. Solution is very simple: Just define XRANGE_SHADOW_SHIFT which means valid address length from VA_BITS to min(cpu_vabits, VA_BITS). Cc: stable@vger.kernel.org Signed-off-by: Kanglong Wang <wangkanglong@loongson.cn> Signed-off-by: Huacai Chen <chenhuacai@loongson.cn> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-11-01LoongArch: Enable IRQ if do_ale() triggered in irq-enabled contextHuacai Chen1-0/+5
commit 69cc6fad5df4ce652d969be69acc60e269e5eea1 upstream. Unaligned access exception can be triggered in irq-enabled context such as user mode, in this case do_ale() may call get_user() which may cause sleep. Then we will get: BUG: sleeping function called from invalid context at arch/loongarch/kernel/access-helper.h:7 in_atomic(): 0, irqs_disabled(): 1, non_block: 0, pid: 129, name: modprobe preempt_count: 0, expected: 0 RCU nest depth: 0, expected: 0 CPU: 0 UID: 0 PID: 129 Comm: modprobe Tainted: G W 6.12.0-rc1+ #1723 Tainted: [W]=WARN Stack : 9000000105e0bd48 0000000000000000 9000000003803944 9000000105e08000 9000000105e0bc70 9000000105e0bc78 0000000000000000 0000000000000000 9000000105e0bc78 0000000000000001 9000000185e0ba07 9000000105e0b890 ffffffffffffffff 9000000105e0bc78 73924b81763be05b 9000000100194500 000000000000020c 000000000000000a 0000000000000000 0000000000000003 00000000000023f0 00000000000e1401 00000000072f8000 0000007ffbb0e260 0000000000000000 0000000000000000 9000000005437650 90000000055d5000 0000000000000000 0000000000000003 0000007ffbb0e1f0 0000000000000000 0000005567b00490 0000000000000000 9000000003803964 0000007ffbb0dfec 00000000000000b0 0000000000000007 0000000000000003 0000000000071c1d ... Call Trace: [<9000000003803964>] show_stack+0x64/0x1a0 [<9000000004c57464>] dump_stack_lvl+0x74/0xb0 [<9000000003861ab4>] __might_resched+0x154/0x1a0 [<900000000380c96c>] emulate_load_store_insn+0x6c/0xf60 [<9000000004c58118>] do_ale+0x78/0x180 [<9000000003801bc8>] handle_ale+0x128/0x1e0 So enable IRQ if unaligned access exception is triggered in irq-enabled context to fix it. Cc: stable@vger.kernel.org Reported-by: Binbin Zhou <zhoubinbin@loongson.cn> Signed-off-by: Huacai Chen <chenhuacai@loongson.cn> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-11-01LoongArch: Get correct cores_per_package for SMT systemsHuacai Chen2-1/+6
commit b7296f9d5bf99330063d4bbecc43c9b33fed0137 upstream. In loongson_sysconf, The "core" of cores_per_node and cores_per_package stands for a logical core, which means in a SMT system it stands for a thread indeed. This information is gotten from SMBIOS Type4 Structure, so in order to get a correct cores_per_package for both SMT and non-SMT systems in parse_cpu_table() we should use SMBIOS_THREAD_PACKAGE_OFFSET instead of SMBIOS_CORE_PACKAGE_OFFSET. Cc: stable@vger.kernel.org Reported-by: Chao Li <lichao@loongson.cn> Tested-by: Chao Li <lichao@loongson.cn> Signed-off-by: Huacai Chen <chenhuacai@loongson.cn> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-11-01x86/lam: Disable ADDRESS_MASKING in most casesPawan Gupta1-0/+1
commit 3267cb6d3a174ff83d6287dcd5b0047bbd912452 upstream. Linear Address Masking (LAM) has a weakness related to transient execution as described in the SLAM paper[1]. Unless Linear Address Space Separation (LASS) is enabled this weakness may be exploitable. Until kernel adds support for LASS[2], only allow LAM for COMPILE_TEST, or when speculation mitigations have been disabled at compile time, otherwise keep LAM disabled. There are no processors in market that support LAM yet, so currently nobody is affected by this issue. [1] SLAM: https://download.vusec.net/papers/slam_sp24.pdf [2] LASS: https://lore.kernel.org/lkml/20230609183632.48706-1-alexander.shishkin@linux.intel.com/ [ dhansen: update SPECULATION_MITIGATIONS -> CPU_MITIGATIONS ] Signed-off-by: Pawan Gupta <pawan.kumar.gupta@linux.intel.com> Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com> Reviewed-by: Sohil Mehta <sohil.mehta@intel.com> Acked-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com> Cc:stable@vger.kernel.org Link: https://lore.kernel.org/all/5373262886f2783f054256babdf5a98545dc986b.1706068222.git.pawan.kumar.gupta%40linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-11-01KVM: arm64: Don't eagerly teardown the vgic on init errorMarc Zyngier2-3/+6
commit df5fd75ee305cb5927e0b1a0b46cc988ad8db2b1 upstream. As there is very little ordering in the KVM API, userspace can instanciate a half-baked GIC (missing its memory map, for example) at almost any time. This means that, with the right timing, a thread running vcpu-0 can enter the kernel without a GIC configured and get a GIC created behind its back by another thread. Amusingly, it will pick up that GIC and start messing with the data structures without the GIC having been fully initialised. Similarly, a thread running vcpu-1 can enter the kernel, and try to init the GIC that was previously created. Since this GIC isn't properly configured (no memory map), it fails to correctly initialise. And that's the point where we decide to teardown the GIC, freeing all its resources. Behind vcpu-0's back. Things stop pretty abruptly, with a variety of symptoms. Clearly, this isn't good, we should be a bit more careful about this. It is obvious that this guest is not viable, as it is missing some important part of its configuration. So instead of trying to tear bits of it down, let's just mark it as *dead*. It means that any further interaction from userspace will result in -EIO. The memory will be released on the "normal" path, when userspace gives up. Cc: stable@vger.kernel.org Reported-by: Alexander Potapenko <glider@google.com> Reviewed-by: Oliver Upton <oliver.upton@linux.dev> Link: https://lore.kernel.org/r/20241009183603.3221824-1-maz@kernel.org Signed-off-by: Marc Zyngier <maz@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-11-01KVM: arm64: Fix shift-out-of-bounds bugIlkka Koskinen1-1/+1
commit c6c167afa090ea0451f91814e1318755a8fb8bb9 upstream. Fix a shift-out-of-bounds bug reported by UBSAN when running VM with MTE enabled host kernel. UBSAN: shift-out-of-bounds in arch/arm64/kvm/sys_regs.c:1988:14 shift exponent 33 is too large for 32-bit type 'int' CPU: 26 UID: 0 PID: 7629 Comm: qemu-kvm Not tainted 6.12.0-rc2 #34 Hardware name: IEI NF5280R7/Mitchell MB, BIOS 00.00. 2024-10-12 09:28:54 10/14/2024 Call trace: dump_backtrace+0xa0/0x128 show_stack+0x20/0x38 dump_stack_lvl+0x74/0x90 dump_stack+0x18/0x28 __ubsan_handle_shift_out_of_bounds+0xf8/0x1e0 reset_clidr+0x10c/0x1c8 kvm_reset_sys_regs+0x50/0x1c8 kvm_reset_vcpu+0xec/0x2b0 __kvm_vcpu_set_target+0x84/0x158 kvm_vcpu_set_target+0x138/0x168 kvm_arch_vcpu_ioctl_vcpu_init+0x40/0x2b0 kvm_arch_vcpu_ioctl+0x28c/0x4b8 kvm_vcpu_ioctl+0x4bc/0x7a8 __arm64_sys_ioctl+0xb4/0x100 invoke_syscall+0x70/0x100 el0_svc_common.constprop.0+0x48/0xf0 do_el0_svc+0x24/0x38 el0_svc+0x3c/0x158 el0t_64_sync_handler+0x120/0x130 el0t_64_sync+0x194/0x198 Fixes: 7af0c2534f4c ("KVM: arm64: Normalize cache configuration") Cc: stable@vger.kernel.org Reviewed-by: Gavin Shan <gshan@redhat.com> Signed-off-by: Ilkka Koskinen <ilkka@os.amperecomputing.com> Reviewed-by: Anshuman Khandual <anshuman.khandual@arm.com> Link: https://lore.kernel.org/r/20241017025701.67936-1-ilkka@os.amperecomputing.com Signed-off-by: Marc Zyngier <maz@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-11-01KVM: nSVM: Ignore nCR3[4:0] when loading PDPTEs from memorySean Christopherson1-1/+5
commit f559b2e9c5c5308850544ab59396b7d53cfc67bd upstream. Ignore nCR3[4:0] when loading PDPTEs from memory for nested SVM, as bits 4:0 of CR3 are ignored when PAE paging is used, and thus VMRUN doesn't enforce 32-byte alignment of nCR3. In the absolute worst case scenario, failure to ignore bits 4:0 can result in an out-of-bounds read, e.g. if the target page is at the end of a memslot, and the VMM isn't using guard pages. Per the APM: The CR3 register points to the base address of the page-directory-pointer table. The page-directory-pointer table is aligned on a 32-byte boundary, with the low 5 address bits 4:0 assumed to be 0. And the SDM's much more explicit: 4:0 Ignored Note, KVM gets this right when loading PDPTRs, it's only the nSVM flow that is broken. Fixes: e4e517b4be01 ("KVM: MMU: Do not unconditionally read PDPTE from guest memory") Reported-by: Kirk Swidowski <swidowski@google.com> Cc: Andy Nguyen <theflow@google.com> Cc: 3pvd <3pvd@google.com> Cc: stable@vger.kernel.org Signed-off-by: Sean Christopherson <seanjc@google.com> Message-ID: <20241009140838.1036226-1-seanjc@google.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-11-01LoongArch: Don't crash in stack_top() for tasks without vDSOThomas Weißschuh1-7/+9
[ Upstream commit 134475a9ab8487527238d270639a8cb74c10aab2 ] Not all tasks have a vDSO mapped, for example kthreads never do. If such a task ever ends up calling stack_top(), it will derefence the NULL vdso pointer and crash. This can for example happen when using kunit: [<9000000000203874>] stack_top+0x58/0xa8 [<90000000002956cc>] arch_pick_mmap_layout+0x164/0x220 [<90000000003c284c>] kunit_vm_mmap_init+0x108/0x12c [<90000000003c1fbc>] __kunit_add_resource+0x38/0x8c [<90000000003c2704>] kunit_vm_mmap+0x88/0xc8 [<9000000000410b14>] usercopy_test_init+0xbc/0x25c [<90000000003c1db4>] kunit_try_run_case+0x5c/0x184 [<90000000003c3d54>] kunit_generic_run_threadfn_adapter+0x24/0x48 [<900000000022e4bc>] kthread+0xc8/0xd4 [<9000000000200ce8>] ret_from_kernel_thread+0xc/0xa4 Fixes: 803b0fc5c3f2 ("LoongArch: Add process management") Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de> Signed-off-by: Huacai Chen <chenhuacai@loongson.cn> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-11-01arm64: Force position-independent veneersMark Rutland1-1/+1
[ Upstream commit 9abe390e689f4f5c23c5f507754f8678431b4f72 ] Certain portions of code always need to be position-independent regardless of CONFIG_RELOCATABLE, including code which is executed in an idmap or which is executed before relocations are applied. In some kernel configurations the LLD linker generates position-dependent veneers for such code, and when executed these result in early boot-time failures. Marc Zyngier encountered a boot failure resulting from this when building a (particularly cursed) configuration with LLVM, as he reported to the list: https://lore.kernel.org/linux-arm-kernel/86wmjwvatn.wl-maz@kernel.org/ In Marc's kernel configuration, the .head.text and .rodata.text sections end up more than 128MiB apart, requiring a veneer to branch between the two: | [mark@lakrids:~/src/linux]% usekorg 14.1.0 aarch64-linux-objdump -t vmlinux | grep -w _text | ffff800080000000 g .head.text 0000000000000000 _text | [mark@lakrids:~/src/linux]% usekorg 14.1.0 aarch64-linux-objdump -t vmlinux | grep -w primary_entry | ffff8000889df0e0 g .rodata.text 000000000000006c primary_entry, ... consequently, LLD inserts a position-dependent veneer for the branch from _stext (in .head.text) to primary_entry (in .rodata.text): | ffff800080000000 <_text>: | ffff800080000000: fa405a4d ccmp x18, #0x0, #0xd, pl // pl = nfrst | ffff800080000004: 14003fff b ffff800080010000 <__AArch64AbsLongThunk_primary_entry> ... | ffff800080010000 <__AArch64AbsLongThunk_primary_entry>: | ffff800080010000: 58000050 ldr x16, ffff800080010008 <__AArch64AbsLongThunk_primary_entry+0x8> | ffff800080010004: d61f0200 br x16 | ffff800080010008: 889df0e0 .word 0x889df0e0 | ffff80008001000c: ffff8000 .word 0xffff8000 ... and as this is executed early in boot before the kernel is mapped in TTBR1 this results in a silent boot failure. Fix this by passing '--pic-veneer' to the linker, which will cause the linker to use position-independent veneers, e.g. | ffff800080000000 <_text>: | ffff800080000000: fa405a4d ccmp x18, #0x0, #0xd, pl // pl = nfrst | ffff800080000004: 14003fff b ffff800080010000 <__AArch64ADRPThunk_primary_entry> ... | ffff800080010000 <__AArch64ADRPThunk_primary_entry>: | ffff800080010000: f004e3f0 adrp x16, ffff800089c8f000 <__idmap_text_start> | ffff800080010004: 91038210 add x16, x16, #0xe0 | ffff800080010008: d61f0200 br x16 I've opted to pass '--pic-veneer' unconditionally, as: * In addition to solving the boot failure, these sequences are generally nicer as they require fewer instructions and don't need to perform data accesses. * While the position-independent veneer sequences have a limited +/-2GiB range, this is not a new restriction. Even kernels built with CONFIG_RELOCATABLE=n are limited to 2GiB in size as we have several structues using 32-bit relative offsets and PPREL32 relocations, which are similarly limited to +/-2GiB in range. These include extable entries, jump table entries, and alt_instr entries. * GNU LD defaults to using position-independent veneers, and supports the same '--pic-veneer' option, so this change is not expected to adversely affect GNU LD. I've tested with GNU LD 2.30 to 2.42 inclusive and LLVM 13.0.1 to 19.1.0 inclusive, using the kernel.org binaries from: * https://mirrors.edge.kernel.org/pub/tools/crosstool/ * https://mirrors.edge.kernel.org/pub/tools/llvm/ Signed-off-by: Mark Rutland <mark.rutland@arm.com> Reported-by: Marc Zyngier <maz@kernel.org> Cc: Ard Biesheuvel <ardb@kernel.org> Cc: Nathan Chancellor <nathan@kernel.org> Cc: Nick Desaulniers <ndesaulniers@google.com> Cc: Will Deacon <will@kernel.org> Acked-by: Ard Biesheuvel <ardb@kernel.org> Reviewed-by: Nathan Chancellor <nathan@kernel.org> Link: https://lore.kernel.org/r/20240927101838.3061054-1-mark.rutland@arm.com Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-11-01riscv, bpf: Make BPF_CMPXCHG fully orderedAndrea Parri1-2/+2
[ Upstream commit e59db0623f6955986d1be0880b351a1f56e7fd6d ] According to the prototype formal BPF memory consistency model discussed e.g. in [1] and following the ordering properties of the C/in-kernel macro atomic_cmpxchg(), a BPF atomic operation with the BPF_CMPXCHG modifier is fully ordered. However, the current RISC-V JIT lowerings fail to meet such memory ordering property. This is illustrated by the following litmus test: BPF BPF__MP+success_cmpxchg+fence { 0:r1=x; 0:r3=y; 0:r5=1; 1:r2=y; 1:r4=f; 1:r7=x; } P0 | P1 ; *(u64 *)(r1 + 0) = 1 | r1 = *(u64 *)(r2 + 0) ; r2 = cmpxchg_64 (r3 + 0, r4, r5) | r3 = atomic_fetch_add((u64 *)(r4 + 0), r5) ; | r6 = *(u64 *)(r7 + 0) ; exists (1:r1=1 /\ 1:r6=0) whose "exists" clause is not satisfiable according to the BPF memory model. Using the current RISC-V JIT lowerings, the test can be mapped to the following RISC-V litmus test: RISCV RISCV__MP+success_cmpxchg+fence { 0:x1=x; 0:x3=y; 0:x5=1; 1:x2=y; 1:x4=f; 1:x7=x; } P0 | P1 ; sd x5, 0(x1) | ld x1, 0(x2) ; L00: | amoadd.d.aqrl x3, x5, 0(x4) ; lr.d x2, 0(x3) | ld x6, 0(x7) ; bne x2, x4, L01 | ; sc.d x6, x5, 0(x3) | ; bne x6, x4, L00 | ; fence rw, rw | ; L01: | ; exists (1:x1=1 /\ 1:x6=0) where the two stores in P0 can be reordered. Update the RISC-V JIT lowerings/implementation of BPF_CMPXCHG to emit an SC with RELEASE ("rl") annotation in order to meet the expected memory ordering guarantees. The resulting RISC-V JIT lowerings of BPF_CMPXCHG match the RISC-V lowerings of the C atomic_cmpxchg(). Other lowerings were fixed via 20a759df3bba ("riscv, bpf: make some atomic operations fully ordered"). Fixes: dd642ccb45ec ("riscv, bpf: Implement more atomic operations for RV64") Signed-off-by: Andrea Parri <parri.andrea@gmail.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Reviewed-by: Puranjay Mohan <puranjay@kernel.org> Acked-by: Björn Töpel <bjorn@kernel.org> Link: https://lpc.events/event/18/contributions/1949/attachments/1665/3441/bpfmemmodel.2024.09.19p.pdf [1] Link: https://lore.kernel.org/bpf/20241017143628.2673894-1-parri.andrea@gmail.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-11-01s390: Initialize psw mask in perf_arch_fetch_caller_regs()Heiko Carstens1-0/+1
[ Upstream commit 223e7fb979fa06934f1595b6ad0ae1d4ead1147f ] Also initialize regs->psw.mask in perf_arch_fetch_caller_regs(). This way user_mode(regs) will return false, like it should. It looks like all current users initialize regs to zero, so that this doesn't fix a bug currently. However it is better to not rely on callers to do this. Fixes: 914d52e46490 ("s390: implement perf_arch_fetch_caller_regs") Signed-off-by: Heiko Carstens <hca@linux.ibm.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-11-01s390/pci: Handle PCI error codes other than 0x3aNiklas Schnelle1-8/+9
[ Upstream commit 3cd03ea57e8e16cc78cc357d5e9f26078426f236 ] The Linux implementation of PCI error recovery for s390 was based on the understanding that firmware error recovery is a two step process with an optional initial error event to indicate the cause of the error if known followed by either error event 0x3A (Success) or 0x3B (Failure) to indicate whether firmware was able to recover. While this has been the case in testing and the error cases seen in the wild it turns out this is not correct. Instead firmware only generates 0x3A for some error and service scenarios and expects the OS to perform recovery for all PCI events codes except for those indicating permanent error (0x3B, 0x40) and those indicating errors on the function measurement block (0x2A, 0x2B, 0x2C). Align Linux behavior with these expectations. Fixes: 4cdf2f4e24ff ("s390/pci: implement minimal PCI error recovery") Reviewed-by: Gerd Bayer <gbayer@linux.ibm.com> Signed-off-by: Niklas Schnelle <schnelle@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-11-01ARM: dts: bcm2837-rpi-cm3-io3: Fix HDMI hpd-gpio pinFlorian Klink1-1/+1
[ Upstream commit dc7785e4723510616d776862ddb4c08857a1bdb2 ] HDMI_HPD_N_1V8 is connected to GPIO pin 0, not 1. This fixes HDMI hotplug/output detection. See https://datasheets.raspberrypi.com/cm/cm3-schematics.pdf Signed-off-by: Florian Klink <flokli@flokli.de> Reviewed-by: Stefan Wahren <wahrenst@gmx.net> Link: https://lore.kernel.org/r/20240715230311.685641-1-flokli@flokli.de Reviewed-by: Stefan Wahren <wahrenst@gmx.net> Fixes: a54fe8a6cf66 ("ARM: dts: add Raspberry Pi Compute Module 3 and IO board") Signed-off-by: Florian Fainelli <florian.fainelli@broadcom.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-11-01x86/resctrl: Avoid overflow in MB settings in bw_validate()Martin Kletzander1-9/+14
[ Upstream commit 2b5648416e47933939dc310c4ea1e29404f35630 ] The resctrl schemata file supports specifying memory bandwidth associated with the Memory Bandwidth Allocation (MBA) feature via a percentage (this is the default) or bandwidth in MiBps (when resctrl is mounted with the "mba_MBps" option). The allowed range for the bandwidth percentage is from /sys/fs/resctrl/info/MB/min_bandwidth to 100, using a granularity of /sys/fs/resctrl/info/MB/bandwidth_gran. The supported range for the MiBps bandwidth is 0 to U32_MAX. There are two issues with parsing of MiBps memory bandwidth: * The user provided MiBps is mistakenly rounded up to the granularity that is unique to percentage input. * The user provided MiBps is parsed using unsigned long (thus accepting values up to ULONG_MAX), and then assigned to u32 that could result in overflow. Do not round up the MiBps value and parse user provided bandwidth as the u32 it is intended to be. Use the appropriate kstrtou32() that can detect out of range values. Fixes: 8205a078ba78 ("x86/intel_rdt/mba_sc: Add schemata support") Fixes: 6ce1560d35f6 ("x86/resctrl: Switch over to the resctrl mbps_val list") Co-developed-by: Reinette Chatre <reinette.chatre@intel.com> Signed-off-by: Reinette Chatre <reinette.chatre@intel.com> Signed-off-by: Martin Kletzander <nert.pinx@gmail.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Reviewed-by: Reinette Chatre <reinette.chatre@intel.com> Reviewed-by: Tony Luck <tony.luck@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-10-30arm64: dts: Sort out CM5 and I/O board I2C portsPhil Elwell8-61/+46
There is a difference in I2C usage between CM4IO and CM5IO. Present a simple, consistent view of the world by moving the assignment of the bus IDs into carrier-specific files. CM5 has reduced connectivity on CM4IO - the DPHYs are connected to CAM1 and DISP1. Keep i2c-10 for use with that pair, as is the case for CM4 on CM4IO. Fixes: 36faab69e8ee ("dts: bcm2712-rpi: Add aliases for the CSI/DSI I2Cs") See: https://github.com/raspberrypi/linux/pull/6421 Signed-off-by: Phil Elwell <phil@raspberrypi.com>
2024-10-25cgroup: Use kernel command line to disable memory cgroupMaíra Canal6-6/+6
Commit 94a23e978235 ("cgroup: Disable cgroup "memory" by default") disabled the memory cgroup by default when initing the cgroups. However, it's possible to disable the memory cgroup by a kernel command line. Hard-coding such a feature can be problematic as some memory management features depend on the order that things are set. For example, it is possible to see a NULL pointer dereference caused by commit 94a23e978235cd35f38075072b34152b2b667e6e. The NULL pointer dereference is triggered by the memory shrinker and ends up in a kernel crash. [ 50.028629] ================================================================== [ 50.028645] BUG: KASAN: null-ptr-deref in do_shrink_slab+0x1fc/0x978 [ 50.028663] Write of size 8 at addr 0000000000000000 by task gfxrecon-replay/1965 [ 50.028676] CPU: 3 UID: 1000 PID: 1965 Comm: gfxrecon-replay Tainted: G C 6.12.0-rc4-v8-thp-kasan+ #85 [ 50.028685] Tainted: [C]=CRAP [ 50.028689] Hardware name: Raspberry Pi 5 Model B Rev 1.0 (DT) [ 50.028694] Call trace: [ 50.028697] dump_backtrace+0xfc/0x120 [ 50.028706] show_stack+0x24/0x38 [ 50.028711] dump_stack_lvl+0x40/0x88 [ 50.028720] print_report+0xe4/0x708 [ 50.028728] kasan_report+0xcc/0x130 [ 50.028733] kasan_check_range+0x254/0x298 [ 50.028738] __kasan_check_write+0x20/0x30 [ 50.028745] do_shrink_slab+0x1fc/0x978 [ 50.028751] shrink_slab+0x318/0xc38 [ 50.028756] shrink_one+0x254/0x6d8 [ 50.028762] shrink_node+0x26b4/0x2848 [ 50.028767] do_try_to_free_pages+0x3e4/0x1190 [ 50.028773] try_to_free_pages+0x5a4/0xb40 [ 50.028778] __alloc_pages_direct_reclaim+0x144/0x298 [ 50.028787] __alloc_pages_slowpath+0x5c4/0xc70 [ 50.028793] __alloc_pages_noprof+0x4a8/0x6a8 [ 50.028800] __folio_alloc_noprof+0x24/0xa8 [ 50.028806] shmem_alloc_and_add_folio+0x2ec/0xce0 [ 50.028812] shmem_get_folio_gfp+0x380/0xc20 [ 50.028818] shmem_read_folio_gfp+0xe0/0x160 [ 50.028824] drm_gem_get_pages+0x238/0x620 [drm] [ 50.029039] drm_gem_shmem_get_pages_sgt+0xd8/0x4b8 [drm_shmem_helper] [ 50.029053] v3d_bo_create_finish+0x58/0x1e0 [v3d] [ 50.029083] v3d_create_bo_ioctl+0xac/0x210 [v3d] [ 50.029105] drm_ioctl_kernel+0x1d8/0x2b8 [drm] [ 50.029220] drm_ioctl+0x4b4/0x920 [drm] [ 50.029330] __arm64_sys_ioctl+0x11c/0x160 [ 50.029337] invoke_syscall+0x88/0x268 [ 50.029345] el0_svc_common+0x160/0x1d8 [ 50.029351] do_el0_svc+0x50/0x68 [ 50.029358] el0_svc+0x34/0x80 [ 50.029364] el0t_64_sync_handler+0x84/0x100 [ 50.029371] el0t_64_sync+0x190/0x198 [ 50.029376] ================================================================== This happens because the memory shrinker is unaware that we are artificially disabling the memory cgroups and therefore it doesn't allocate `nr_deferred` (as it would if we used the kernel command line). To avoid such an issue, revert the artificial disablement and disable it through the command line. If a user wants to enable the feature, it can use the `cgroup_enable=` command line. Signed-off-by: Maíra Canal <mcanal@igalia.com>
2024-10-25dts: Simplify bootargsPhil Elwell7-17/+9
Reduce the number of different places that bootargs is set in Pi dts files. The variants are all combinations of with/without Bluetooth and with/without NUMA support (2711). This is effectively a cosmetic change - the resulting dtbs are unchanged. Signed-off-by: Phil Elwell <phil@raspberrypi.com>
2024-10-23Merge remote-tracking branch 'stable/linux-6.6.y' into rpi-6.6.yDom Cobley16-38/+110
2024-10-22dts: Set preferred numa options in bootargsDom Cobley3-3/+3
The default cmdline adjustment is now numa_policy=interleave for 2711 and 2712, and additionally system_heap.max_order=0 iommu_dma_numa_policy=interleave for just 2712 (due to its better iommu support). The key setting numa=fake=<n> is not set here, so we will boot with a single numa region and behaviour should be pretty much unchanged from before this PR. Signed-off-by: Dom Cobley <popcornmix@gmail.com>
2024-10-22dts: Move some common rpi settings into rpi filesPhil Elwell6-18/+6
Most 2711 devices and all 2712 device share common bootargs (command lines). Make the common values shared defaults, overriding them were necessary. Signed-off-by: Phil Elwell <phil@raspberrypi.com>
2024-10-22config: bcm2711_defconfig/bcm2712_defconfig: Enable NUMADom Cobley2-0/+4
Allow NUMA and NUMA_EMULATION on 64-bit Pi kernels Signed-off-by: Dom Cobley <popcornmix@gmail.com>
generated by cgit v1.2.3 (git 2.25.1) at 2024-11-22 22:26:22 +0000