kernel/linux.git, branch v6.6.82

Linux 6.6.82

2025-03-09T08:55:04+00:00

Signed-off-by: Greg Kroah-Hartman

x86/boot/32: Temporarily map initrd for microcode loading

2025-03-09T08:55:04+00:00

commit 4c585af7180c147062c636a927a2fc2b6a7072f5 upstream Early microcode loading on 32-bit runs in physical address mode because the initrd is not covered by the initial page tables. That results in a horrible mess all over the microcode loader code. Provide a temporary mapping for the initrd in the initial page tables by appending it to the actual initial mapping starting with a new PGD or PMD depending on the configured page table levels ([non-]PAE). The page table entries are located after _brk_end so they are not permanently using memory space. The mapping is invalidated right away in i386_start_kernel() after the early microcode loader has run. This prepares for removing the physical address mode oddities from all over the microcode loader code, which in turn allows further cleanups. Provide the map and unmap code and document the place where the microcode loader needs to be invoked with a comment. Signed-off-by: Thomas Gleixner Signed-off-by: Borislav Petkov (AMD) Link: https://lore.kernel.org/r/20231017211722.292291436@linutronix.de Signed-off-by: Greg Kroah-Hartman

x86/microcode: Provide CONFIG_MICROCODE_INITRD32

2025-03-09T08:55:03+00:00

commit fdbd43819400e74c1c20a646969ea8f71706eb2b upstream Create an aggregate config switch which covers X86_32, MICROCODE and BLK_DEV_INITRD to avoid lengthy #ifdeffery in upcoming code. Signed-off-by: Thomas Gleixner Signed-off-by: Borislav Petkov (AMD) Link: https://lore.kernel.org/r/20231017211722.236208250@linutronix.de Signed-off-by: Greg Kroah-Hartman

x86/boot/32: Restructure mk_early_pgtbl_32()

2025-03-09T08:55:03+00:00

commit 69ba866db281c768d5ecca909361ea4c4e71d57e upstream Prepare it for adding a temporary initrd mapping by splitting out the actual map loop. No functional change. Signed-off-by: Thomas Gleixner Signed-off-by: Borislav Petkov (AMD) Link: https://lore.kernel.org/r/20231017211722.175910753@linutronix.de Signed-off-by: Greg Kroah-Hartman

x86/boot/32: De-uglify the 2/3 level paging difference in mk_early_pgtbl_32()

2025-03-09T08:55:03+00:00

commit a62f4ca106fd250e9247decd100f3905131fc1fe upstream Move the ifdeffery out of the function and use proper typedefs to make it work for both 2 and 3 level paging. No functional change. [ bp: Move mk_early_pgtbl_32() declaration into a header. ] Signed-off-by: Thomas Gleixner Signed-off-by: Borislav Petkov (AMD) Link: https://lore.kernel.org/r/20231017211722.111059491@linutronix.de Signed-off-by: Greg Kroah-Hartman

x86/boot: Use __pa_nodebug() in mk_early_pgtbl_32()

2025-03-09T08:55:03+00:00

commit 1e2dd572d2b773b5b8882aae66e5f0328d562aa9 upstream Use the existing macro instead of undefining and redefining __pa(). No functional change. Signed-off-by: Thomas Gleixner Signed-off-by: Borislav Petkov (AMD) Link: https://lore.kernel.org/r/20231017211722.051625827@linutronix.de Signed-off-by: Greg Kroah-Hartman

x86/boot/32: Disable stackprotector and tracing for mk_early_pgtbl_32()

2025-03-09T08:55:03+00:00

commit 242db7589460ca94e28c51ffbddd621756f97e11 upstream Stackprotector cannot work before paging is enabled. The read from the per CPU variable __stack_chk_guard is always accessing the virtual address either directly on UP or via FS on SMP. In physical address mode this results in an access to memory above 3GB. So this works by chance as the hardware returns the same value when there is no RAM at this physical address. When there is RAM populated above 3G then the read is by chance the same as nothing changes that memory during the very early boot stage. Stop relying on pure luck and disable the stack protector for the only C function which is called during early boot before paging is enabled. Remove function tracing from the whole source file as there is no way to trace this at all, but in case of CONFIG_DYNAMIC_FTRACE=n mk_early_pgtbl_32() would access global function tracer variables in physical address mode which again might work by chance. Signed-off-by: Thomas Gleixner Signed-off-by: Borislav Petkov (AMD) Link: https://lore.kernel.org/r/20231002115902.156063939@linutronix.de Signed-off-by: Greg Kroah-Hartman

