user/sven/linux.git, branch v6.1.9

Linux 6.1.9

2023-02-01T07:38:58Z

Link: https://lore.kernel.org/r/20230130134336.532886729@linuxfoundation.org Tested-by: Florian Fainelli Tested-by: Shuah Khan Link: https://lore.kernel.org/r/20230130181611.883327545@linuxfoundation.org Tested-by: Conor Dooley Tested-by: Justin M. Forbes Tested-by: Takeshi Ogasawara Tested-by: Ronald Warsow Tested-by: Guenter Roeck Tested-by: Bagas Sanjaya Tested-by: Sudip Mukherjee Tested-by: Salvatore Bonaccorso Link: https://lore.kernel.org/r/20230131072621.746783417@linuxfoundation.org Tested-by: Ronald Warsow Tested-by: Bagas Sanjaya Tested-by: Takeshi Ogasawara Tested-by: Jon Hunter Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Allen Pais Tested-by: Fenil Jain Tested-by: Florian Fainelli Tested-by: Ron Economos Signed-off-by: Greg Kroah-Hartman

amdgpu: fix build on non-DCN platforms.

2023-02-01T07:34:51Z

commit f439a959dcfb6b39d6fd4b85ca1110a1d1de1587 upstream. This fixes the build here locally on my 32-bit arm build. Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman

perf/x86/amd: fix potential integer overflow on shift of a int

2023-02-01T07:34:51Z

commit 08245672cdc6505550d1a5020603b0a8d4a6dcc7 upstream. The left shift of int 32 bit integer constant 1 is evaluated using 32 bit arithmetic and then passed as a 64 bit function argument. In the case where i is 32 or more this can lead to an overflow. Avoid this by shifting using the BIT_ULL macro instead. Fixes: 471af006a747 ("perf/x86/amd: Constrain Large Increment per Cycle events") Signed-off-by: Colin Ian King Signed-off-by: Peter Zijlstra (Intel) Acked-by: Ian Rogers Acked-by: Kim Phillips Link: https://lore.kernel.org/r/20221202135149.1797974-1-colin.i.king@gmail.com Signed-off-by: Greg Kroah-Hartman

netfilter: conntrack: unify established states for SCTP paths

2023-02-01T07:34:51Z

commit a44b7651489f26271ac784b70895e8a85d0cebf4 upstream. An SCTP endpoint can start an association through a path and tear it down over another one. That means the initial path will not see the shutdown sequence, and the conntrack entry will remain in ESTABLISHED state for 5 days. By merging the HEARTBEAT_ACKED and ESTABLISHED states into one ESTABLISHED state, there remains no difference between a primary or secondary path. The timeout for the merged ESTABLISHED state is set to 210 seconds (hb_interval * max_path_retrans + rto_max). So, even if a path doesn't see the shutdown sequence, it will expire in a reasonable amount of time. With this change in place, there is now more than one state from which we can transition to ESTABLISHED, COOKIE_ECHOED and HEARTBEAT_SENT, so handle the setting of ASSURED bit whenever a state change has happened and the new state is ESTABLISHED. Removed the check for dir==REPLY since the transition to ESTABLISHED can happen only in the reply direction. Fixes: 9fb9cbb1082d ("[NETFILTER]: Add nf_conntrack subsystem.") Signed-off-by: Sriram Yagnaraman Signed-off-by: Pablo Neira Ayuso Signed-off-by: Greg Kroah-Hartman

dt-bindings: i2c: renesas,rzv2m: Fix SoC specific string

2023-02-01T07:34:51Z

commit 0a4eecf96c640886226f1ca7fdbb11bb20bc55b9 upstream. The preferred form for Renesas' compatible strings is: ",-" Somehow the compatible string for the r9a09g011 I2C IP was upstreamed as renesas,i2c-r9a09g011 instead of renesas,r9a09g011-i2c, which is really confusing, especially considering the generic fallback is renesas,rzv2m-i2c. The first user of renesas,i2c-r9a09g011 in the kernel is not yet in a kernel release, it will be in v6.1, therefore it can still be fixed in v6.1. Even if we don't fix it before v6.2, I don't think there is any harm in making such a change. s/renesas,i2c-r9a09g011/renesas,r9a09g011-i2c/g for consistency. Fixes: ba7a4d15e2c4 ("dt-bindings: i2c: Document RZ/V2M I2C controller") Signed-off-by: Fabrizio Castro Reviewed-by: Geert Uytterhoeven Reviewed-by: Krzysztof Kozlowski Signed-off-by: Wolfram Sang Signed-off-by: Greg Kroah-Hartman

x86/i8259: Mark legacy PIC interrupts with IRQ_LEVEL

2023-02-01T07:34:50Z

commit 5fa55950729d0762a787451dc52862c3f850f859 upstream. Baoquan reported that after triggering a crash the subsequent crash-kernel fails to boot about half of the time. It triggers a NULL pointer dereference in the periodic tick code. This happens because the legacy timer interrupt (IRQ0) is resent in software which happens in soft interrupt (tasklet) context. In this context get_irq_regs() returns NULL which leads to the NULL pointer dereference. The reason for the resend is a spurious APIC interrupt on the IRQ0 vector which is captured and leads to a resend when the legacy timer interrupt is enabled. This is wrong because the legacy PIC interrupts are level triggered and therefore should never be resent in software, but nothing ever sets the IRQ_LEVEL flag on those interrupts, so the core code does not know about their trigger type. Ensure that IRQ_LEVEL is set when the legacy PCI interrupts are set up. Fixes: a4633adcdbc1 ("[PATCH] genirq: add genirq sw IRQ-retrigger") Reported-by: Baoquan He Signed-off-by: Thomas Gleixner Tested-by: Baoquan He Link: https://lore.kernel.org/r/87mt6rjrra.ffs@tglx Signed-off-by: Greg Kroah-Hartman

dt-bindings: riscv: fix single letter canonical order

2023-02-01T07:34:50Z

commit a943385aa80151c6b2611d3a1cf8338af2b257a1 upstream. I used the wikipedia table for ordering extensions when updating the pattern here in commit 299824e68bd0 ("dt-bindings: riscv: add new riscv,isa strings for emulators"). Unfortunately that table did not match canonical order, as defined by the RISC-V ISA Manual, which defines extension ordering in (what is currently) Table 41, "Standard ISA extension names". Fix things up by re-sorting v (vector) and adding p (packed-simd) & j (dynamic languages). The e (reduced integer) and g (general) extensions are still intentionally left out. Link: https://github.com/riscv/riscv-isa-manual/releases/tag/riscv-unpriv-pdf-from-asciidoc-15112022 # Chapter 29.5 Fixes: 299824e68bd0 ("dt-bindings: riscv: add new riscv,isa strings for emulators") Acked-by: Guo Ren Reviewed-by: Heiko Stuebner Reviewed-by: Palmer Dabbelt Acked-by: Palmer Dabbelt Signed-off-by: Conor Dooley Acked-by: Rob Herring Link: https://lore.kernel.org/r/20221205174459.60195-3-conor@kernel.org Signed-off-by: Palmer Dabbelt Signed-off-by: Greg Kroah-Hartman

dt-bindings: riscv: fix underscore requirement for multi-letter extensions

2023-02-01T07:34:50Z

commit ec64efc4966edf19fa1bc398a26bddfbadc1605f upstream. The RISC-V ISA Manual allows the first multi-letter extension to avoid a leading underscore. Underscores are only required between multi-letter extensions. The dt-binding does not validate that a multi-letter extension is canonically ordered, as that'd need an even worse regex than is here, but it should not fail validation for valid ISA strings. Allow the first multi-letter extension to appear immediately after the single-letter extensions. Link: https://github.com/riscv/riscv-isa-manual/releases/tag/riscv-unpriv-pdf-from-asciidoc-15112022 # Chapter 29.5 Fixes: 299824e68bd0 ("dt-bindings: riscv: add new riscv,isa strings for emulators") Acked-by: Guo Ren Signed-off-by: Conor Dooley Acked-by: Rob Herring Reviewed-by: Palmer Dabbelt Acked-by: Palmer Dabbelt Link: https://lore.kernel.org/r/20221205174459.60195-2-conor@kernel.org Signed-off-by: Palmer Dabbelt Signed-off-by: Greg Kroah-Hartman

acpi: Fix suspend with Xen PV

2023-02-01T07:34:50Z

commit fe0ba8c23f9a35b0307eb662f16dd3a75fcdae41 upstream. Commit f1e525009493 ("x86/boot: Skip realmode init code when running as Xen PV guest") missed one code path accessing real_mode_header, leading to dereferencing NULL when suspending the system under Xen: [ 348.284004] PM: suspend entry (deep) [ 348.289532] Filesystems sync: 0.005 seconds [ 348.291545] Freezing user space processes ... (elapsed 0.000 seconds) done. [ 348.292457] OOM killer disabled. [ 348.292462] Freezing remaining freezable tasks ... (elapsed 0.104 seconds) done. [ 348.396612] printk: Suspending console(s) (use no_console_suspend to debug) [ 348.749228] PM: suspend devices took 0.352 seconds [ 348.769713] ACPI: EC: interrupt blocked [ 348.816077] BUG: kernel NULL pointer dereference, address: 000000000000001c [ 348.816080] #PF: supervisor read access in kernel mode [ 348.816081] #PF: error_code(0x0000) - not-present page [ 348.816083] PGD 0 P4D 0 [ 348.816086] Oops: 0000 [#1] PREEMPT SMP NOPTI [ 348.816089] CPU: 0 PID: 6764 Comm: systemd-sleep Not tainted 6.1.3-1.fc32.qubes.x86_64 #1 [ 348.816092] Hardware name: Star Labs StarBook/StarBook, BIOS 8.01 07/03/2022 [ 348.816093] RIP: e030:acpi_get_wakeup_address+0xc/0x20 Fix that by adding an optional acpi callback allowing to skip setting the wakeup address, as in the Xen PV case this will be handled by the hypervisor anyway. Fixes: f1e525009493 ("x86/boot: Skip realmode init code when running as Xen PV guest") Reported-by: Marek Marczykowski-Górecki Signed-off-by: Juergen Gross Signed-off-by: Dave Hansen Acked-by: Rafael J. Wysocki Link: https://lore.kernel.org/all/20230117155724.22940-1-jgross%40suse.com Signed-off-by: Greg Kroah-Hartman

x86/sev: Add SEV-SNP guest feature negotiation support

2023-02-01T07:34:50Z

commit 8c29f016540532582721cec1dbf6d144873433ba upstream. The hypervisor can enable various new features (SEV_FEATURES[1:63]) and start a SNP guest. Some of these features need guest side implementation. If any of these features are enabled without it, the behavior of the SNP guest will be undefined. It may fail booting in a non-obvious way making it difficult to debug. Instead of allowing the guest to continue and have it fail randomly later, detect this early and fail gracefully. The SEV_STATUS MSR indicates features which the hypervisor has enabled. While booting, SNP guests should ascertain that all the enabled features have guest side implementation. In case a feature is not implemented in the guest, the guest terminates booting with GHCB protocol Non-Automatic Exit(NAE) termination request event, see "SEV-ES Guest-Hypervisor Communication Block Standardization" document (currently at https://developer.amd.com/wp-content/resources/56421.pdf), section "Termination Request". Populate SW_EXITINFO2 with mask of unsupported features that the hypervisor can easily report to the user. More details in the AMD64 APM Vol 2, Section "SEV_STATUS MSR". [ bp: - Massage. - Move snp_check_features() call to C code. Note: the CC:stable@ aspect here is to be able to protect older, stable kernels when running on newer hypervisors. Or not "running" but fail reliably and in a well-defined manner instead of randomly. ] Fixes: cbd3d4f7c4e5 ("x86/sev: Check SEV-SNP features support") Signed-off-by: Nikunj A Dadhania Signed-off-by: Borislav Petkov (AMD) Reviewed-by: Tom Lendacky Cc: Link: https://lore.kernel.org/r/20230118061943.534309-1-nikunj@amd.com Signed-off-by: Greg Kroah-Hartman