Linux 6.6.81

2025-03-07T15:45:57+00:00

Link: https://lore.kernel.org/r/20250305174500.327985489@linuxfoundation.org Tested-by: Pavel Machek (CIP) Tested-by: SeongJae Park Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Mark Brown Tested-by: Shuah Khan Tested-by: Hardik Garg Link: https://lore.kernel.org/r/20250306151412.957725234@linuxfoundation.org Tested-by: Pavel Machek (CIP) Tested-by: Florian Fainelli Tested-by: Mark Brown Tested-by: Peter Schneider Tested-by: Jon Hunter Signed-off-by: Greg Kroah-Hartman

scsi: ufs: core: Cancel RTC work during ufshcd_remove()

2025-03-07T15:45:57+00:00

commit 1695c4361d35b7bdadd7b34f99c9c07741e181e5 upstream. Currently, RTC work is only cancelled during __ufshcd_wl_suspend(). When ufshcd is removed in ufshcd_remove(), RTC work is not cancelled. Due to this, any further trigger of the RTC work after ufshcd_remove() would result in a NULL pointer dereference as below: Unable to handle kernel NULL pointer dereference at virtual address 00000000000002a4 Workqueue: events ufshcd_rtc_work Call trace: _raw_spin_lock_irqsave+0x34/0x8c pm_runtime_get_if_active+0x24/0xb4 ufshcd_rtc_work+0x124/0x19c process_scheduled_works+0x18c/0x2d8 worker_thread+0x144/0x280 kthread+0x11c/0x128 ret_from_fork+0x10/0x20 Since RTC work accesses the ufshcd internal structures, it should be cancelled when ufshcd is removed. So do that in ufshcd_remove(), as per the order in ufshcd_init(). Cc: stable@vger.kernel.org # 6.8 Fixes: 6bf999e0eb41 ("scsi: ufs: core: Add UFS RTC support") Signed-off-by: Manivannan Sadhasivam Link: https://lore.kernel.org/r/20241111-ufs_bug_fix-v1-1-45ad8b62f02e@linaro.org Reviewed-by: Peter Wang Reviewed-by: Bean Huo Reviewed-by: Bart Van Assche Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman

scsi: ufs: core: Start the RTC update work later

2025-03-07T15:45:57+00:00

commit 54c814c8b23bc7617be3d46abdb896937695dbfa upstream. The RTC update work involves runtime resuming the UFS controller. Hence, only start the RTC update work after runtime power management in the UFS driver has been fully initialized. This patch fixes the following kernel crash: Internal error: Oops: 0000000096000006 [#1] PREEMPT SMP Workqueue: events ufshcd_rtc_work Call trace: _raw_spin_lock_irqsave+0x34/0x8c (P) pm_runtime_get_if_active+0x24/0x9c (L) pm_runtime_get_if_active+0x24/0x9c ufshcd_rtc_work+0x138/0x1b4 process_one_work+0x148/0x288 worker_thread+0x2cc/0x3d4 kthread+0x110/0x114 ret_from_fork+0x10/0x20 Reported-by: Neil Armstrong Closes: https://lore.kernel.org/linux-scsi/0c0bc528-fdc2-4106-bc99-f23ae377f6f5@linaro.org/ Fixes: 6bf999e0eb41 ("scsi: ufs: core: Add UFS RTC support") Cc: Bean Huo Cc: stable@vger.kernel.org Signed-off-by: Bart Van Assche Link: https://lore.kernel.org/r/20241031212632.2799127-1-bvanassche@acm.org Reviewed-by: Peter Wang Reviewed-by: Bean Huo Tested-by: Neil Armstrong # on SM8650-HDK Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman