commit 103a4e4a4351d3d5214c4f54fdf89f0f81b692ef Author: Greg Kroah-Hartman Date: Wed Jun 12 11:39:59 2024 +0200 Linux 6.9.4 Link: https://lore.kernel.org/r/20240606131651.683718371@linuxfoundation.org Tested-by: Ronald Warsow Tested-by: SeongJae Park Tested-by: Pavel Machek (CIP) Tested-by: Shuah Khan Tested-by: Bagas Sanjaya Tested-by: Jon Hunter Tested-by: Mark Brown Tested-by: Allen Pais Tested-by: Pascal Ernster Tested-by: Ron Economos Tested-by: Peter Schneider Link: https://lore.kernel.org/r/20240609113803.338372290@linuxfoundation.org Tested-by: Ronald Warsow Tested-by: SeongJae Park Tested-by: Bagas Sanjaya Tested-by: Mark Brown Tested-by: Jon Hunter Tested-by: Linux Kernel Functional Testing Tested-by: Kelsey Steele Signed-off-by: Greg Kroah-Hartman commit 41fa936c3adaea4cb552680281fd403bc5038c9b Author: Srinivas Pandruvada Date: Mon Apr 15 14:52:10 2024 -0700 platform/x86/intel-uncore-freq: Don't present root domain on error commit db643cb7ebe524d17b4b13583dda03485d4a1bc0 upstream. If none of the clusters are added because of some error, fail to load driver without presenting root domain. In this case root domain will present invalid data. Signed-off-by: Srinivas Pandruvada Fixes: 01c10f88c9b7 ("platform/x86/intel-uncore-freq: tpmi: Provide cluster level control") Cc: # 6.5+ Link: https://lore.kernel.org/r/20240415215210.2824868-1-srinivas.pandruvada@linux.intel.com Reviewed-by: Hans de Goede Signed-off-by: Hans de Goede Signed-off-by: Greg Kroah-Hartman commit 1dbeaa75ce5edae95b98ccd6e4f2ed26dfee03ae Author: Srinivas Pandruvada Date: Tue Apr 23 13:46:10 2024 -0700 platform/x86/intel/tpmi: Handle error from tpmi_process_info() commit 2920141fc149f71bad22361946417bc43783ed7f upstream. When tpmi_process_info() returns error, fail to load the driver. This can happen if call to ioremap() returns error. Signed-off-by: Srinivas Pandruvada Reviewed-by: Ilpo Järvinen Cc: stable@vger.kernel.org # v6.3+ Link: https://lore.kernel.org/r/20240423204619.3946901-2-srinivas.pandruvada@linux.intel.com Reviewed-by: Hans de Goede Signed-off-by: Hans de Goede Signed-off-by: Greg Kroah-Hartman commit ebfb16fc057a016abb46a9720a54abf0d4f6abe1 Author: Dongli Zhang Date: Wed May 22 15:02:18 2024 -0700 genirq/cpuhotplug, x86/vector: Prevent vector leak during CPU offline commit a6c11c0a5235fb144a65e0cb2ffd360ddc1f6c32 upstream. The absence of IRQD_MOVE_PCNTXT prevents immediate effectiveness of interrupt affinity reconfiguration via procfs. Instead, the change is deferred until the next instance of the interrupt being triggered on the original CPU. When the interrupt next triggers on the original CPU, the new affinity is enforced within __irq_move_irq(). A vector is allocated from the new CPU, but the old vector on the original CPU remains and is not immediately reclaimed. Instead, apicd->move_in_progress is flagged, and the reclaiming process is delayed until the next trigger of the interrupt on the new CPU. Upon the subsequent triggering of the interrupt on the new CPU, irq_complete_move() adds a task to the old CPU's vector_cleanup list if it remains online. Subsequently, the timer on the old CPU iterates over its vector_cleanup list, reclaiming old vectors. However, a rare scenario arises if the old CPU is outgoing before the interrupt triggers again on the new CPU. In that case irq_force_complete_move() is not invoked on the outgoing CPU to reclaim the old apicd->prev_vector because the interrupt isn't currently affine to the outgoing CPU, and irq_needs_fixup() returns false. Even though __vector_schedule_cleanup() is later called on the new CPU, it doesn't reclaim apicd->prev_vector; instead, it simply resets both apicd->move_in_progress and apicd->prev_vector to 0. As a result, the vector remains unreclaimed in vector_matrix, leading to a CPU vector leak. To address this issue, move the invocation of irq_force_complete_move() before the irq_needs_fixup() call to reclaim apicd->prev_vector, if the interrupt is currently or used to be affine to the outgoing CPU. Additionally, reclaim the vector in __vector_schedule_cleanup() as well, following a warning message, although theoretically it should never see apicd->move_in_progress with apicd->prev_cpu pointing to an offline CPU. Fixes: f0383c24b485 ("genirq/cpuhotplug: Add support for cleaning up move in progress") Signed-off-by: Dongli Zhang Signed-off-by: Thomas Gleixner Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20240522220218.162423-1-dongli.zhang@oracle.com Signed-off-by: Greg Kroah-Hartman commit f7c6d909a2d412e6d7cf36d7a60d26f6fbcdfa39 Author: Thomas Gleixner Date: Thu May 30 17:29:18 2024 +0200 x86/topology/intel: Unlock CPUID before evaluating anything commit 0c2f6d04619ec2b53ad4b0b591eafc9389786e86 upstream. Intel CPUs have a MSR bit to limit CPUID enumeration to leaf two. If this bit is set by the BIOS then CPUID evaluation including topology enumeration does not work correctly as the evaluation code does not try to analyze any leaf greater than two. This went unnoticed before because the original topology code just repeated evaluation several times and managed to overwrite the initial limited information with the correct one later. The new evaluation code does it once and therefore ends up with the limited and wrong information. Cure this by unlocking CPUID right before evaluating anything which depends on the maximum CPUID leaf being greater than two instead of rereading stuff after unlock. Fixes: 22d63660c35e ("x86/cpu: Use common topology code for Intel") Reported-by: Peter Schneider Signed-off-by: Thomas Gleixner Signed-off-by: Borislav Petkov (AMD) Tested-by: Peter Schneider Cc: Link: https://lore.kernel.org/r/fd3f73dc-a86f-4bcf-9c60-43556a21eb42@googlemail.com Signed-off-by: Greg Kroah-Hartman commit db856aea9cf062c4d7126ea5853045725c8e30fc Author: Gerd Hoffmann Date: Wed Mar 13 13:58:42 2024 +0100 KVM: x86: Don't advertise guest.MAXPHYADDR as host.MAXPHYADDR in CPUID commit 6f5c9600621b4efb5c61b482d767432eb1ad3a9c upstream. Drop KVM's propagation of GuestPhysBits (CPUID leaf 80000008, EAX[23:16]) to HostPhysBits (same leaf, EAX[7:0]) when advertising the address widths to userspace via KVM_GET_SUPPORTED_CPUID. Per AMD, GuestPhysBits is intended for software use, and physical CPUs do not set that field. I.e. GuestPhysBits will be non-zero if and only if KVM is running as a nested hypervisor, and in that case, GuestPhysBits is NOT guaranteed to capture the CPU's effective MAXPHYADDR when running with TDP enabled. E.g. KVM will soon use GuestPhysBits to communicate the CPU's maximum *addressable* guest physical address, which would result in KVM under- reporting PhysBits when running as an L1 on a CPU with MAXPHYADDR=52, but without 5-level paging. Signed-off-by: Gerd Hoffmann Cc: stable@vger.kernel.org Reviewed-by: Xiaoyao Li Link: https://lore.kernel.org/r/20240313125844.912415-2-kraxel@redhat.com [sean: rewrite changelog with --verbose, Cc stable@] Signed-off-by: Sean Christopherson Signed-off-by: Greg Kroah-Hartman commit 78d94a35dbe793d2a481415e60600f3e342a858e Author: Bjorn Helgaas Date: Wed Apr 17 15:40:12 2024 -0500 x86/pci: Skip early E820 check for ECAM region commit 199f968f1484a14024d0d467211ffc2faf193eb4 upstream. Arul, Mateusz, Imcarneiro91, and Aman reported a regression caused by 07eab0901ede ("efi/x86: Remove EfiMemoryMappedIO from E820 map"). On the Lenovo Legion 9i laptop, that commit removes the ECAM area from E820, which means the early E820 validation fails, which means we don't enable ECAM in the "early MCFG" path. The static MCFG table describes ECAM without depending on the ACPI interpreter. Many Legion 9i ACPI methods rely on that, so they fail when PCI config access isn't available, resulting in the embedded controller, PS/2, audio, trackpad, and battery devices not being detected. The _OSC method also fails, so Linux can't take control of the PCIe hotplug, PME, and AER features: # pci_mmcfg_early_init() PCI: ECAM [mem 0xc0000000-0xce0fffff] (base 0xc0000000) for domain 0000 [bus 00-e0] PCI: not using ECAM ([mem 0xc0000000-0xce0fffff] not reserved) ACPI Error: AE_ERROR, Returned by Handler for [PCI_Config] (20230628/evregion-300) ACPI: Interpreter enabled ACPI: Ignoring error and continuing table load ACPI BIOS Error (bug): Could not resolve symbol [\_SB.PC00.RP01._SB.PC00], AE_NOT_FOUND (20230628/dswload2-162) ACPI Error: AE_NOT_FOUND, During name lookup/catalog (20230628/psobject-220) ACPI: Skipping parse of AML opcode: OpcodeName unavailable (0x0010) ACPI BIOS Error (bug): Could not resolve symbol [\_SB.PC00.RP01._SB.PC00], AE_NOT_FOUND (20230628/dswload2-162) ACPI Error: AE_NOT_FOUND, During name lookup/catalog (20230628/psobject-220) ... ACPI Error: Aborting method \_SB.PC00._OSC due to previous error (AE_NOT_FOUND) (20230628/psparse-529) acpi PNP0A08:00: _OSC: platform retains control of PCIe features (AE_NOT_FOUND) # pci_mmcfg_late_init() PCI: ECAM [mem 0xc0000000-0xce0fffff] (base 0xc0000000) for domain 0000 [bus 00-e0] PCI: [Firmware Info]: ECAM [mem 0xc0000000-0xce0fffff] not reserved in ACPI motherboard resources PCI: ECAM [mem 0xc0000000-0xce0fffff] is EfiMemoryMappedIO; assuming valid PCI: ECAM [mem 0xc0000000-0xce0fffff] reserved to work around lack of ACPI motherboard _CRS Per PCI Firmware r3.3, sec 4.1.2, ECAM space must be reserved by a PNP0C02 resource, but there's no requirement to mention it in E820, so we shouldn't look at E820 to validate the ECAM space described by MCFG. In 2006, 946f2ee5c731 ("[PATCH] i386/x86-64: Check that MCFG points to an e820 reserved area") added a sanity check of E820 to work around buggy MCFG tables, but that over-aggressive validation causes failures like this one. Keep the E820 validation check for machines older than 2016, an arbitrary ten years after 946f2ee5c731, so machines that depend on it don't break. Skip the early E820 check for 2016 and newer BIOSes since there's no requirement to describe ECAM in E820. Link: https://lore.kernel.org/r/20240417204012.215030-2-helgaas@kernel.org Fixes: 07eab0901ede ("efi/x86: Remove EfiMemoryMappedIO from E820 map") Reported-by: Mateusz Kaduk Closes: https://bugzilla.kernel.org/show_bug.cgi?id=218444 Signed-off-by: Bjorn Helgaas Tested-by: Mateusz Kaduk Reviewed-by: Andy Shevchenko Reviewed-by: Hans de Goede Reviewed-by: Kuppuswamy Sathyanarayanan Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 268ea2acacf01c1be3f0ba002df8b216d7b7d8ae Author: Thomas Gleixner Date: Fri May 17 16:40:36 2024 +0200 x86/topology: Handle bogus ACPI tables correctly commit 9d22c96316ac59ed38e80920c698fed38717b91b upstream. The ACPI specification clearly states how the processors should be enumerated in the MADT: "To ensure that the boot processor is supported post initialization, two guidelines should be followed. The first is that OSPM should initialize processors in the order that they appear in the MADT. The second is that platform firmware should list the boot processor as the first processor entry in the MADT. ... Failure of OSPM implementations and platform firmware to abide by these guidelines can result in both unpredictable and non optimal platform operation." The kernel relies on that ordering to detect the real BSP on crash kernels which is important to avoid sending a INIT IPI to it as that would cause a full machine reset. On a Dell XPS 16 9640 the BIOS ignores this rule and enumerates the CPUs in the wrong order. As a consequence the kernel falsely detects a crash kernel and disables the corresponding CPU. Prevent this by checking the IA32_APICBASE MSR for the BSP bit on the boot CPU. If that bit is set, then the MADT based BSP detection can be safely ignored. If the kernel detects a mismatch between the BSP bit and the first enumerated MADT entry then emit a firmware bug message. This obviously also has to be taken into account when the boot APIC ID and the first enumerated APIC ID match. If the boot CPU does not have the BSP bit set in the APICBASE MSR then there is no way for the boot CPU to determine which of the CPUs is the real BSP. Sending an INIT to the real BSP would reset the machine so the only sane way to deal with that is to limit the number of CPUs to one and emit a corresponding warning message. Fixes: 5c5682b9f87a ("x86/cpu: Detect real BSP on crash kernels") Reported-by: Carsten Tolkmit Signed-off-by: Thomas Gleixner Tested-by: Carsten Tolkmit Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/87le48jycb.ffs@tglx Closes: https://bugzilla.kernel.org/show_bug.cgi?id=218837 Signed-off-by: Greg Kroah-Hartman commit 6ca67a5fe1c606d1fbe24c30a9fc0bdc43a18554 Author: Hagar Hemdan Date: Tue Apr 23 13:59:26 2024 +0000 efi: libstub: only free priv.runtime_map when allocated commit 4b2543f7e1e6b91cfc8dd1696e3cdf01c3ac8974 upstream. priv.runtime_map is only allocated when efi_novamap is not set. Otherwise, it is an uninitialized value. In the error path, it is freed unconditionally. Avoid passing an uninitialized value to free_pool. Free priv.runtime_map only when it was allocated. This bug was discovered and resolved using Coverity Static Analysis Security Testing (SAST) by Synopsys, Inc. Fixes: f80d26043af9 ("efi: libstub: avoid efi_get_memory_map() for allocating the virt map") Cc: Signed-off-by: Hagar Hemdan Signed-off-by: Ard Biesheuvel Signed-off-by: Greg Kroah-Hartman commit f949dce98679fdf2f074841d1a2c0383382cad47 Author: Ard Biesheuvel Date: Thu May 16 11:05:42 2024 +0200 x86/efistub: Omit physical KASLR when memory reservations exist commit 15aa8fb852f995dd234a57f12dfb989044968bb6 upstream. The legacy decompressor has elaborate logic to ensure that the randomized physical placement of the decompressed kernel image does not conflict with any memory reservations, including ones specified on the command line using mem=, memmap=, efi_fake_mem= or hugepages=, which are taken into account by the kernel proper at a later stage. When booting in EFI mode, it is the firmware's job to ensure that the chosen range does not conflict with any memory reservations that it knows about, and this is trivially achieved by using the firmware's memory allocation APIs. That leaves reservations specified on the command line, though, which the firmware knows nothing about, as these regions have no other special significance to the platform. Since commit a1b87d54f4e4 ("x86/efistub: Avoid legacy decompressor when doing EFI boot") these reservations are not taken into account when randomizing the physical placement, which may result in conflicts where the memory cannot be reserved by the kernel proper because its own executable image resides there. To avoid having to duplicate or reuse the existing complicated logic, disable physical KASLR entirely when such overrides are specified. These are mostly diagnostic tools or niche features, and physical KASLR (as opposed to virtual KASLR, which is much more important as it affects the memory addresses observed by code executing in the kernel) is something we can live without. Closes: https://lkml.kernel.org/r/FA5F6719-8824-4B04-803E-82990E65E627%40akamai.com Reported-by: Ben Chaney Fixes: a1b87d54f4e4 ("x86/efistub: Avoid legacy decompressor when doing EFI boot") Cc: # v6.1+ Reviewed-by: Kees Cook Signed-off-by: Ard Biesheuvel Signed-off-by: Greg Kroah-Hartman commit 7a5bc0f266e78476f04583c25c9ab7b6785a53ae Author: Geert Uytterhoeven Date: Mon Apr 22 12:30:38 2024 +0200 Revert "drm: Make drivers depends on DRM_DW_HDMI" commit 8f7f115596d3dccedc06f5813e0269734f5cc534 upstream. This reverts commit c0e0f139354c01e0213204e4a96e7076e5a3e396, as helper code should always be selected by the driver that needs it, for the convenience of the final user configuring a kernel. The user who configures a kernel should not need to know which helpers are needed for the driver he is interested in. Making a driver depend on helper code means that the user needs to know which helpers to enable first, which is very user-unfriendly. Signed-off-by: Geert Uytterhoeven Acked-by: Arnd Bergmann Link: https://patchwork.freedesktop.org/patch/msgid/bd93d43b07f8ed6368119f4a5ddac2ee80debe53.1713780345.git.geert+renesas@glider.be Signed-off-by: Maxime Ripard Cc: Mark Brown Signed-off-by: Greg Kroah-Hartman commit ac54c155b76d304c59044deef74d8614578dc576 Author: Takashi Iwai Date: Fri May 31 09:51:07 2024 +0200 ALSA: seq: ump: Fix swapped song position pointer data [ Upstream commit 310fa3ec2859f1c094e6e9b5d2e1ca51738c409a ] At converting between the legacy event and UMP, the parameters for MIDI Song Position Pointer are incorrectly stored. It should have been LSB -> MSB order while it stored in MSB -> LSB order. This patch corrects the ordering. Fixes: e9e02819a98a ("ALSA: seq: Automatic conversion of UMP events") Link: https://lore.kernel.org/r/20240531075110.3250-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 0c1f28c32a194303da630fca89481334b9547b80 Author: Sergey Matyukevich Date: Thu May 23 11:43:23 2024 +0300 riscv: prevent pt_regs corruption for secondary idle threads [ Upstream commit a638b0461b58aa3205cd9d5f14d6f703d795b4af ] Top of the kernel thread stack should be reserved for pt_regs. However this is not the case for the idle threads of the secondary boot harts. Their stacks overlap with their pt_regs, so both may get corrupted. Similar issue has been fixed for the primary hart, see c7cdd96eca28 ("riscv: prevent stack corruption by reserving task_pt_regs(p) early"). However that fix was not propagated to the secondary harts. The problem has been noticed in some CPU hotplug tests with V enabled. The function smp_callin stored several registers on stack, corrupting top of pt_regs structure including status field. As a result, kernel attempted to save or restore inexistent V context. Fixes: 9a2451f18663 ("RISC-V: Avoid using per cpu array for ordered booting") Fixes: 2875fe056156 ("RISC-V: Add cpu_ops and modify default booting method") Signed-off-by: Sergey Matyukevich Reviewed-by: Alexandre Ghiti Link: https://lore.kernel.org/r/20240523084327.2013211-1-geomatsi@gmail.com Signed-off-by: Palmer Dabbelt Signed-off-by: Sasha Levin commit 5626d5b744cde73ed6d939633fcec6d65a8488ff Author: Guenter Roeck Date: Thu May 30 08:20:14 2024 -0700 hwmon: (shtc1) Fix property misspelling [ Upstream commit 52a2c70c3ec555e670a34dd1ab958986451d2dd2 ] The property name is "sensirion,low-precision", not "sensicon,low-precision". Cc: Chris Ruehl Fixes: be7373b60df5 ("hwmon: shtc1: add support for device tree bindings") Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit 1479015702b7b5bd9128105c67e863baa8db653d Author: Peter Colberg Date: Tue May 21 14:12:46 2024 -0400 hwmon: (intel-m10-bmc-hwmon) Fix multiplier for N6000 board power sensor [ Upstream commit 027a44fedd55fbdf1d45603894634acd960ad04b ] The Intel N6000 BMC outputs the board power value in milliwatt, whereas the hwmon sysfs interface must provide power values in microwatt. Fixes: e1983220ae14 ("hwmon: intel-m10-bmc-hwmon: Add N6000 sensors") Signed-off-by: Peter Colberg Reviewed-by: Matthew Gerlach Link: https://lore.kernel.org/r/20240521181246.683833-1-peter.colberg@intel.com Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit c7ca42116e7931754df6d40cb0860f8995104274 Author: Gerald Loacker Date: Wed May 29 16:42:47 2024 +0200 drm/panel: sitronix-st7789v: fix display size for jt240mhqs_hwt_ek_e3 panel [ Upstream commit b62c150c3bae72ac1910dcc588f360159eb0744a ] This is a portrait mode display. Change the dimensions accordingly. Fixes: 0fbbe96bfa08 ("drm/panel: sitronix-st7789v: add jasonic jt240mhqs-hwt-ek-e3 support") Signed-off-by: Gerald Loacker Acked-by: Jessica Zhang Link: https://lore.kernel.org/r/20240409-bugfix-jt240mhqs_hwt_ek_e3-timing-v2-3-e4821802443d@wolfvision.net Signed-off-by: Neil Armstrong Link: https://patchwork.freedesktop.org/patch/msgid/20240409-bugfix-jt240mhqs_hwt_ek_e3-timing-v2-3-e4821802443d@wolfvision.net Signed-off-by: Sasha Levin commit 9938a1715cd8614af3bbf2442594867a0bd8eb3c Author: Gerald Loacker Date: Wed May 29 16:42:46 2024 +0200 drm/panel: sitronix-st7789v: tweak timing for jt240mhqs_hwt_ek_e3 panel [ Upstream commit 2ba50582634d0bfe3a333ab7575a7f0122a7cde8 ] Use the default timing parameters to get a refresh rate of about 60 Hz for a clock of 6 MHz. Fixes: 0fbbe96bfa08 ("drm/panel: sitronix-st7789v: add jasonic jt240mhqs-hwt-ek-e3 support") Signed-off-by: Gerald Loacker Acked-by: Jessica Zhang Link: https://lore.kernel.org/r/20240409-bugfix-jt240mhqs_hwt_ek_e3-timing-v2-2-e4821802443d@wolfvision.net Signed-off-by: Neil Armstrong Link: https://patchwork.freedesktop.org/patch/msgid/20240409-bugfix-jt240mhqs_hwt_ek_e3-timing-v2-2-e4821802443d@wolfvision.net Signed-off-by: Sasha Levin commit 6d3934a09d6d266c2b6e5a24d8b4b437dd6f12c6 Author: Gerald Loacker Date: Wed May 29 16:42:45 2024 +0200 drm/panel: sitronix-st7789v: fix timing for jt240mhqs_hwt_ek_e3 panel [ Upstream commit 0e5895ff7fab0fc05ec17daf9a568368828fa6ea ] Flickering was observed when using partial mode. Moving the vsync to the same position as used by the default sitronix-st7789v timing resolves this issue. Fixes: 0fbbe96bfa08 ("drm/panel: sitronix-st7789v: add jasonic jt240mhqs-hwt-ek-e3 support") Acked-by: Jessica Zhang Signed-off-by: Gerald Loacker Link: https://lore.kernel.org/r/20240409-bugfix-jt240mhqs_hwt_ek_e3-timing-v2-1-e4821802443d@wolfvision.net Signed-off-by: Neil Armstrong Link: https://patchwork.freedesktop.org/patch/msgid/20240409-bugfix-jt240mhqs_hwt_ek_e3-timing-v2-1-e4821802443d@wolfvision.net Signed-off-by: Sasha Levin commit a06dc08de516f780e03f39e15f47adb4229146fc Author: Nathan Lynch Date: Fri May 24 14:29:54 2024 -0500 powerpc/pseries/lparcfg: drop error message from guest name lookup [ Upstream commit 12870ae3818e39ea65bf710f645972277b634f72 ] It's not an error or exceptional situation when the hosting environment does not expose a name for the LP/guest via RTAS or the device tree. This happens with qemu when run without the '-name' option. The message also lacks a newline. Remove it. Signed-off-by: Nathan Lynch Fixes: eddaa9a40275 ("powerpc/pseries: read the lpar name from the firmware") Signed-off-by: Michael Ellerman Link: https://msgid.link/20240524-lparcfg-updates-v2-1-62e2e9d28724@linux.ibm.com Signed-off-by: Sasha Levin commit 94a132ce910c2f0a43f2ac1feda93c0c74fa0676 Author: Takashi Iwai Date: Thu May 30 12:10:43 2024 +0200 ALSA: seq: Fix yet another spot for system message conversion [ Upstream commit 700fe6fd093d08c6da2bda8efe00479b0e617327 ] We fixed the incorrect UMP type for system messages in the recent commit, but it missed one place in system_ev_to_ump_midi1(). Fix it now. Fixes: e9e02819a98a ("ALSA: seq: Automatic conversion of UMP events") Fixes: c2bb79613fed ("ALSA: seq: Fix incorrect UMP type for system messages") Link: https://lore.kernel.org/r/20240530101044.17524-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 13c4543db34e0da5a7d2f550b6262d860f248381 Author: Yue Haibing Date: Wed May 29 17:56:33 2024 +0800 ipvlan: Dont Use skb->sk in ipvlan_process_v{4,6}_outbound [ Upstream commit b3dc6e8003b500861fa307e9a3400c52e78e4d3a ] Raw packet from PF_PACKET socket ontop of an IPv6-backed ipvlan device will hit WARN_ON_ONCE() in sk_mc_loop() through sch_direct_xmit() path. WARNING: CPU: 2 PID: 0 at net/core/sock.c:775 sk_mc_loop+0x2d/0x70 Modules linked in: sch_netem ipvlan rfkill cirrus drm_shmem_helper sg drm_kms_helper CPU: 2 PID: 0 Comm: swapper/2 Kdump: loaded Not tainted 6.9.0+ #279 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 RIP: 0010:sk_mc_loop+0x2d/0x70 Code: fa 0f 1f 44 00 00 65 0f b7 15 f7 96 a3 4f 31 c0 66 85 d2 75 26 48 85 ff 74 1c RSP: 0018:ffffa9584015cd78 EFLAGS: 00010212 RAX: 0000000000000011 RBX: ffff91e585793e00 RCX: 0000000002c6a001 RDX: 0000000000000000 RSI: 0000000000000040 RDI: ffff91e589c0f000 RBP: ffff91e5855bd100 R08: 0000000000000000 R09: 3d00545216f43d00 R10: ffff91e584fdcc50 R11: 00000060dd8616f4 R12: ffff91e58132d000 R13: ffff91e584fdcc68 R14: ffff91e5869ce800 R15: ffff91e589c0f000 FS: 0000000000000000(0000) GS:ffff91e898100000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f788f7c44c0 CR3: 0000000008e1a000 CR4: 00000000000006f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ? __warn (kernel/panic.c:693) ? sk_mc_loop (net/core/sock.c:760) ? report_bug (lib/bug.c:201 lib/bug.c:219) ? handle_bug (arch/x86/kernel/traps.c:239) ? exc_invalid_op (arch/x86/kernel/traps.c:260 (discriminator 1)) ? asm_exc_invalid_op (./arch/x86/include/asm/idtentry.h:621) ? sk_mc_loop (net/core/sock.c:760) ip6_finish_output2 (net/ipv6/ip6_output.c:83 (discriminator 1)) ? nf_hook_slow (net/netfilter/core.c:626) ip6_finish_output (net/ipv6/ip6_output.c:222) ? __pfx_ip6_finish_output (net/ipv6/ip6_output.c:215) ipvlan_xmit_mode_l3 (drivers/net/ipvlan/ipvlan_core.c:602) ipvlan ipvlan_start_xmit (drivers/net/ipvlan/ipvlan_main.c:226) ipvlan dev_hard_start_xmit (net/core/dev.c:3594) sch_direct_xmit (net/sched/sch_generic.c:343) __qdisc_run (net/sched/sch_generic.c:416) net_tx_action (net/core/dev.c:5286) handle_softirqs (kernel/softirq.c:555) __irq_exit_rcu (kernel/softirq.c:589) sysvec_apic_timer_interrupt (arch/x86/kernel/apic/apic.c:1043) The warning triggers as this: packet_sendmsg packet_snd //skb->sk is packet sk __dev_queue_xmit __dev_xmit_skb //q->enqueue is not NULL __qdisc_run sch_direct_xmit dev_hard_start_xmit ipvlan_start_xmit ipvlan_xmit_mode_l3 //l3 mode ipvlan_process_outbound //vepa flag ipvlan_process_v6_outbound ip6_local_out __ip6_finish_output ip6_finish_output2 //multicast packet sk_mc_loop //sk->sk_family is AF_PACKET Call ip{6}_local_out() with NULL sk in ipvlan as other tunnels to fix this. Fixes: 2ad7bf363841 ("ipvlan: Initial check-in of the IPVLAN driver.") Suggested-by: Eric Dumazet Signed-off-by: Yue Haibing Reviewed-by: Eric Dumazet Link: https://lore.kernel.org/r/20240529095633.613103-1-yuehaibing@huawei.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 841baa7e30bec950ebecd38e0cc912c6d8b4f473 Author: Shay Agroskin Date: Tue May 28 20:09:12 2024 +0300 net: ena: Fix redundant device NUMA node override [ Upstream commit 2dc8b1e7177d4f49f492ce648440caf2de0c3616 ] The driver overrides the NUMA node id of the device regardless of whether it knows its correct value (often setting it to -1 even though the node id is advertised in 'struct device'). This can lead to suboptimal configurations. This patch fixes this behavior and makes the shared memory allocation functions use the NUMA node id advertised by the underlying device. Fixes: 1738cd3ed342 ("net: ena: Add a driver for Amazon Elastic Network Adapters (ENA)") Signed-off-by: Shay Agroskin Link: https://lore.kernel.org/r/20240528170912.1204417-1-shayagr@amazon.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit afb6b63c700c050bda4cb7ffd8ea0c68a8a718ae Author: Paul Greenwalt Date: Tue May 28 15:06:08 2024 -0700 ice: fix 200G PHY types to link speed mapping [ Upstream commit 2a6d8f2de2224ac46df94dc40f43f8b9701f6703 ] Commit 24407a01e57c ("ice: Add 200G speed/phy type use") added support for 200G PHY speeds, but did not include the mapping of 200G PHY types to link speed. As a result the driver is returning UNKNOWN link speed when setting 200G ethtool advertised link modes. To fix this add 200G PHY types to link speed mapping to ice_get_link_speed_based_on_phy_type(). Fixes: 24407a01e57c ("ice: Add 200G speed/phy type use") Reviewed-by: Michal Swiatkowski Signed-off-by: Paul Greenwalt Tested-by: Pucha Himasekhar Reddy Signed-off-by: Jacob Keller Link: https://lore.kernel.org/r/20240528-net-2024-05-28-intel-net-fixes-v1-5-dc8593d2bbc6@intel.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 797c6534f0160d8018462b5cd540de967032299f Author: Tristram Ha Date: Tue May 28 14:34:26 2024 -0700 net: dsa: microchip: fix RGMII error in KSZ DSA driver [ Upstream commit 278d65ccdadb5f0fa0ceaf7b9cc97b305cd72822 ] The driver should return RMII interface when XMII is running in RMII mode. Fixes: 0ab7f6bf1675 ("net: dsa: microchip: ksz9477: use common xmii function") Signed-off-by: Tristram Ha Acked-by: Arun Ramadoss Acked-by: Jerry Ray Reviewed-by: Andrew Lunn Link: https://lore.kernel.org/r/1716932066-3342-1-git-send-email-Tristram.Ha@microchip.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit c0b37b1cca2d62ea2d1398ba6943b229477cbe4e Author: Alexander Mikhalitsyn Date: Tue May 28 22:30:30 2024 +0200 ipv4: correctly iterate over the target netns in inet_dump_ifaddr() [ Upstream commit b8c8abefc07b47f0dc9342530b7618237df96724 ] A recent change to inet_dump_ifaddr had the function incorrectly iterate over net rather than tgt_net, resulting in the data coming for the incorrect network namespace. Fixes: cdb2f80f1c10 ("inet: use xa_array iterator to implement inet_dump_ifaddr()") Reported-by: Stéphane Graber Closes: https://github.com/lxc/incus/issues/892 Bisected-by: Stéphane Graber Signed-off-by: Alexander Mikhalitsyn Tested-by: Stéphane Graber Acked-by: Christian Brauner Reviewed-by: Eric Dumazet Link: https://lore.kernel.org/r/20240528203030.10839-1-aleksandr.mikhalitsyn@canonical.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit b8af8e6118a6605f0e495a58d591ca94a85a50fc Author: Eric Dumazet Date: Tue May 28 11:43:53 2024 +0000 net: fix __dst_negative_advice() race [ Upstream commit 92f1655aa2b2294d0b49925f3b875a634bd3b59e ] __dst_negative_advice() does not enforce proper RCU rules when sk->dst_cache must be cleared, leading to possible UAF. RCU rules are that we must first clear sk->sk_dst_cache, then call dst_release(old_dst). Note that sk_dst_reset(sk) is implementing this protocol correctly, while __dst_negative_advice() uses the wrong order. Given that ip6_negative_advice() has special logic against RTF_CACHE, this means each of the three ->negative_advice() existing methods must perform the sk_dst_reset() themselves. Note the check against NULL dst is centralized in __dst_negative_advice(), there is no need to duplicate it in various callbacks. Many thanks to Clement Lecigne for tracking this issue. This old bug became visible after the blamed commit, using UDP sockets. Fixes: a87cb3e48ee8 ("net: Facility to report route quality of connected sockets") Reported-by: Clement Lecigne Diagnosed-by: Clement Lecigne Signed-off-by: Eric Dumazet Cc: Tom Herbert Reviewed-by: David Ahern Link: https://lore.kernel.org/r/20240528114353.1794151-1-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit a97788b86d9d1531a0bee8b64b0c983889cbc899 Author: Eric Dumazet Date: Mon Apr 29 13:30:09 2024 +0000 inet: introduce dst_rtable() helper [ Upstream commit 05d6d492097c55f2d153fc3fd33cbe78e1e28e0a ] I added dst_rt6_info() in commit e8dfd42c17fa ("ipv6: introduce dst_rt6_info() helper") This patch does a similar change for IPv4. Instead of (struct rtable *)dst casts, we can use : #define dst_rtable(_ptr) \ container_of_const(_ptr, struct rtable, dst) Patch is smaller than IPv6 one, because IPv4 has skb_rtable() helper. Signed-off-by: Eric Dumazet Reviewed-by: David Ahern Reviewed-by: Sabrina Dubroca Link: https://lore.kernel.org/r/20240429133009.1227754-1-edumazet@google.com Signed-off-by: Jakub Kicinski Stable-dep-of: 92f1655aa2b2 ("net: fix __dst_negative_advice() race") Signed-off-by: Sasha Levin commit 30c83ed52fee13fd64bca8b08763fe98f3bea8a7 Author: Eric Dumazet Date: Fri Apr 26 15:19:52 2024 +0000 ipv6: introduce dst_rt6_info() helper [ Upstream commit e8dfd42c17faf183415323db1ef0c977be0d6489 ] Instead of (struct rt6_info *)dst casts, we can use : #define dst_rt6_info(_ptr) \ container_of_const(_ptr, struct rt6_info, dst) Some places needed missing const qualifiers : ip6_confirm_neigh(), ipv6_anycast_destination(), ipv6_unicast_destination(), has_gateway() v2: added missing parts (David Ahern) Signed-off-by: Eric Dumazet Reviewed-by: David Ahern Signed-off-by: David S. Miller Stable-dep-of: 92f1655aa2b2 ("net: fix __dst_negative_advice() race") Signed-off-by: Sasha Levin commit 869f31cfb1341f178d2e27b3ed5172d773729d5d Author: Alex Deucher Date: Wed May 15 11:25:49 2024 -0400 drm/amdgpu: Adjust logic in amdgpu_device_partner_bandwidth() [ Upstream commit ba46b3bda296c4f82b061ac40b90f49d2a00a380 ] Use current speed/width on devices which don't support dynamic PCIe switching. Fixes: 466a7d115326 ("drm/amd: Use the first non-dGPU PCI device for BW limits") Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/3289 Acked-by: Christian König Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 74be1f4aad99396d966cdd63ffe2c0b756e66f57 Author: Uwe Kleine-König Date: Tue May 21 12:52:42 2024 +0200 spi: stm32: Don't warn about spurious interrupts [ Upstream commit 95d7c452a26564ef0c427f2806761b857106d8c4 ] The dev_warn to notify about a spurious interrupt was introduced with the reasoning that these are unexpected. However spurious interrupts tend to trigger continously and the error message on the serial console prevents that the core's detection of spurious interrupts kicks in (which disables the irq) and just floods the console. Fixes: c64e7efe46b7 ("spi: stm32: make spurious and overrun interrupts visible") Signed-off-by: Uwe Kleine-König Link: https://msgid.link/r/20240521105241.62400-2-u.kleine-koenig@pengutronix.de Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit bb253a1d65acd631eb384cbe4c6db64c9c28f6c9 Author: Miguel Ojeda Date: Tue May 28 18:31:50 2024 +0200 kheaders: use `command -v` to test for existence of `cpio` [ Upstream commit 6e58e0173507e506a5627741358bc770f220e356 ] Commit 13e1df09284d ("kheaders: explicitly validate existence of cpio command") added an explicit check for `cpio` using `type`. However, `type` in `dash` (which is used in some popular distributions and base images as the shell script runner) prints the missing message to standard output, and thus no error is printed: $ bash -c 'type missing >/dev/null' bash: line 1: type: missing: not found $ dash -c 'type missing >/dev/null' $ For instance, this issue may be seen by loongarch builders, given its defconfig enables CONFIG_IKHEADERS since commit 9cc1df421f00 ("LoongArch: Update Loongson-3 default config file"). Therefore, use `command -v` instead to have consistent behavior, and take the chance to provide a more explicit error. Fixes: 13e1df09284d ("kheaders: explicitly validate existence of cpio command") Signed-off-by: Miguel Ojeda Signed-off-by: Masahiro Yamada Signed-off-by: Sasha Levin commit e9250578ac6278dfd24a57c326eb805b3bdb0e31 Author: Andi Shyti Date: Fri May 17 11:06:16 2024 +0200 drm/i915/gt: Fix CCS id's calculation for CCS mode setting [ Upstream commit ee01b6a386eaf9984b58a2476e8f531149679da9 ] The whole point of the previous fixes has been to change the CCS hardware configuration to generate only one stream available to the compute users. We did this by changing the info.engine_mask that is set during device probe, reset during the detection of the fused engines, and finally reset again when choosing the CCS mode. We can't use the engine_mask variable anymore, as with the current configuration, it imposes only one CCS no matter what the hardware configuration is. Before changing the engine_mask for the third time, save it and use it for calculating the CCS mode. After the previous changes, the user reported a performance drop to around 1/4. We have tested that the compute operations, with the current patch, have improved by the same factor. Fixes: 6db31251bb26 ("drm/i915/gt: Enable only one CCS for compute workload") Signed-off-by: Andi Shyti Cc: Chris Wilson Cc: Gnattu OC Cc: Joonas Lahtinen Cc: Matt Roper Tested-by: Jian Ye Reviewed-by: Umesh Nerlige Ramappa Tested-by: Gnattu OC Link: https://patchwork.freedesktop.org/patch/msgid/20240517090616.242529-1-andi.shyti@linux.intel.com (cherry picked from commit a09d2327a9ba8e3f5be238bc1b7ca2809255b464) Signed-off-by: Jani Nikula Signed-off-by: Sasha Levin commit 00a43f84101a37a8f220a09daafc1c6216b9b348 Author: Arnd Bergmann Date: Tue Apr 30 09:48:09 2024 -0700 drm/i915/guc: avoid FIELD_PREP warning [ Upstream commit d4f36db62396b73bed383c0b6e48d36278cafa78 ] With gcc-7 and earlier, there are lots of warnings like In file included from :0:0: In function '__guc_context_policy_add_priority.isra.66', inlined from '__guc_context_set_prio.isra.67' at drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c:3292:3, inlined from 'guc_context_set_prio' at drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c:3320:2: include/linux/compiler_types.h:399:38: error: call to '__compiletime_assert_631' declared with attribute error: FIELD_PREP: mask is not constant _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__) ^ ... drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c:2422:3: note: in expansion of macro 'FIELD_PREP' FIELD_PREP(GUC_KLV_0_KEY, GUC_CONTEXT_POLICIES_KLV_ID_##id) | \ ^~~~~~~~~~ Make sure that GUC_KLV_0_KEY is an unsigned value to avoid the warning. Fixes: 77b6f79df66e ("drm/i915/guc: Update to GuC version 69.0.3") Signed-off-by: Arnd Bergmann Reviewed-by: Michal Wajdeczko Signed-off-by: Julia Filipchuk Signed-off-by: John Harrison Link: https://patchwork.freedesktop.org/patch/msgid/20240430164809.482131-1-julia.filipchuk@intel.com (cherry picked from commit 364e039827ef628c650c21c1afe1c54d9c3296d9) Signed-off-by: Jani Nikula Signed-off-by: Sasha Levin commit c3438b829f46f9af4c9ed16f13a1eb075eb25f7f Author: Masahiro Yamada Date: Sun May 19 18:22:27 2024 +0900 kconfig: fix comparison to constant symbols, 'm', 'n' [ Upstream commit aabdc960a283ba78086b0bf66ee74326f49e218e ] Currently, comparisons to 'm' or 'n' result in incorrect output. [Test Code] config MODULES def_bool y modules config A def_tristate m config B def_bool A > n CONFIG_B is unset, while CONFIG_B=y is expected. The reason for the issue is because Kconfig compares the tristate values as strings. Currently, the .type fields in the constant symbol definitions, symbol_{yes,mod,no} are unspecified, i.e., S_UNKNOWN. When expr_calc_value() evaluates 'A > n', it checks the types of 'A' and 'n' to determine how to compare them. The left-hand side, 'A', is a tristate symbol with a value of 'm', which corresponds to a numeric value of 1. (Internally, 'y', 'm', and 'n' are represented as 2, 1, and 0, respectively.) The right-hand side, 'n', has an unknown type, so it is treated as the string "n" during the comparison. expr_calc_value() compares two values numerically only when both can have numeric values. Otherwise, they are compared as strings. symbol numeric value ASCII code ------------------------------------- y 2 0x79 m 1 0x6d n 0 0x6e 'm' is greater than 'n' if compared numerically (since 1 is greater than 0), but smaller than 'n' if compared as strings (since the ASCII code 0x6d is smaller than 0x6e). Specifying .type=S_TRISTATE for symbol_{yes,mod,no} fixes the above test code. Doing so, however, would cause a regression to the following test code. [Test Code 2] config MODULES def_bool n modules config A def_tristate n config B def_bool A = m You would get CONFIG_B=y, while CONFIG_B should not be set. The reason is because sym_get_string_value() turns 'm' into 'n' when the module feature is disabled. Consequently, expr_calc_value() evaluates 'A = n' instead of 'A = m'. This oddity has been hidden because the type of 'm' was previously S_UNKNOWN instead of S_TRISTATE. sym_get_string_value() should not tweak the string because the tristate value has already been correctly calculated. There is no reason to return the string "n" where its tristate value is mod. Fixes: 31847b67bec0 ("kconfig: allow use of relations other than (in)equality") Signed-off-by: Masahiro Yamada Signed-off-by: Sasha Levin commit 91f249b01fe490fce11fbb4307952ca8cce78724 Author: Vladimir Oltean Date: Mon May 27 18:39:55 2024 +0300 net/sched: taprio: extend minimum interval restriction to entire cycle too [ Upstream commit fb66df20a7201e60f2b13d7f95d031b31a8831d3 ] It is possible for syzbot to side-step the restriction imposed by the blamed commit in the Fixes: tag, because the taprio UAPI permits a cycle-time different from (and potentially shorter than) the sum of entry intervals. We need one more restriction, which is that the cycle time itself must be larger than N * ETH_ZLEN bit times, where N is the number of schedule entries. This restriction needs to apply regardless of whether the cycle time came from the user or was the implicit, auto-calculated value, so we move the existing "cycle == 0" check outside the "if "(!new->cycle_time)" branch. This way covers both conditions and scenarios. Add a selftest which illustrates the issue triggered by syzbot. Fixes: b5b73b26b3ca ("taprio: Fix allowing too small intervals") Reported-by: syzbot+a7d2b1d5d1af83035567@syzkaller.appspotmail.com Closes: https://lore.kernel.org/netdev/0000000000007d66bc06196e7c66@google.com/ Signed-off-by: Vladimir Oltean Link: https://lore.kernel.org/r/20240527153955.553333-2-vladimir.oltean@nxp.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 6239e4cd1fde091d6f0502a4af3ba5153c8a1086 Author: Vladimir Oltean Date: Mon May 27 18:39:54 2024 +0300 net/sched: taprio: make q->picos_per_byte available to fill_sched_entry() [ Upstream commit e634134180885574d1fe7aa162777ba41e7fcd5b ] In commit b5b73b26b3ca ("taprio: Fix allowing too small intervals"), a comparison of user input against length_to_duration(q, ETH_ZLEN) was introduced, to avoid RCU stalls due to frequent hrtimers. The implementation of length_to_duration() depends on q->picos_per_byte being set for the link speed. The blamed commit in the Fixes: tag has moved this too late, so the checks introduced above are ineffective. The q->picos_per_byte is zero at parse_taprio_schedule() -> parse_sched_list() -> parse_sched_entry() -> fill_sched_entry() time. Move the taprio_set_picos_per_byte() call as one of the first things in taprio_change(), before the bulk of the netlink attribute parsing is done. That's because it is needed there. Add a selftest to make sure the issue doesn't get reintroduced. Fixes: 09dbdf28f9f9 ("net/sched: taprio: fix calculation of maximum gate durations") Signed-off-by: Vladimir Oltean Reviewed-by: Eric Dumazet Link: https://lore.kernel.org/r/20240527153955.553333-1-vladimir.oltean@nxp.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit c115b10e4f952f38b29d3c03d57354a7fbe9aa86 Author: Eric Garver Date: Tue May 21 10:25:05 2024 -0400 netfilter: nft_fib: allow from forward/input without iif selector [ Upstream commit e8ded22ef0f4831279c363c264cd41cd9d59ca9e ] This removes the restriction of needing iif selector in the forward/input hooks for fib lookups when requested result is oif/oifname. Removing this restriction allows "loose" lookups from the forward hooks. Fixes: be8be04e5ddb ("netfilter: nft_fib: reverse path filter for policy-based routing on iif") Signed-off-by: Eric Garver Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 819bfeca16eb9ad647ddcae25e7e12c30612147c Author: Florian Westphal Date: Mon May 13 12:27:15 2024 +0200 netfilter: tproxy: bail out if IP has been disabled on the device [ Upstream commit 21a673bddc8fd4873c370caf9ae70ffc6d47e8d3 ] syzbot reports: general protection fault, probably for non-canonical address 0xdffffc0000000003: 0000 [#1] PREEMPT SMP KASAN PTI KASAN: null-ptr-deref in range [0x0000000000000018-0x000000000000001f] [..] RIP: 0010:nf_tproxy_laddr4+0xb7/0x340 net/ipv4/netfilter/nf_tproxy_ipv4.c:62 Call Trace: nft_tproxy_eval_v4 net/netfilter/nft_tproxy.c:56 [inline] nft_tproxy_eval+0xa9a/0x1a00 net/netfilter/nft_tproxy.c:168 __in_dev_get_rcu() can return NULL, so check for this. Reported-and-tested-by: syzbot+b94a6818504ea90d7661@syzkaller.appspotmail.com Fixes: cc6eb4338569 ("tproxy: use the interface primary IP address as a default value for --on-ip") Signed-off-by: Florian Westphal Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 06fa4c04e844e4d662c7d8a787b420b3da281d42 Author: Pablo Neira Ayuso Date: Wed May 8 22:50:34 2024 +0200 netfilter: nft_payload: skbuff vlan metadata mangle support [ Upstream commit 33c563ebf8d3deed7d8addd20d77398ac737ef9a ] Userspace assumes vlan header is present at a given offset, but vlan offload allows to store this in metadata fields of the skbuff. Hence mangling vlan results in a garbled packet. Handle this transparently by adding a parser to the kernel. If vlan metadata is present and payload offset is over 12 bytes (source and destination mac address fields), then subtract vlan header present in vlan metadata, otherwise mangle vlan metadata based on offset and length, extracting data from the source register. This is similar to: 8cfd23e67401 ("netfilter: nft_payload: work around vlan header stripping") to deal with vlan payload mangling. Fixes: 7ec3f7b47b8d ("netfilter: nft_payload: add packet mangling support") Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit bb581ef3971f6c2602fc0ce04137887d657e9569 Author: MD Danish Anwar Date: Mon May 27 12:00:15 2024 +0530 net: ti: icssg-prueth: Fix start counter for ft1 filter [ Upstream commit 56a5cf538c3f2d935b0d81040a8303b6e7fc5fd8 ] The start counter for FT1 filter is wrongly set to 0 in the driver. FT1 is used for source address violation (SAV) check and source address starts at Byte 6 not Byte 0. Fix this by changing start counter to ETH_ALEN in icssg_ft1_set_mac_addr(). Fixes: e9b4ece7d74b ("net: ti: icssg-prueth: Add Firmware config and classification APIs.") Signed-off-by: MD Danish Anwar Link: https://lore.kernel.org/r/20240527063015.263748-1-danishanwar@ti.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit ff3deb79cc1902fb4e100703fb85a1db784af9ad Author: Christoph Hellwig Date: Thu May 23 20:26:14 2024 +0200 block: stack max_user_sectors [ Upstream commit e528bede6f4e6822afdf0fa80be46ea9199f0911 ] The max_user_sectors is one of the three factors determining the actual max_sectors limit for READ/WRITE requests. Because of that it needs to be stacked at least for the device mapper multi-path case where requests are directly inserted on the lower device. For SCSI disks this is important because the sd driver actually sets it's own advisory limit that is lower than max_hw_sectors based on the block limits VPD page. While this is a bit odd an unusual, the same effect can happen if a user or udev script tweaks the value manually. Fixes: 4f563a64732d ("block: add a max_user_discard_sectors queue limit") Reported-by: Mike Snitzer Signed-off-by: Christoph Hellwig Acked-by: Mike Snitzer Reviewed-by: Martin K. Petersen Link: https://lore.kernel.org/r/20240523182618.602003-3-hch@lst.de Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 149fb01c479eb6346133572c609c1b1f3dbe8f76 Author: Christoph Hellwig Date: Thu May 23 20:26:13 2024 +0200 sd: also set max_user_sectors when setting max_sectors [ Upstream commit bafea1c58b24be594d97841ced1b7ae0347bf6e3 ] sd can set a max_sectors value that is lower than the max_hw_sectors limit based on the block limits VPD page. While this is rather unusual, it used to work until the max_user_sectors field was split out to cleanly deal with conflicting hardware and user limits when the hardware limit changes. Also set max_user_sectors to ensure the limit can properly be stacked. Fixes: 4f563a64732d ("block: add a max_user_discard_sectors queue limit") Reported-by: Mike Snitzer Signed-off-by: Christoph Hellwig Acked-by: Mike Snitzer Reviewed-by: Martin K. Petersen Link: https://lore.kernel.org/r/20240523182618.602003-2-hch@lst.de Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 11173662473e31fd2a4ae1e0a0de0de8ed8d01ec Author: Takashi Iwai Date: Mon May 27 17:18:50 2024 +0200 ALSA: seq: Don't clear bank selection at event -> UMP MIDI2 conversion [ Upstream commit a200df7deb3186cd7b55abb77ab96dfefb8a4f09 ] The current code to convert from a legacy sequencer event to UMP MIDI2 clears the bank selection at each time the program change is submitted. This is confusing and may lead to incorrect bank values tranmitted to the destination in the end. Drop the line to clear the bank info and keep the provided values. Fixes: e9e02819a98a ("ALSA: seq: Automatic conversion of UMP events") Link: https://lore.kernel.org/r/20240527151852.29036-2-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit e400db196fb78c5b049ff94c8dd4f37d6fb83aa0 Author: Takashi Iwai Date: Mon May 27 17:18:49 2024 +0200 ALSA: seq: Fix missing bank setup between MIDI1/MIDI2 UMP conversion [ Upstream commit 8a42886cae307663f3f999846926bd6e64392000 ] When a UMP packet is converted between MIDI1 and MIDI2 protocols, the bank selection may be lost. The conversion from MIDI1 to MIDI2 needs the encoding of the bank into UMP_MSG_STATUS_PROGRAM bits, while the conversion from MIDI2 to MIDI1 needs the extraction from that instead. This patch implements the missing bank selection mechanism in those conversions. Fixes: e9e02819a98a ("ALSA: seq: Automatic conversion of UMP events") Link: https://lore.kernel.org/r/20240527151852.29036-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 92deed4a9bfd9ef187764225bba530116c49e15c Author: Matthew Brost Date: Mon Apr 15 12:04:53 2024 -0700 drm/xe: Only use reserved BCS instances for usm migrate exec queue [ Upstream commit c8ea2c31f5ea437199b239d76ad5db27343edb0c ] The GuC context scheduling queue is 2 entires deep, thus it is possible for a migration job to be stuck behind a fault if migration exec queue shares engines with user jobs. This can deadlock as the migrate exec queue is required to service page faults. Avoid deadlock by only using reserved BCS instances for usm migrate exec queue. Fixes: a043fbab7af5 ("drm/xe/pvc: Use fast copy engines as migrate engine on PVC") Cc: Matt Roper Cc: Niranjana Vishwanathapura Signed-off-by: Matthew Brost Link: https://patchwork.freedesktop.org/patch/msgid/20240415190453.696553-2-matthew.brost@intel.com Reviewed-by: Brian Welty (cherry picked from commit 04f4a70a183a688a60fe3882d6e4236ea02cfc67) Signed-off-by: Thomas Hellström Signed-off-by: Sasha Levin commit 2803bc08b0f1933f4c41b922c919290865654b3e Author: Himal Prasad Ghimiray Date: Wed May 8 20:52:15 2024 +0530 drm/xe: Change pcode timeout to 50msec while polling again [ Upstream commit 77b79df0268bee3ef38fd5e76e86a076ce02995d ] Polling is initially attempted with timeout_base_ms enabled for preemption, and if it exceeds this timeframe, another attempt is made without preemption, allowing an additional 50 ms before timing out. v2 - Rebase v3 - Move warnings to separate patch (Lucas) Cc: Lucas De Marchi Cc: Rodrigo Vivi Signed-off-by: Himal Prasad Ghimiray Fixes: 7dc9b92dcfef ("drm/xe: Remove i915_utils dependency from xe_pcode.") Reviewed-by: Lucas De Marchi Link: https://patchwork.freedesktop.org/patch/msgid/20240508152216.3263109-2-himal.prasad.ghimiray@intel.com Signed-off-by: Rodrigo Vivi (cherry picked from commit c81858eb52266b3d6ba28ca4f62a198231a10cdc) Signed-off-by: Thomas Hellström Signed-off-by: Sasha Levin commit 4e85c324b3f21a5205f5dd4d85c2023d7d4f1282 Author: Riana Tauro Date: Wed Apr 10 14:20:04 2024 +0530 drm/xe: check pcode init status only on root gt of root tile [ Upstream commit 933fd5ffaf87a60a019992d48e3a96b5c3403d9f ] The root tile indicates the pcode initialization is complete when all tiles have completed their initialization. So the mailbox can be polled only on the root tile. Check pcode init status only on root tile and move it to device probe early as root tile is initialized there. Also make similar changes in resume paths. v2: add lock/unlocked version of pcode_mailbox_rw to allow pcode init to be called in device early probe (Rodrigo) v3: add code description about using root tile change function names to xe_pcode_probe_early and xe_pcode_init (Rodrigo) Signed-off-by: Riana Tauro Reviewed-by: Rodrigo Vivi Reviewed-by: Himal Prasad Ghimiray Link: https://patchwork.freedesktop.org/patch/msgid/20240410085005.1126343-2-riana.tauro@intel.com Signed-off-by: Rodrigo Vivi Stable-dep-of: 77b79df0268b ("drm/xe: Change pcode timeout to 50msec while polling again") Signed-off-by: Sasha Levin commit 492990552be6df3580c5be178dcbfa4c2204219c Author: Rodrigo Vivi Date: Mon Mar 18 14:01:41 2024 -0400 drm/xe: Add dbg messages on the suspend resume functions. [ Upstream commit f7f24b7950af4b1548ad5075ddb13eeb333bb782 ] In case of the suspend/resume flow getting locked up we can get reports with some useful hints on where it might get locked and if that has failed. Reviewed-by: Matthew Auld Link: https://patchwork.freedesktop.org/patch/msgid/20240318180141.267458-2-rodrigo.vivi@intel.com Signed-off-by: Rodrigo Vivi Stable-dep-of: 77b79df0268b ("drm/xe: Change pcode timeout to 50msec while polling again") Signed-off-by: Sasha Levin commit 5c268d05611b9de3e4b63ab8bf63815f97a39d09 Author: Matthieu Baerts (NGI0) Date: Fri May 24 18:30:59 2024 +0200 selftests: mptcp: join: mark 'fail' tests as flaky [ Upstream commit 38af56e6668b455f7dd0a8e2d9afe74100068e17 ] These tests are rarely unstable. It depends on the CI running the tests, especially if it is also busy doing other tasks in parallel, and if a debug kernel config is being used. It looks like this issue is sometimes present with the NetDev CI. While this is being investigated, the tests are marked as flaky not to create noises on such CIs. Fixes: b6e074e171bc ("selftests: mptcp: add infinite map testcase") Link: https://github.com/multipath-tcp/mptcp_net-next/issues/491 Reviewed-by: Mat Martineau Signed-off-by: Matthieu Baerts (NGI0) Link: https://lore.kernel.org/r/20240524-upstream-net-20240524-selftests-mptcp-flaky-v1-4-a352362f3f8e@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 4468331b1ad30dbf454dead8374a5056ce1eb3f9 Author: Geliang Tang Date: Fri Apr 5 12:52:06 2024 +0200 selftests: mptcp: add ms units for tc-netem delay [ Upstream commit 9109853a388b7b2b934f56f4ddb250d72e486555 ] 'delay 1' in tc-netem is confusing, not sure if it's a delay of 1 second or 1 millisecond. This patch explicitly adds millisecond units to make these commands clearer. Signed-off-by: Geliang Tang Reviewed-by: Matthieu Baerts (NGI0) Signed-off-by: Matthieu Baerts (NGI0) Signed-off-by: David S. Miller Stable-dep-of: 38af56e6668b ("selftests: mptcp: join: mark 'fail' tests as flaky") Signed-off-by: Sasha Levin commit 4393c8c7b250cf1869847ab89a9500cc51e1647a Author: Matthieu Baerts (NGI0) Date: Fri May 24 18:30:58 2024 +0200 selftests: mptcp: join: mark 'fastclose' tests as flaky [ Upstream commit 8c06ac2178a9dee887929232226e35a5cdda1793 ] These tests are flaky since their introduction. This might be less or not visible depending on the CI running the tests, especially if it is also busy doing other tasks in parallel, and if a debug kernel config is being used. It looks like this issue is often present with the NetDev CI. While this is being investigated, the tests are marked as flaky not to create noises on such CIs. Fixes: 01542c9bf9ab ("selftests: mptcp: add fastclose testcase") Link: https://github.com/multipath-tcp/mptcp_net-next/issues/324 Reviewed-by: Mat Martineau Signed-off-by: Matthieu Baerts (NGI0) Link: https://lore.kernel.org/r/20240524-upstream-net-20240524-selftests-mptcp-flaky-v1-3-a352362f3f8e@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit db11517530b13cb1cfdea89eb90af891ea454a76 Author: Matthieu Baerts (NGI0) Date: Fri May 24 18:30:57 2024 +0200 selftests: mptcp: simult flows: mark 'unbalanced' tests as flaky [ Upstream commit cc73a6577ae64247898269d138dee6b73ff710cc ] These tests are flaky since their introduction. This might be less or not visible depending on the CI running the tests, especially if it is also busy doing other tasks in parallel. A first analysis shown that the transfer can be slowed down when there are some re-injections at the MPTCP level. Such re-injections can of course happen, and disturb the transfer, but it looks strange to have them in this lab. That could be caused by the kernel having access to less CPU cycles -- e.g. when other activities are executed in parallel -- or by a misinterpretation on the MPTCP packet scheduler side. While this is being investigated, the tests are marked as flaky not to create noises in other CIs. Fixes: 219d04992b68 ("mptcp: push pending frames when subflow has free space") Link: https://github.com/multipath-tcp/mptcp_net-next/issues/475 Reviewed-by: Mat Martineau Signed-off-by: Matthieu Baerts (NGI0) Link: https://lore.kernel.org/r/20240524-upstream-net-20240524-selftests-mptcp-flaky-v1-2-a352362f3f8e@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 5a1619baa6a56e09b0554377f466201ccaf3655d Author: Jacob Keller Date: Thu May 23 10:45:30 2024 -0700 ice: fix accounting if a VLAN already exists [ Upstream commit 82617b9a04649e83ee8731918aeadbb6e6d7cbc7 ] The ice_vsi_add_vlan() function is used to add a VLAN filter for the target VSI. This function prepares a filter in the switch table for the given VSI. If it succeeds, the vsi->num_vlan counter is incremented. It is not considered an error to add a VLAN which already exists in the switch table, so the function explicitly checks and ignores -EEXIST. The vsi->num_vlan counter is still incremented. This seems incorrect, as it means we can double-count in the case where the same VLAN is added twice by the caller. The actual table will have one less filter than the count. The ice_vsi_del_vlan() function similarly checks and handles the -ENOENT condition for when deleting a filter that doesn't exist. This flow only decrements the vsi->num_vlan if it actually deleted a filter. The vsi->num_vlan counter is used only in a few places, primarily related to tracking the number of non-zero VLANs. If the vsi->num_vlans gets out of sync, then ice_vsi_num_non_zero_vlans() will incorrectly report more VLANs than are present, and ice_vsi_has_non_zero_vlans() could return true potentially in cases where there are only VLAN 0 filters left. Fix this by only incrementing the vsi->num_vlan in the case where we actually added an entry, and not in the case where the entry already existed. Fixes: a1ffafb0b4a4 ("ice: Support configuring the device to Double VLAN Mode") Signed-off-by: Jacob Keller Tested-by: Pucha Himasekhar Reddy Reviewed-by: Simon Horman Link: https://lore.kernel.org/r/20240523-net-2024-05-23-intel-net-fixes-v1-2-17a923e0bb5f@intel.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 0d23ab4b61fb52787a4fc64ede470b95327108dc Author: Alexander Lobakin Date: Thu May 23 10:45:29 2024 -0700 idpf: don't enable NAPI and interrupts prior to allocating Rx buffers [ Upstream commit d514c8b54209de7a95ab37259fe32c7406976bd9 ] Currently, idpf enables NAPI and interrupts prior to allocating Rx buffers. This may lead to frame loss (there are no buffers to place incoming frames) and even crashes on quick ifup-ifdown. Interrupts must be enabled only after all the resources are here and available. Split interrupt init into two phases: initialization and enabling, and perform the second only after the queues are fully initialized. Note that we can't just move interrupt initialization down the init process, as the queues must have correct a ::q_vector pointer set and NAPI already added in order to allocate buffers correctly. Also, during the deinit process, disable HW interrupts first and only then disable NAPI. Otherwise, there can be a HW event leading to napi_schedule(), but the NAPI will already be unavailable. Fixes: d4d558718266 ("idpf: initialize interrupts and enable vport") Reported-by: Michal Kubiak Reviewed-by: Wojciech Drewek Signed-off-by: Alexander Lobakin Reviewed-by: Simon Horman Tested-by: Krishneil Singh Signed-off-by: Jacob Keller Link: https://lore.kernel.org/r/20240523-net-2024-05-23-intel-net-fixes-v1-1-17a923e0bb5f@intel.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 529f340e1197d3a0f5a9d7effde33a158e362370 Author: Horatiu Vultur Date: Fri May 24 10:53:50 2024 +0200 net: micrel: Fix lan8841_config_intr after getting out of sleep mode [ Upstream commit 4fb679040d9f758eeb3b4d01bbde6405bf20e64e ] When the interrupt is enabled, the function lan8841_config_intr tries to clear any pending interrupts by reading the interrupt status, then checks the return value for errors and then continue to enable the interrupt. It has been seen that once the system gets out of sleep mode, the interrupt status has the value 0x400 meaning that the PHY detected that the link was in low power. That is correct value but the problem is that the check is wrong. We try to check for errors but we return an error also in this case which is not an error. Therefore fix this by returning only when there is an error. Fixes: a8f1a19d27ef ("net: micrel: Add support for lan8841 PHY") Signed-off-by: Horatiu Vultur Reviewed-by: Suman Ghosh Reviewed-by: Andrew Lunn Reviewed-by: Russell King (Oracle) Link: https://lore.kernel.org/r/20240524085350.359812-1-horatiu.vultur@microchip.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit aff74215e0feef6eac9a4013a36158b8fb527670 Author: Xiaolei Wang Date: Fri May 24 13:05:28 2024 +0800 net:fec: Add fec_enet_deinit() [ Upstream commit bf0497f53c8535f99b72041529d3f7708a6e2c0d ] When fec_probe() fails or fec_drv_remove() needs to release the fec queue and remove a NAPI context, therefore add a function corresponding to fec_enet_init() and call fec_enet_deinit() which does the opposite to release memory and remove a NAPI context. Fixes: 59d0f7465644 ("net: fec: init multi queue date structure") Signed-off-by: Xiaolei Wang Reviewed-by: Wei Fang Reviewed-by: Andrew Lunn Link: https://lore.kernel.org/r/20240524050528.4115581-1-xiaolei.wang@windriver.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 0e09218399e6ee371cfc55d545c93c620e27f8f9 Author: Ido Schimmel Date: Thu May 23 14:02:57 2024 +0300 ipv4: Fix address dump when IPv4 is disabled on an interface [ Upstream commit 7b05ab85e28f615e70520d24c075249b4512044e ] Cited commit started returning an error when user space requests to dump the interface's IPv4 addresses and IPv4 is disabled on the interface. Restore the previous behavior and do not return an error. Before cited commit: # ip address show dev dummy1 10: dummy1: mtu 1500 qdisc noqueue state UNKNOWN group default qlen 1000 link/ether e2:40:68:98:d0:18 brd ff:ff:ff:ff:ff:ff inet6 fe80::e040:68ff:fe98:d018/64 scope link proto kernel_ll valid_lft forever preferred_lft forever # ip link set dev dummy1 mtu 67 # ip address show dev dummy1 10: dummy1: mtu 67 qdisc noqueue state UNKNOWN group default qlen 1000 link/ether e2:40:68:98:d0:18 brd ff:ff:ff:ff:ff:ff After cited commit: # ip address show dev dummy1 10: dummy1: mtu 1500 qdisc noqueue state UNKNOWN group default qlen 1000 link/ether 32:2d:69:f2:9c:99 brd ff:ff:ff:ff:ff:ff inet6 fe80::302d:69ff:fef2:9c99/64 scope link proto kernel_ll valid_lft forever preferred_lft forever # ip link set dev dummy1 mtu 67 # ip address show dev dummy1 RTNETLINK answers: No such device Dump terminated With this patch: # ip address show dev dummy1 10: dummy1: mtu 1500 qdisc noqueue state UNKNOWN group default qlen 1000 link/ether de:17:56:bb:57:c0 brd ff:ff:ff:ff:ff:ff inet6 fe80::dc17:56ff:febb:57c0/64 scope link proto kernel_ll valid_lft forever preferred_lft forever # ip link set dev dummy1 mtu 67 # ip address show dev dummy1 10: dummy1: mtu 67 qdisc noqueue state UNKNOWN group default qlen 1000 link/ether de:17:56:bb:57:c0 brd ff:ff:ff:ff:ff:ff I fixed the exact same issue for IPv6 in commit c04f7dfe6ec2 ("ipv6: Fix address dump when IPv6 is disabled on an interface"), but noted [1] that I am not doing the change for IPv4 because I am not aware of a way to disable IPv4 on an interface other than unregistering it. I clearly missed the above case. [1] https://lore.kernel.org/netdev/20240321173042.2151756-1-idosch@nvidia.com/ Fixes: cdb2f80f1c10 ("inet: use xa_array iterator to implement inet_dump_ifaddr()") Reported-by: Carolina Jubran Reported-by: Yamen Safadi Tested-by: Carolina Jubran Reviewed-by: Petr Machata Signed-off-by: Ido Schimmel Reviewed-by: Eric Dumazet Reviewed-by: David Ahern Link: https://lore.kernel.org/r/20240523110257.334315-1-idosch@nvidia.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 48ca521e95d2e549cc41446eefe926ddd76369c6 Author: Damien Le Moal Date: Mon May 27 13:34:45 2024 +0900 null_blk: Fix return value of nullb_device_power_store() [ Upstream commit d9ff882b54f99f96787fa3df7cd938966843c418 ] When powering on a null_blk device that is not already on, the return value ret that is initialized to be count is reused to check the return value of null_add_dev(), leading to nullb_device_power_store() to return null_add_dev() return value (0 on success) instead of "count". So make sure to set ret to be equal to count when there are no errors. Fixes: a2db328b0839 ("null_blk: fix null-ptr-dereference while configuring 'power' and 'submit_queues'") Signed-off-by: Damien Le Moal Reviewed-by: Yu Kuai Reviewed-by: Kanchan Joshi Link: https://lore.kernel.org/r/20240527043445.235267-1-dlemoal@kernel.org Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit b81e1c5a3c70398cf76631ede63a03616ed1ba3c Author: Jakub Sitnicki Date: Mon May 27 13:20:07 2024 +0200 bpf: Allow delete from sockmap/sockhash only if update is allowed [ Upstream commit 98e948fb60d41447fd8d2d0c3b8637fc6b6dc26d ] We have seen an influx of syzkaller reports where a BPF program attached to a tracepoint triggers a locking rule violation by performing a map_delete on a sockmap/sockhash. We don't intend to support this artificial use scenario. Extend the existing verifier allowed-program-type check for updating sockmap/sockhash to also cover deleting from a map. From now on only BPF programs which were previously allowed to update sockmap/sockhash can delete from these map types. Fixes: ff9105993240 ("bpf, sockmap: Prevent lock inversion deadlock in map delete elem") Reported-by: Tetsuo Handa Reported-by: syzbot+ec941d6e24f633a59172@syzkaller.appspotmail.com Signed-off-by: Jakub Sitnicki Signed-off-by: Daniel Borkmann Tested-by: syzbot+ec941d6e24f633a59172@syzkaller.appspotmail.com Acked-by: John Fastabend Closes: https://syzkaller.appspot.com/bug?extid=ec941d6e24f633a59172 Link: https://lore.kernel.org/bpf/20240527-sockmap-verify-deletes-v1-1-944b372f2101@cloudflare.com Signed-off-by: Sasha Levin commit 1a947e64925451de1c2395661d8e354ccedee13a Author: Charles Keepax Date: Mon May 27 11:08:40 2024 +0100 ASoC: cs42l43: Only restrict 44.1kHz for the ASP [ Upstream commit 797c525e85d1e44cf0e6f338890e8e0c661f524a ] The SoundWire interface can always support 44.1kHz using flow controlled mode, and whether the ASP is in master mode should obviously only affect the ASP. Update cs42l43_startup() to only restrict the rates for the ASP DAI. Fixes: fc918cbe874e ("ASoC: cs42l43: Add support for the cs42l43") Signed-off-by: Charles Keepax Link: https://msgid.link/r/20240527100840.439832-1-ckeepax@opensource.cirrus.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 243e7ca79412ec6adee32e6c05bf425d92640057 Author: Parthiban Veerasooran Date: Thu May 23 14:23:14 2024 +0530 net: usb: smsc95xx: fix changing LED_SEL bit value updated from EEPROM [ Upstream commit 52a2f0608366a629d43dacd3191039c95fef74ba ] LED Select (LED_SEL) bit in the LED General Purpose IO Configuration register is used to determine the functionality of external LED pins (Speed Indicator, Link and Activity Indicator, Full Duplex Link Indicator). The default value for this bit is 0 when no EEPROM is present. If a EEPROM is present, the default value is the value of the LED Select bit in the Configuration Flags of the EEPROM. A USB Reset or Lite Reset (LRST) will cause this bit to be restored to the image value last loaded from EEPROM, or to be set to 0 if no EEPROM is present. While configuring the dual purpose GPIO/LED pins to LED outputs in the LED General Purpose IO Configuration register, the LED_SEL bit is changed as 0 and resulting the configured value from the EEPROM is cleared. The issue is fixed by using read-modify-write approach. Fixes: f293501c61c5 ("smsc95xx: configure LED outputs") Signed-off-by: Parthiban Veerasooran Reviewed-by: Simon Horman Reviewed-by: Woojung Huh Link: https://lore.kernel.org/r/20240523085314.167650-1-Parthiban.Veerasooran@microchip.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 2b4fa532320ba681ca25e6e1d003854edf6226c2 Author: Hariprasad Kelam Date: Thu May 23 13:06:26 2024 +0530 Octeontx2-pf: Free send queue buffers incase of leaf to inner [ Upstream commit 1684842147677a1279bcff95f8adb6de9a656e30 ] There are two type of classes. "Leaf classes" that are the bottom of the class hierarchy. "Inner classes" that are neither the root class nor leaf classes. QoS rules can only specify leaf classes as targets for traffic. Root / \ / \ 1 2 /\ / \ 4 5 classes 1,4 and 5 are leaf classes. class 2 is a inner class. When a leaf class made as inner, or vice versa, resources associated with send queue (send queue buffers and transmit schedulers) are not getting freed. Fixes: 5e6808b4c68d ("octeontx2-pf: Add support for HTB offload") Signed-off-by: Hariprasad Kelam Link: https://lore.kernel.org/r/20240523073626.4114-1-hkelam@marvell.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit a74c5663341a46f9f151d905da69103cfe9dd4b1 Author: Kuniyuki Iwashima Date: Thu May 23 00:42:18 2024 +0900 af_unix: Read sk->sk_hash under bindlock during bind(). [ Upstream commit 51d1b25a720982324871338b1a36b197ec9bd6f0 ] syzkaller reported data-race of sk->sk_hash in unix_autobind() [0], and the same ones exist in unix_bind_bsd() and unix_bind_abstract(). The three bind() functions prefetch sk->sk_hash locklessly and use it later after validating that unix_sk(sk)->addr is NULL under unix_sk(sk)->bindlock. The prefetched sk->sk_hash is the hash value of unbound socket set in unix_create1() and does not change until bind() completes. There could be a chance that sk->sk_hash changes after the lockless read. However, in such a case, non-NULL unix_sk(sk)->addr is visible under unix_sk(sk)->bindlock, and bind() returns -EINVAL without using the prefetched value. The KCSAN splat is false-positive, but let's silence it by reading sk->sk_hash under unix_sk(sk)->bindlock. [0]: BUG: KCSAN: data-race in unix_autobind / unix_autobind write to 0xffff888034a9fb88 of 4 bytes by task 4468 on cpu 0: __unix_set_addr_hash net/unix/af_unix.c:331 [inline] unix_autobind+0x47a/0x7d0 net/unix/af_unix.c:1185 unix_dgram_connect+0x7e3/0x890 net/unix/af_unix.c:1373 __sys_connect_file+0xd7/0xe0 net/socket.c:2048 __sys_connect+0x114/0x140 net/socket.c:2065 __do_sys_connect net/socket.c:2075 [inline] __se_sys_connect net/socket.c:2072 [inline] __x64_sys_connect+0x40/0x50 net/socket.c:2072 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0x4f/0x110 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x46/0x4e read to 0xffff888034a9fb88 of 4 bytes by task 4465 on cpu 1: unix_autobind+0x28/0x7d0 net/unix/af_unix.c:1134 unix_dgram_connect+0x7e3/0x890 net/unix/af_unix.c:1373 __sys_connect_file+0xd7/0xe0 net/socket.c:2048 __sys_connect+0x114/0x140 net/socket.c:2065 __do_sys_connect net/socket.c:2075 [inline] __se_sys_connect net/socket.c:2072 [inline] __x64_sys_connect+0x40/0x50 net/socket.c:2072 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0x4f/0x110 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x46/0x4e value changed: 0x000000e4 -> 0x000001e3 Reported by Kernel Concurrency Sanitizer on: CPU: 1 PID: 4465 Comm: syz-executor.0 Not tainted 6.8.0-12822-gcd51db110a7e #12 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 Fixes: afd20b9290e1 ("af_unix: Replace the big lock with small locks.") Reported-by: syzkaller Signed-off-by: Kuniyuki Iwashima Link: https://lore.kernel.org/r/20240522154218.78088-1-kuniyu@amazon.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 22cb1ecc8770a1edcf906963f6ad2b586692d88d Author: Kuniyuki Iwashima Date: Thu May 23 00:40:02 2024 +0900 af_unix: Annotate data-race around unix_sk(sk)->addr. [ Upstream commit 97e1db06c7bb948da10ba85acad8030b56886593 ] Once unix_sk(sk)->addr is assigned under net->unx.table.locks and unix_sk(sk)->bindlock, *(unix_sk(sk)->addr) and unix_sk(sk)->path are fully set up, and unix_sk(sk)->addr is never changed. unix_getname() and unix_copy_addr() access the two fields locklessly, and commit ae3b564179bf ("missing barriers in some of unix_sock ->addr and ->path accesses") added smp_store_release() and smp_load_acquire() pairs. In other functions, we still read unix_sk(sk)->addr locklessly to check if the socket is bound, and KCSAN complains about it. [0] Given these functions have no dependency for *(unix_sk(sk)->addr) and unix_sk(sk)->path, READ_ONCE() is enough to annotate the data-race. Note that it is safe to access unix_sk(sk)->addr locklessly if the socket is found in the hash table. For example, the lockless read of otheru->addr in unix_stream_connect() is safe. Note also that newu->addr there is of the child socket that is still not accessible from userspace, and smp_store_release() publishes the address in case the socket is accept()ed and unix_getname() / unix_copy_addr() is called. [0]: BUG: KCSAN: data-race in unix_bind / unix_listen write (marked) to 0xffff88805f8d1840 of 8 bytes by task 13723 on cpu 0: __unix_set_addr_hash net/unix/af_unix.c:329 [inline] unix_bind_bsd net/unix/af_unix.c:1241 [inline] unix_bind+0x881/0x1000 net/unix/af_unix.c:1319 __sys_bind+0x194/0x1e0 net/socket.c:1847 __do_sys_bind net/socket.c:1858 [inline] __se_sys_bind net/socket.c:1856 [inline] __x64_sys_bind+0x40/0x50 net/socket.c:1856 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0x4f/0x110 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x46/0x4e read to 0xffff88805f8d1840 of 8 bytes by task 13724 on cpu 1: unix_listen+0x72/0x180 net/unix/af_unix.c:734 __sys_listen+0xdc/0x160 net/socket.c:1881 __do_sys_listen net/socket.c:1890 [inline] __se_sys_listen net/socket.c:1888 [inline] __x64_sys_listen+0x2e/0x40 net/socket.c:1888 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0x4f/0x110 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x46/0x4e value changed: 0x0000000000000000 -> 0xffff88807b5b1b40 Reported by Kernel Concurrency Sanitizer on: CPU: 1 PID: 13724 Comm: syz-executor.4 Not tainted 6.8.0-12822-gcd51db110a7e #12 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Reported-by: syzkaller Signed-off-by: Kuniyuki Iwashima Link: https://lore.kernel.org/r/20240522154002.77857-1-kuniyu@amazon.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit aee1955a1509a921c05c70dad5d6fc8563dfcb31 Author: Roded Zats Date: Wed May 22 10:30:44 2024 +0300 enic: Validate length of nl attributes in enic_set_vf_port [ Upstream commit e8021b94b0412c37bcc79027c2e382086b6ce449 ] enic_set_vf_port assumes that the nl attribute IFLA_PORT_PROFILE is of length PORT_PROFILE_MAX and that the nl attributes IFLA_PORT_INSTANCE_UUID, IFLA_PORT_HOST_UUID are of length PORT_UUID_MAX. These attributes are validated (in the function do_setlink in rtnetlink.c) using the nla_policy ifla_port_policy. The policy defines IFLA_PORT_PROFILE as NLA_STRING, IFLA_PORT_INSTANCE_UUID as NLA_BINARY and IFLA_PORT_HOST_UUID as NLA_STRING. That means that the length validation using the policy is for the max size of the attributes and not on exact size so the length of these attributes might be less than the sizes that enic_set_vf_port expects. This might cause an out of bands read access in the memcpys of the data of these attributes in enic_set_vf_port. Fixes: f8bd909183ac ("net: Add ndo_{set|get}_vf_port support for enic dynamic vnics") Signed-off-by: Roded Zats Link: https://lore.kernel.org/r/20240522073044.33519-1-rzats@paloaltonetworks.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 9dd7ecab89de40932c2aeaadc55f61e6368815f8 Author: Luke D. Jones Date: Sun May 26 21:10:32 2024 +1200 ALSA: hda/realtek: Adjust G814JZR to use SPI init for amp [ Upstream commit 2be46155d792d629e8fe3188c2cde176833afe36 ] The 2024 ASUS ROG G814J model is much the same as the 2023 model and the 2023 16" version. We can use the same Cirrus Amp quirk. Fixes: 811dd426a9b1 ("ALSA: hda/realtek: Add quirks for Asus ROG 2024 laptops using CS35L41") Signed-off-by: Luke D. Jones Link: https://lore.kernel.org/r/20240526091032.114545-1-luke@ljones.dev Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 7238bbf605cbc8ac26b51787e7e0928fc4a44cff Author: Takashi Iwai Date: Fri May 24 17:11:46 2024 +0200 ALSA: core: Remove debugfs at disconnection [ Upstream commit 495000a38634e640e2fd02f7e4f1512ccc92d770 ] The card-specific debugfs entries are removed at the last stage of card free phase, and it's performed after synchronization of the closes of all opened fds. This works fine for most cases, but it can be potentially problematic for a hotplug device like USB-audio. Due to the nature of snd_card_free_when_closed(), the card free isn't called immediately after the driver removal for a hotplug device, but it's left until the last fd is closed. It implies that the card debugfs entries also remain. Meanwhile, when a new device is inserted before the last close and the very same card slot is assigned, the driver tries to create the card debugfs root again on the very same path. This conflicts with the remaining entry, and results in the kernel warning such as: debugfs: Directory 'card0' with parent 'sound' already present! with the missing debugfs entry afterwards. For avoiding such conflicts, remove debugfs entries at the device disconnection phase instead. The jack kctl debugfs entries get removed in snd_jack_dev_disconnect() instead of each kctl private_free. Fixes: 2d670ea2bd53 ("ALSA: jack: implement software jack injection via debugfs") Link: https://lore.kernel.org/r/20240524151256.32521-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit dc0477ef4dea6f4c11a125f09d688e6dc7679069 Author: Daniel Borkmann Date: Fri May 24 18:36:17 2024 +0200 netkit: Fix pkt_type override upon netkit pass verdict [ Upstream commit 3998d184267dfcff858aaa84d3de17429253629d ] When running Cilium connectivity test suite with netkit in L2 mode, we found that compared to tcx a few tests were failing which pushed traffic into an L7 proxy sitting in host namespace. The problem in particular is around the invocation of eth_type_trans() in netkit. In case of tcx, this is run before the tcx ingress is triggered inside host namespace and thus if the BPF program uses the bpf_skb_change_type() helper the newly set type is retained. However, in case of netkit, the late eth_type_trans() invocation overrides the earlier decision from the BPF program which eventually leads to the test failure. Instead of eth_type_trans(), split out the relevant parts, meaning, reset of mac header and call to eth_skb_pkt_type() before the BPF program is run in order to have the same behavior as with tcx, and refactor a small helper called eth_skb_pull_mac() which is run in case it's passed up the stack where the mac header must be pulled. With this all connectivity tests pass. Fixes: 35dfaad7188c ("netkit, bpf: Add bpf programmable net device") Signed-off-by: Daniel Borkmann Acked-by: Nikolay Aleksandrov Link: https://lore.kernel.org/r/20240524163619.26001-2-daniel@iogearbox.net Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 325deceac2499288291b925281639ace206101ca Author: Daniel Borkmann Date: Fri May 24 18:36:16 2024 +0200 netkit: Fix setting mac address in l2 mode [ Upstream commit d6fe532b7499e4575f9647879b7a34625817fe7f ] When running Cilium connectivity test suite with netkit in L2 mode, we found that it is expected to be able to specify a custom MAC address for the devices, in particular, cilium-cni obtains the specified MAC address by querying the endpoint and sets the MAC address of the interface inside the Pod. Thus, fix the missing support in netkit for L2 mode. Fixes: 35dfaad7188c ("netkit, bpf: Add bpf programmable net device") Signed-off-by: Daniel Borkmann Acked-by: Nikolay Aleksandrov Acked-by: Stanislav Fomichev Link: https://lore.kernel.org/r/20240524163619.26001-1-daniel@iogearbox.net Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 1bdd4ae98bff7b63d035ac0d4384dada177592a6 Author: Friedrich Vock Date: Tue May 14 09:09:31 2024 +0200 bpf: Fix potential integer overflow in resolve_btfids [ Upstream commit 44382b3ed6b2787710c8ade06c0e97f5970a47c8 ] err is a 32-bit integer, but elf_update returns an off_t, which is 64-bit at least on 64-bit platforms. If symbols_patch is called on a binary between 2-4GB in size, the result will be negative when cast to a 32-bit integer, which the code assumes means an error occurred. This can wrongly trigger build failures when building very large kernel images. Fixes: fbbb68de80a4 ("bpf: Add resolve_btfids tool to resolve BTF IDs in ELF object") Signed-off-by: Friedrich Vock Signed-off-by: Daniel Borkmann Acked-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/20240514070931.199694-1-friedrich.vock@gmx.de Signed-off-by: Sasha Levin commit 8a283cdfc8beeb14024387a925247b563d614e1e Author: Tetsuo Handa Date: Sun May 5 23:08:31 2024 +0900 dma-buf/sw-sync: don't enable IRQ from sync_print_obj() [ Upstream commit b794918961516f667b0c745aebdfebbb8a98df39 ] Since commit a6aa8fca4d79 ("dma-buf/sw-sync: Reduce irqsave/irqrestore from known context") by error replaced spin_unlock_irqrestore() with spin_unlock_irq() for both sync_debugfs_show() and sync_print_obj() despite sync_print_obj() is called from sync_debugfs_show(), lockdep complains inconsistent lock state warning. Use plain spin_{lock,unlock}() for sync_print_obj(), for sync_debugfs_show() is already using spin_{lock,unlock}_irq(). Reported-by: syzbot Closes: https://syzkaller.appspot.com/bug?extid=a225ee3df7e7f9372dbe Fixes: a6aa8fca4d79 ("dma-buf/sw-sync: Reduce irqsave/irqrestore from known context") Signed-off-by: Tetsuo Handa Reviewed-by: Christian König Link: https://patchwork.freedesktop.org/patch/msgid/c2e46020-aaa6-4e06-bf73-f05823f913f0@I-love.SAKURA.ne.jp Signed-off-by: Christian König Signed-off-by: Sasha Levin commit e481b93803cc5d56b6ca4e66e9ea6bc10ac5c1e8 Author: Gal Pressman Date: Wed May 22 22:26:59 2024 +0300 net/mlx5e: Fix UDP GSO for encapsulated packets [ Upstream commit 83fea49f2711fc90c0d115b0ed04046b45155b65 ] When the skb is encapsulated, adjust the inner UDP header instead of the outer one, and account for UDP header (instead of TCP) in the inline header size calculation. Fixes: 689adf0d4892 ("net/mlx5e: Add UDP GSO support") Reported-by: Jason Baron Closes: https://lore.kernel.org/netdev/c42961cb-50b9-4a9a-bd43-87fe48d88d29@akamai.com/ Signed-off-by: Gal Pressman Reviewed-by: Dragos Tatulea Reviewed-by: Boris Pismenny Signed-off-by: Tariq Toukan Reviewed-by: Simon Horman Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 634e0e9f821fd23ac088f33840081cc3069f31bf Author: Carolina Jubran Date: Wed May 22 22:26:58 2024 +0300 net/mlx5e: Use rx_missed_errors instead of rx_dropped for reporting buffer exhaustion [ Upstream commit 5c74195d5dd977e97556e6fa76909b831c241230 ] Previously, the driver incorrectly used rx_dropped to report device buffer exhaustion. According to the documentation, rx_dropped should not be used to count packets dropped due to buffer exhaustion, which is the purpose of rx_missed_errors. Use rx_missed_errors as intended for counting packets dropped due to buffer exhaustion. Fixes: 269e6b3af3bf ("net/mlx5e: Report additional error statistics in get stats ndo") Signed-off-by: Carolina Jubran Signed-off-by: Tariq Toukan Reviewed-by: Simon Horman Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 719367cad4d026caec48d7c6687ded30719a04eb Author: Rahul Rameshbabu Date: Wed May 22 22:26:56 2024 +0300 net/mlx5e: Fix IPsec tunnel mode offload feature check [ Upstream commit 9a52f6d44f4521773b4699b4ed34b8e21d5a175c ] Remove faulty check disabling checksum offload and GSO for offload of simple IPsec tunnel L4 traffic. Comment previously describing the deleted code incorrectly claimed the check prevented double tunnel (or three layers of ip headers). Fixes: f1267798c980 ("net/mlx5: Fix checksum issue of VXLAN and IPsec crypto offload") Signed-off-by: Rahul Rameshbabu Signed-off-by: Tariq Toukan Reviewed-by: Simon Horman Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit cc9ac559f2e21894c21ac5b0c85fb24a5cab266c Author: Rahul Rameshbabu Date: Wed May 22 22:26:55 2024 +0300 net/mlx5: Use mlx5_ipsec_rx_status_destroy to correctly delete status rules [ Upstream commit 16d66a4fa81da07bc4ed19f4e53b87263c2f8d38 ] rx_create no longer allocates a modify_hdr instance that needs to be cleaned up. The mlx5_modify_header_dealloc call will lead to a NULL pointer dereference. A leak in the rules also previously occurred since there are now two rules populated related to status. BUG: kernel NULL pointer dereference, address: 0000000000000000 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 109907067 P4D 109907067 PUD 116890067 PMD 0 Oops: 0000 [#1] SMP CPU: 1 PID: 484 Comm: ip Not tainted 6.9.0-rc2-rrameshbabu+ #254 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS Arch Linux 1.16.3-1-1 04/01/2014 RIP: 0010:mlx5_modify_header_dealloc+0xd/0x70 Call Trace: ? show_regs+0x60/0x70 ? __die+0x24/0x70 ? page_fault_oops+0x15f/0x430 ? free_to_partial_list.constprop.0+0x79/0x150 ? do_user_addr_fault+0x2c9/0x5c0 ? exc_page_fault+0x63/0x110 ? asm_exc_page_fault+0x27/0x30 ? mlx5_modify_header_dealloc+0xd/0x70 rx_create+0x374/0x590 rx_add_rule+0x3ad/0x500 ? rx_add_rule+0x3ad/0x500 ? mlx5_cmd_exec+0x2c/0x40 ? mlx5_create_ipsec_obj+0xd6/0x200 mlx5e_accel_ipsec_fs_add_rule+0x31/0xf0 mlx5e_xfrm_add_state+0x426/0xc00 Fixes: 94af50c0a9bb ("net/mlx5e: Unify esw and normal IPsec status table creation/destruction") Signed-off-by: Rahul Rameshbabu Signed-off-by: Tariq Toukan Reviewed-by: Simon Horman Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 0b2aed9f3507513a713a03bb8e10e392c50bea0a Author: Gal Pressman Date: Wed May 22 22:26:54 2024 +0300 net/mlx5: Fix MTMP register capability offset in MCAM register [ Upstream commit 1b9f86c6d53245dab087f1b2c05727b5982142ff ] The MTMP register (0x900a) capability offset is off-by-one, move it to the right place. Fixes: 1f507e80c700 ("net/mlx5: Expose NIC temperature via hardware monitoring kernel API") Signed-off-by: Gal Pressman Reviewed-by: Cosmin Ratiu Signed-off-by: Tariq Toukan Reviewed-by: Simon Horman Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 7d9b1979bcb0e2fdc0f28e668cc57751cea08e6a Author: Tariq Toukan Date: Wed May 22 22:26:53 2024 +0300 net/mlx5: Do not query MPIR on embedded CPU function [ Upstream commit fca3b4791850b7e2181f0b3195b66d53df83151b ] A proper query to MPIR needs to set the correct value in the depth field. On embedded CPU this value is not necessarily zero. As there is no real use case for multi-PF netdev on the embedded CPU of the smart NIC, block this option. This fixes the following failure: ACCESS_REG(0x805) op_mod(0x1) failed, status bad system state(0x4), syndrome (0x685f19), err(-5) Fixes: 678eb448055a ("net/mlx5: SD, Implement basic query and instantiation") Signed-off-by: Tariq Toukan Reviewed-by: Simon Horman Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 76680d1c8b1ebad41a72069e30328eb64c3284d7 Author: Maher Sanalla Date: Wed May 22 22:26:52 2024 +0300 net/mlx5: Lag, do bond only if slaves agree on roce state [ Upstream commit 51ef9305b8f40946d65c40368ffb4c14636d369a ] Currently, the driver does not enforce that lag bond slaves must have matching roce capabilities. Yet, in mlx5_do_bond(), the driver attempts to enable roce on all vports of the bond slaves, causing the following syndrome when one slave has no roce fw support: mlx5_cmd_out_err:809:(pid 25427): MODIFY_NIC_VPORT_CONTEXT(0×755) op_mod(0×0) failed, status bad parameter(0×3), syndrome (0xc1f678), err(-22) Thus, create HW lag only if bond's slaves agree on roce state, either all slaves have roce support resulting in a roce lag bond, or none do, resulting in a raw eth bond. Fixes: 7907f23adc18 ("net/mlx5: Implement RoCE LAG feature") Signed-off-by: Maher Sanalla Signed-off-by: Tariq Toukan Reviewed-by: Simon Horman Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 45d2dbef9e76b76286e86d70717cef77614ed78d Author: Mathieu Othacehe Date: Tue May 21 08:54:06 2024 +0200 net: phy: micrel: set soft_reset callback to genphy_soft_reset for KSZ8061 [ Upstream commit 128d54fbcb14b8717ecf596d3dbded327b9980b3 ] Following a similar reinstate for the KSZ8081 and KSZ9031. Older kernels would use the genphy_soft_reset if the PHY did not implement a .soft_reset. The KSZ8061 errata described here: https://ww1.microchip.com/downloads/en/DeviceDoc/KSZ8061-Errata-DS80000688B.pdf and worked around with 232ba3a51c ("net: phy: Micrel KSZ8061: link failure after cable connect") is back again without this soft reset. Fixes: 6e2d85ec0559 ("net: phy: Stop with excessive soft reset") Tested-by: Karim Ben Houcine Signed-off-by: Mathieu Othacehe Reviewed-by: Andrew Lunn Reviewed-by: Florian Fainelli Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 289a10b47fe5d17a81c9ee69994110d3ccfb5495 Author: Mario Limonciello Date: Wed May 8 16:45:35 2024 -0500 drm/amd/display: Enable colorspace property for MST connectors [ Upstream commit 8195979d2dd995d60c2663adf54c69c1bf4eadd1 ] MST colorspace property support was disabled due to a series of warnings that came up when the device was plugged in since the properties weren't made at device creation. Create the properties in advance instead. Suggested-by: Ville Syrjälä Fixes: 69a959610229 ("drm/amd/display: Temporary Disable MST DP Colorspace Property"). Reported-and-tested-by: Tyler Schneider Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/3353 Reviewed-by: Harry Wentland Signed-off-by: Mario Limonciello Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 9e45e8676d4b44426dbeb021db8988295da3a833 Author: Sagi Grimberg Date: Tue May 21 23:20:28 2024 +0300 nvmet: fix ns enable/disable possible hang [ Upstream commit f97914e35fd98b2b18fb8a092e0a0799f73afdfe ] When disabling an nvmet namespace, there is a period where the subsys->lock is released, as the ns disable waits for backend IO to complete, and the ns percpu ref to be properly killed. The original intent was to avoid taking the subsystem lock for a prolong period as other processes may need to acquire it (for example new incoming connections). However, it opens up a window where another process may come in and enable the ns, (re)intiailizing the ns percpu_ref, causing the disable sequence to hang. Solve this by taking the global nvmet_config_sem over the entire configfs enable/disable sequence. Fixes: a07b4970f464 ("nvmet: add a generic NVMe target") Signed-off-by: Sagi Grimberg Reviewed-by: Christoph Hellwig Reviewed-by: Chaitanya Kulkarni Signed-off-by: Keith Busch Signed-off-by: Sasha Levin commit 99d4f68a1d0b0922e2da8bb843aa4cb58f956ce7 Author: Keith Busch Date: Tue May 21 11:02:28 2024 -0700 nvme-multipath: fix io accounting on failover [ Upstream commit a2e4c5f5f68dbd206f132bc709b98dea64afc3b8 ] There are io stats accounting that needs to be handled, so don't call blk_mq_end_request() directly. Use the existing nvme_end_req() helper that already handles everything. Fixes: d4d957b53d91ee ("nvme-multipath: support io stats on the mpath device") Reviewed-by: Christoph Hellwig Reviewed-by: Sagi Grimberg Signed-off-by: Keith Busch Signed-off-by: Sasha Levin commit 2488cd662411d955db684bff0f9c4bd8a15c516b Author: Keith Busch Date: Tue May 21 09:50:47 2024 -0700 nvme: fix multipath batched completion accounting [ Upstream commit 2fe7b422460d14b33027d8770f7be8d26bcb2639 ] Batched completions were missing the io stats accounting and bio trace events. Move the common code to a helper and call it from the batched and non-batched functions. Fixes: d4d957b53d91ee ("nvme-multipath: support io stats on the mpath device") Reviewed-by: Christoph Hellwig Reviewed-by: Sagi Grimberg Reviewed-by: Chaitanya Kulkarni Reviewed-by: Hannes Reinecke Signed-off-by: Keith Busch Signed-off-by: Sasha Levin commit 50ee21bfc005e69f183d6b4b454e33f0c2571e1f Author: Fedor Pchelkin Date: Sat May 4 14:47:04 2024 +0300 dma-mapping: benchmark: handle NUMA_NO_NODE correctly [ Upstream commit e64746e74f717961250a155e14c156616fcd981f ] cpumask_of_node() can be called for NUMA_NO_NODE inside do_map_benchmark() resulting in the following sanitizer report: UBSAN: array-index-out-of-bounds in ./arch/x86/include/asm/topology.h:72:28 index -1 is out of range for type 'cpumask [64][1]' CPU: 1 PID: 990 Comm: dma_map_benchma Not tainted 6.9.0-rc6 #29 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) Call Trace: dump_stack_lvl (lib/dump_stack.c:117) ubsan_epilogue (lib/ubsan.c:232) __ubsan_handle_out_of_bounds (lib/ubsan.c:429) cpumask_of_node (arch/x86/include/asm/topology.h:72) [inline] do_map_benchmark (kernel/dma/map_benchmark.c:104) map_benchmark_ioctl (kernel/dma/map_benchmark.c:246) full_proxy_unlocked_ioctl (fs/debugfs/file.c:333) __x64_sys_ioctl (fs/ioctl.c:890) do_syscall_64 (arch/x86/entry/common.c:83) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) Use cpumask_of_node() in place when binding a kernel thread to a cpuset of a particular node. Note that the provided node id is checked inside map_benchmark_ioctl(). It's just a NUMA_NO_NODE case which is not handled properly later. Found by Linux Verification Center (linuxtesting.org). Fixes: 65789daa8087 ("dma-mapping: add benchmark support for streaming DMA APIs") Signed-off-by: Fedor Pchelkin Acked-by: Barry Song Signed-off-by: Christoph Hellwig Signed-off-by: Sasha Levin commit 63e7e05a48a35308aeddd7ecccb68363a5988e87 Author: Fedor Pchelkin Date: Sat May 4 14:47:03 2024 +0300 dma-mapping: benchmark: fix node id validation [ Upstream commit 1ff05e723f7ca30644b8ec3fb093f16312e408ad ] While validating node ids in map_benchmark_ioctl(), node_possible() may be provided with invalid argument outside of [0,MAX_NUMNODES-1] range leading to: BUG: KASAN: wild-memory-access in map_benchmark_ioctl (kernel/dma/map_benchmark.c:214) Read of size 8 at addr 1fffffff8ccb6398 by task dma_map_benchma/971 CPU: 7 PID: 971 Comm: dma_map_benchma Not tainted 6.9.0-rc6 #37 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) Call Trace: dump_stack_lvl (lib/dump_stack.c:117) kasan_report (mm/kasan/report.c:603) kasan_check_range (mm/kasan/generic.c:189) variable_test_bit (arch/x86/include/asm/bitops.h:227) [inline] arch_test_bit (arch/x86/include/asm/bitops.h:239) [inline] _test_bit at (include/asm-generic/bitops/instrumented-non-atomic.h:142) [inline] node_state (include/linux/nodemask.h:423) [inline] map_benchmark_ioctl (kernel/dma/map_benchmark.c:214) full_proxy_unlocked_ioctl (fs/debugfs/file.c:333) __x64_sys_ioctl (fs/ioctl.c:890) do_syscall_64 (arch/x86/entry/common.c:83) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) Compare node ids with sane bounds first. NUMA_NO_NODE is considered a special valid case meaning that benchmarking kthreads won't be bound to a cpuset of a given node. Found by Linux Verification Center (linuxtesting.org). Fixes: 65789daa8087 ("dma-mapping: add benchmark support for streaming DMA APIs") Signed-off-by: Fedor Pchelkin Reviewed-by: Robin Murphy Signed-off-by: Christoph Hellwig Signed-off-by: Sasha Levin commit 54a66f249c86dd1cdba9cd22c9c1ceb43e04f9cd Author: Fedor Pchelkin Date: Sat May 4 14:47:01 2024 +0300 dma-mapping: benchmark: fix up kthread-related error handling [ Upstream commit bb9025f4432f8c158322cf2c04c2b492f23eb511 ] kthread creation failure is invalidly handled inside do_map_benchmark(). The put_task_struct() calls on the error path are supposed to balance the get_task_struct() calls which only happen after all the kthreads are successfully created. Rollback using kthread_stop() for already created kthreads in case of such failure. In normal situation call kthread_stop_put() to gracefully stop kthreads and put their task refcounts. This should be done for all started kthreads. Found by Linux Verification Center (linuxtesting.org). Fixes: 65789daa8087 ("dma-mapping: add benchmark support for streaming DMA APIs") Suggested-by: Robin Murphy Signed-off-by: Fedor Pchelkin Reviewed-by: Robin Murphy Signed-off-by: Christoph Hellwig Signed-off-by: Sasha Levin commit 4cbe4df46b7ebc43a6d40cc38b2d04e80a10aaa3 Author: Uwe Kleine-König Date: Thu May 23 12:33:25 2024 +0200 spi: stm32: Revert change that enabled controller before asserting CS [ Upstream commit a827ad9b3c2fc243e058595533f91ce41a312527 ] On stm32mp157 enabling the controller before asserting CS makes the hardware trigger spurious interrupts in a tight loop and the transfers fail. Revert the commit that swapped the order of enable and CS. This reintroduces the problem that swapping was supposed to fix, which however is less grave. Reported-by: Leonard Göhrs Link: https://lore.kernel.org/all/39033ed7-3e57-4339-80b4-fc8919e26aa7@pengutronix.de/ Fixes: 52b62e7a5d4f ("spi: stm32: enable controller before asserting CS") Signed-off-by: Uwe Kleine-König Link: https://msgid.link/r/20240523103326.792907-2-u.kleine-koenig@pengutronix.de Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 4ab9b2180605b0f1a196824320922b2e02bfc5fb Author: Andy Shevchenko Date: Wed May 22 20:09:49 2024 +0300 spi: Don't mark message DMA mapped when no transfer in it is [ Upstream commit 9f788ba457b45b0ce422943fcec9fa35c4587764 ] There is no need to set the DMA mapped flag of the message if it has no mapped transfers. Moreover, it may give the code a chance to take the wrong paths, i.e. to exercise DMA related APIs on unmapped data. Make __spi_map_msg() to bail earlier on the above mentioned cases. Fixes: 99adef310f68 ("spi: Provide core support for DMA mapping transfers") Signed-off-by: Andy Shevchenko Link: https://msgid.link/r/20240522171018.3362521-2-andriy.shevchenko@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 56a7b74dd37275251c9c61060a4fa65d71cf00f8 Author: Pablo Neira Ayuso Date: Thu May 9 23:02:24 2024 +0200 netfilter: nft_payload: restore vlan q-in-q match support [ Upstream commit aff5c01fa1284d606f8e7cbdaafeef2511bb46c1 ] Revert f6ae9f120dad ("netfilter: nft_payload: add C-VLAN support"). f41f72d09ee1 ("netfilter: nft_payload: simplify vlan header handling") already allows to match on inner vlan tags by subtract the vlan header size to the payload offset which has been popped and stored in skbuff metadata fields. Fixes: f6ae9f120dad ("netfilter: nft_payload: add C-VLAN support") Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 6f313a33cbee3e4c1a466ed6070182756f26f875 Author: Alexander Maltsev Date: Wed Apr 17 18:51:41 2024 +0500 netfilter: ipset: Add list flush to cancel_gc [ Upstream commit c1193d9bbbd379defe9be3c6de566de684de8a6f ] Flushing list in cancel_gc drops references to other lists right away, without waiting for RCU to destroy list. Fixes race when referenced ipsets can't be destroyed while referring list is scheduled for destroy. Fixes: 97f7cf1cd80e ("netfilter: ipset: fix performance regression in swap operation") Signed-off-by: Alexander Maltsev Acked-by: Jozsef Kadlecsik Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 215df6490e208bfdd5b3012f5075e7f8736f3e7a Author: Eric Dumazet Date: Wed May 15 13:23:39 2024 +0000 netfilter: nfnetlink_queue: acquire rcu_read_lock() in instance_destroy_rcu() [ Upstream commit dc21c6cc3d6986d938efbf95de62473982c98dec ] syzbot reported that nf_reinject() could be called without rcu_read_lock() : WARNING: suspicious RCU usage 6.9.0-rc7-syzkaller-02060-g5c1672705a1a #0 Not tainted net/netfilter/nfnetlink_queue.c:263 suspicious rcu_dereference_check() usage! other info that might help us debug this: rcu_scheduler_active = 2, debug_locks = 1 2 locks held by syz-executor.4/13427: #0: ffffffff8e334f60 (rcu_callback){....}-{0:0}, at: rcu_lock_acquire include/linux/rcupdate.h:329 [inline] #0: ffffffff8e334f60 (rcu_callback){....}-{0:0}, at: rcu_do_batch kernel/rcu/tree.c:2190 [inline] #0: ffffffff8e334f60 (rcu_callback){....}-{0:0}, at: rcu_core+0xa86/0x1830 kernel/rcu/tree.c:2471 #1: ffff88801ca92958 (&inst->lock){+.-.}-{2:2}, at: spin_lock_bh include/linux/spinlock.h:356 [inline] #1: ffff88801ca92958 (&inst->lock){+.-.}-{2:2}, at: nfqnl_flush net/netfilter/nfnetlink_queue.c:405 [inline] #1: ffff88801ca92958 (&inst->lock){+.-.}-{2:2}, at: instance_destroy_rcu+0x30/0x220 net/netfilter/nfnetlink_queue.c:172 stack backtrace: CPU: 0 PID: 13427 Comm: syz-executor.4 Not tainted 6.9.0-rc7-syzkaller-02060-g5c1672705a1a #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/02/2024 Call Trace: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:114 lockdep_rcu_suspicious+0x221/0x340 kernel/locking/lockdep.c:6712 nf_reinject net/netfilter/nfnetlink_queue.c:323 [inline] nfqnl_reinject+0x6ec/0x1120 net/netfilter/nfnetlink_queue.c:397 nfqnl_flush net/netfilter/nfnetlink_queue.c:410 [inline] instance_destroy_rcu+0x1ae/0x220 net/netfilter/nfnetlink_queue.c:172 rcu_do_batch kernel/rcu/tree.c:2196 [inline] rcu_core+0xafd/0x1830 kernel/rcu/tree.c:2471 handle_softirqs+0x2d6/0x990 kernel/softirq.c:554 __do_softirq kernel/softirq.c:588 [inline] invoke_softirq kernel/softirq.c:428 [inline] __irq_exit_rcu+0xf4/0x1c0 kernel/softirq.c:637 irq_exit_rcu+0x9/0x30 kernel/softirq.c:649 instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1043 [inline] sysvec_apic_timer_interrupt+0xa6/0xc0 arch/x86/kernel/apic/apic.c:1043 Fixes: 9872bec773c2 ("[NETFILTER]: nfnetlink: use RCU for queue instances hash") Reported-by: syzbot Signed-off-by: Eric Dumazet Acked-by: Florian Westphal Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 79c722e06b1884439ab6efd6502bd9a2f414df3f Author: Matthieu Baerts (NGI0) Date: Wed Jun 5 11:21:18 2024 +0200 selftests: net: lib: set 'i' as local commit 84a8bc3ec225b28067b168e9410e452c83d706da upstream. Without this, the 'i' variable declared before could be overridden by accident, e.g. for i in "${@}"; do __ksft_status_merge "${i}" ## 'i' has been modified foo "${i}" ## using 'i' with an unexpected value done After a quick look, it looks like 'i' is currently not used after having been modified in __ksft_status_merge(), but still, better be safe than sorry. I saw this while modifying the same file, not because I suspected an issue somewhere. Fixes: 596c8819cb78 ("selftests: forwarding: Have RET track kselftest framework constants") Acked-by: Geliang Tang Signed-off-by: Matthieu Baerts (NGI0) Reviewed-by: Hangbin Liu Link: https://lore.kernel.org/r/20240605-upstream-net-20240605-selftests-net-lib-fixes-v1-3-b3afadd368c9@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 0a1cb0c6102bb4fd310243588d39461da49497ad Author: Chuck Lever Date: Sun Jun 2 18:15:25 2024 -0400 SUNRPC: Fix loop termination condition in gss_free_in_token_pages() commit 4a77c3dead97339478c7422eb07bf4bf63577008 upstream. The in_token->pages[] array is not NULL terminated. This results in the following KASAN splat: KASAN: maybe wild-memory-access in range [0x04a2013400000008-0x04a201340000000f] Fixes: bafa6b4d95d9 ("SUNRPC: Fix gss_free_in_token_pages()") Reviewed-by: Benjamin Coddington Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit de13c56f99477b56980c7e00b09c776d16b7563d Author: Matthew R. Ochs Date: Wed May 22 15:06:40 2024 +0300 tpm_tis_spi: Account for SPI header when allocating TPM SPI xfer buffer [ Upstream commit 195aba96b854dd664768f382cd1db375d8181f88 ] The TPM SPI transfer mechanism uses MAX_SPI_FRAMESIZE for computing the maximum transfer length and the size of the transfer buffer. As such, it does not account for the 4 bytes of header that prepends the SPI data frame. This can result in out-of-bounds accesses and was confirmed with KASAN. Introduce SPI_HDRSIZE to account for the header and use to allocate the transfer buffer. Fixes: a86a42ac2bd6 ("tpm_tis_spi: Add hardware wait polling") Signed-off-by: Matthew R. Ochs Tested-by: Carol Soto Reviewed-by: Jarkko Sakkinen Signed-off-by: Jarkko Sakkinen Signed-off-by: Sasha Levin commit 4ed468edfeb54c7202e559eba74c25fac6a0dad0 Author: Carlos López Date: Mon May 27 11:43:52 2024 +0200 tracing/probes: fix error check in parse_btf_field() [ Upstream commit e569eb34970281438e2b48a3ef11c87459fcfbcb ] btf_find_struct_member() might return NULL or an error via the ERR_PTR() macro. However, its caller in parse_btf_field() only checks for the NULL condition. Fix this by using IS_ERR() and returning the error up the stack. Link: https://lore.kernel.org/all/20240527094351.15687-1-clopez@suse.de/ Fixes: c440adfbe3025 ("tracing/probes: Support BTF based data structure field access") Signed-off-by: Carlos López Signed-off-by: Masami Hiramatsu (Google) Signed-off-by: Sasha Levin commit c8f7c80bb84e95565d293a04b14a409341442bdc Author: David Howells Date: Fri May 24 15:23:36 2024 +0100 cifs: Fix missing set of remote_i_size [ Upstream commit 93a43155127fec0f8cc942d63b76668c2f8f69fa ] Occasionally, the generic/001 xfstest will fail indicating corruption in one of the copy chains when run on cifs against a server that supports FSCTL_DUPLICATE_EXTENTS_TO_FILE (eg. Samba with a share on btrfs). The problem is that the remote_i_size value isn't updated by cifs_setsize() when called by smb2_duplicate_extents(), but i_size *is*. This may cause cifs_remap_file_range() to then skip the bit after calling ->duplicate_extents() that sets sizes. Fix this by calling netfs_resize_file() in smb2_duplicate_extents() before calling cifs_setsize() to set i_size. This means we don't then need to call netfs_resize_file() upon return from ->duplicate_extents(), but we also fix the test to compare against the pre-dup inode size. [Note that this goes back before the addition of remote_i_size with the netfs_inode struct. It should probably have been setting cifsi->server_eof previously.] Fixes: cfc63fc8126a ("smb3: fix cached file size problems in duplicate extents (reflink)") Signed-off-by: David Howells cc: Steve French cc: Paulo Alcantara cc: Shyam Prasad N cc: Rohith Surabattula cc: Jeff Layton cc: linux-cifs@vger.kernel.org cc: netfs@lists.linux.dev Signed-off-by: Steve French Signed-off-by: Sasha Levin commit 05505ae716057993d1407d4a80a1fe8118255423 Author: David Howells Date: Tue Nov 28 16:26:44 2023 +0000 cifs: Set zero_point in the copy_file_range() and remap_file_range() [ Upstream commit 3758c485f6c9124d8ad76b88382004cbc28a0892 ] Set zero_point in the copy_file_range() and remap_file_range() implementations so that we don't skip reading data modified on a server-side copy. Signed-off-by: David Howells cc: Steve French cc: Shyam Prasad N cc: Rohith Surabattula cc: Jeff Layton cc: linux-cifs@vger.kernel.org cc: netfs@lists.linux.dev cc: linux-fsdevel@vger.kernel.org cc: linux-mm@kvack.org Stable-dep-of: 93a43155127f ("cifs: Fix missing set of remote_i_size") Signed-off-by: Sasha Levin commit 3f0438db1fe9a32652d3271edab58cb04564e7ab Author: Andrey Konovalov Date: Fri May 17 15:01:18 2024 +0200 kasan, fortify: properly rename memintrinsics [ Upstream commit 2e577732e8d28b9183df701fb90cb7943aa4ed16 ] After commit 69d4c0d32186 ("entry, kasan, x86: Disallow overriding mem*() functions") and the follow-up fixes, with CONFIG_FORTIFY_SOURCE enabled, even though the compiler instruments meminstrinsics by generating calls to __asan/__hwasan_ prefixed functions, FORTIFY_SOURCE still uses uninstrumented memset/memmove/memcpy as the underlying functions. As a result, KASAN cannot detect bad accesses in memset/memmove/memcpy. This also makes KASAN tests corrupt kernel memory and cause crashes. To fix this, use __asan_/__hwasan_memset/memmove/memcpy as the underlying functions whenever appropriate. Do this only for the instrumented code (as indicated by __SANITIZE_ADDRESS__). Link: https://lkml.kernel.org/r/20240517130118.759301-1-andrey.konovalov@linux.dev Fixes: 69d4c0d32186 ("entry, kasan, x86: Disallow overriding mem*() functions") Fixes: 51287dcb00cc ("kasan: emit different calls for instrumentable memintrinsics") Fixes: 36be5cba99f6 ("kasan: treat meminstrinsic as builtins in uninstrumented files") Signed-off-by: Andrey Konovalov Reported-by: Erhard Furtner Reported-by: Nico Pache Closes: https://lore.kernel.org/all/20240501144156.17e65021@outsider.home/ Reviewed-by: Marco Elver Tested-by: Nico Pache Acked-by: Nico Pache Cc: Alexander Potapenko Cc: Andrey Ryabinin Cc: Daniel Axtens Cc: Dmitry Vyukov Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit f7ca7b7b335a71517768ef86a67de871b888d3af Author: David Howells Date: Tue May 21 16:49:46 2024 +0100 netfs: Fix setting of BDP_ASYNC from iocb flags [ Upstream commit c596bea1452ddf172ec9b588e4597228e9a1f4d5 ] Fix netfs_perform_write() to set BDP_ASYNC if IOCB_NOWAIT is set rather than if IOCB_SYNC is not set. It reflects asynchronicity in the sense of not waiting rather than synchronicity in the sense of not returning until the op is complete. Without this, generic/590 fails on cifs in strict caching mode with a complaint that one of the writes fails with EAGAIN. The test can be distilled down to: mount -t cifs /my/share /mnt -ostuff xfs_io -i -c 'falloc 0 8191M -c fsync -f /mnt/file xfs_io -i -c 'pwrite -b 1M -W 0 8191M' /mnt/file Fixes: c38f4e96e605 ("netfs: Provide func to copy data to pagecache for buffered write") Signed-off-by: David Howells Link: https://lore.kernel.org/r/316306.1716306586@warthog.procyon.org.uk Reviewed-by: Jens Axboe cc: Jeff Layton cc: Enzo Matsumiya cc: Jens Axboe cc: Matthew Wilcox cc: netfs@lists.linux.dev cc: v9fs@lists.linux.dev cc: linux-afs@lists.infradead.org cc: linux-cifs@vger.kernel.org cc: linux-fsdevel@vger.kernel.org Signed-off-by: Christian Brauner Signed-off-by: Sasha Levin commit 5d0495473ee4c1d041b5a917f10446a22c047f47 Author: Yu Kuai Date: Thu May 23 23:39:34 2024 +0800 null_blk: fix null-ptr-dereference while configuring 'power' and 'submit_queues' [ Upstream commit a2db328b0839312c169eb42746ec46fc1ab53ed2 ] Writing 'power' and 'submit_queues' concurrently will trigger kernel panic: Test script: modprobe null_blk nr_devices=0 mkdir -p /sys/kernel/config/nullb/nullb0 while true; do echo 1 > submit_queues; echo 4 > submit_queues; done & while true; do echo 1 > power; echo 0 > power; done Test result: BUG: kernel NULL pointer dereference, address: 0000000000000148 Oops: 0000 [#1] PREEMPT SMP RIP: 0010:__lock_acquire+0x41d/0x28f0 Call Trace: lock_acquire+0x121/0x450 down_write+0x5f/0x1d0 simple_recursive_removal+0x12f/0x5c0 blk_mq_debugfs_unregister_hctxs+0x7c/0x100 blk_mq_update_nr_hw_queues+0x4a3/0x720 nullb_update_nr_hw_queues+0x71/0xf0 [null_blk] nullb_device_submit_queues_store+0x79/0xf0 [null_blk] configfs_write_iter+0x119/0x1e0 vfs_write+0x326/0x730 ksys_write+0x74/0x150 This is because del_gendisk() can concurrent with blk_mq_update_nr_hw_queues(): nullb_device_power_store nullb_apply_submit_queues null_del_dev del_gendisk nullb_update_nr_hw_queues if (!dev->nullb) // still set while gendisk is deleted return 0 blk_mq_update_nr_hw_queues dev->nullb = NULL Fix this problem by resuing the global mutex to protect nullb_device_power_store() and nullb_update_nr_hw_queues() from configfs. Fixes: 45919fbfe1c4 ("null_blk: Enable modifying 'submit_queues' after an instance has been configured") Reported-and-tested-by: Yi Zhang Closes: https://lore.kernel.org/all/CAHj4cs9LgsHLnjg8z06LQ3Pr5cax-+Ps+xT7AP7TPnEjStuwZA@mail.gmail.com/ Signed-off-by: Yu Kuai Reviewed-by: Zhu Yanjun Link: https://lore.kernel.org/r/20240523153934.1937851-1-yukuai1@huaweicloud.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit ed1e7dcc051d2e19895ef22e62b462861805f399 Author: Larysa Zaremba Date: Tue May 21 12:39:54 2024 -0700 idpf: Interpret .set_channels() input differently [ Upstream commit 5e7695e0219bf6acb96081af3ba0ca08b1829656 ] Unlike ice, idpf does not check, if user has requested at least 1 combined channel. Instead, it relies on a check in the core code. Unfortunately, the check does not trigger for us because of the hacky .set_channels() interpretation logic that is not consistent with the core code. This naturally leads to user being able to trigger a crash with an invalid input. This is how: 1. ethtool -l -> combined: 40 2. ethtool -L rx 0 tx 0 combined number is not specified, so command becomes {rx_count = 0, tx_count = 0, combined_count = 40}. 3. ethnl_set_channels checks, if there is at least 1 RX and 1 TX channel, comparing (combined_count + rx_count) and (combined_count + tx_count) to zero. Obviously, (40 + 0) is greater than zero, so the core code deems the input OK. 4. idpf interprets `rx 0 tx 0` as 0 channels and tries to proceed with such configuration. The issue has to be solved fundamentally, as current logic is also known to cause AF_XDP problems in ice [0]. Interpret the command in a way that is more consistent with ethtool manual [1] (--show-channels and --set-channels) and new ice logic. Considering that in the idpf driver only the difference between RX and TX queues forms dedicated channels, change the correct way to set number of channels to: ethtool -L combined 10 /* For symmetric queues */ ethtool -L combined 8 tx 2 rx 0 /* For asymmetric queues */ [0] https://lore.kernel.org/netdev/20240418095857.2827-1-larysa.zaremba@intel.com/ [1] https://man7.org/linux/man-pages/man8/ethtool.8.html Fixes: 02cbfba1add5 ("idpf: add ethtool callbacks") Reviewed-by: Przemek Kitszel Reviewed-by: Igor Bagnucki Signed-off-by: Larysa Zaremba Tested-by: Krishneil Singh Reviewed-by: Simon Horman Signed-off-by: Jacob Keller Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit f6e031ab22f910ee99d51da5d3ff436b9c96e46a Author: Larysa Zaremba Date: Tue May 21 12:39:53 2024 -0700 ice: Interpret .set_channels() input differently [ Upstream commit 05d6f442f31f901d27dbc64fd504a8ec7d5013de ] A bug occurs because a safety check guarding AF_XDP-related queues in ethnl_set_channels(), does not trigger. This happens, because kernel and ice driver interpret the ethtool command differently. How the bug occurs: 1. ethtool -l -> combined: 40 2. Attach AF_XDP to queue 30 3. ethtool -L rx 15 tx 15 combined number is not specified, so command becomes {rx_count = 15, tx_count = 15, combined_count = 40}. 4. ethnl_set_channels checks, if there are any AF_XDP of queues from the new (combined_count + rx_count) to the old one, so from 55 to 40, check does not trigger. 5. ice interprets `rx 15 tx 15` as 15 combined channels and deletes the queue that AF_XDP is attached to. Interpret the command in a way that is more consistent with ethtool manual [0] (--show-channels and --set-channels). Considering that in the ice driver only the difference between RX and TX queues forms dedicated channels, change the correct way to set number of channels to: ethtool -L combined 10 /* For symmetric queues */ ethtool -L combined 8 tx 2 rx 0 /* For asymmetric queues */ [0] https://man7.org/linux/man-pages/man8/ethtool.8.html Fixes: 87324e747fde ("ice: Implement ethtool ops for channels") Reviewed-by: Michal Swiatkowski Signed-off-by: Larysa Zaremba Tested-by: Chandan Kumar Rout Tested-by: Pucha Himasekhar Reddy Acked-by: Maciej Fijalkowski Signed-off-by: Jacob Keller Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 6829fda2c7a692aaad4a04b87b705401863ab8a5 Author: Henry Wang Date: Fri May 17 09:15:16 2024 +0800 drivers/xen: Improve the late XenStore init protocol [ Upstream commit a3607581cd49c17128a486a526a36a97bafcb2bb ] Currently, the late XenStore init protocol is only triggered properly for the case that HVM_PARAM_STORE_PFN is ~0ULL (invalid). For the case that XenStore interface is allocated but not ready (the connection status is not XENSTORE_CONNECTED), Linux should also wait until the XenStore is set up properly. Introduce a macro to describe the XenStore interface is ready, use it in xenbus_probe_initcall() to select the code path of doing the late XenStore init protocol or not. Since now we have more than one condition for XenStore late init, rework the check in xenbus_probe() for the free_irq(). Take the opportunity to enhance the check of the allocated XenStore interface can be properly mapped, and return error early if the memremap() fails. Fixes: 5b3353949e89 ("xen: add support for initializing xenstore later as HVM domain") Signed-off-by: Henry Wang Signed-off-by: Michal Orzel Reviewed-by: Stefano Stabellini Link: https://lore.kernel.org/r/20240517011516.1451087-1-xin.wang2@amd.com Signed-off-by: Juergen Gross Signed-off-by: Sasha Levin commit 60c93dc45325f5208fc64553f1f484a97a803248 Author: Ryosuke Yasuoka Date: Wed May 22 00:34:42 2024 +0900 nfc: nci: Fix handling of zero-length payload packets in nci_rx_work() [ Upstream commit 6671e352497ca4bb07a96c48e03907065ff77d8a ] When nci_rx_work() receives a zero-length payload packet, it should not discard the packet and exit the loop. Instead, it should continue processing subsequent packets. Fixes: d24b03535e5e ("nfc: nci: Fix uninit-value in nci_dev_up and nci_ntf_packet") Signed-off-by: Ryosuke Yasuoka Reviewed-by: Simon Horman Reviewed-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/20240521153444.535399-1-ryasuoka@redhat.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 5f9a04a94fd1894d7009055ab8e5832a0242dba3 Author: Paolo Abeni Date: Tue May 21 16:01:00 2024 +0200 net: relax socket state check at accept time. [ Upstream commit 26afda78cda3da974fd4c287962c169e9462c495 ] Christoph reported the following splat: WARNING: CPU: 1 PID: 772 at net/ipv4/af_inet.c:761 __inet_accept+0x1f4/0x4a0 Modules linked in: CPU: 1 PID: 772 Comm: syz-executor510 Not tainted 6.9.0-rc7-g7da7119fe22b #56 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-2.el7 04/01/2014 RIP: 0010:__inet_accept+0x1f4/0x4a0 net/ipv4/af_inet.c:759 Code: 04 38 84 c0 0f 85 87 00 00 00 41 c7 04 24 03 00 00 00 48 83 c4 10 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc e8 ec b7 da fd <0f> 0b e9 7f fe ff ff e8 e0 b7 da fd 0f 0b e9 fe fe ff ff 89 d9 80 RSP: 0018:ffffc90000c2fc58 EFLAGS: 00010293 RAX: ffffffff836bdd14 RBX: 0000000000000000 RCX: ffff888104668000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: dffffc0000000000 R08: ffffffff836bdb89 R09: fffff52000185f64 R10: dffffc0000000000 R11: fffff52000185f64 R12: dffffc0000000000 R13: 1ffff92000185f98 R14: ffff88810754d880 R15: ffff8881007b7800 FS: 000000001c772880(0000) GS:ffff88811b280000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fb9fcf2e178 CR3: 00000001045d2002 CR4: 0000000000770ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: inet_accept+0x138/0x1d0 net/ipv4/af_inet.c:786 do_accept+0x435/0x620 net/socket.c:1929 __sys_accept4_file net/socket.c:1969 [inline] __sys_accept4+0x9b/0x110 net/socket.c:1999 __do_sys_accept net/socket.c:2016 [inline] __se_sys_accept net/socket.c:2013 [inline] __x64_sys_accept+0x7d/0x90 net/socket.c:2013 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0x58/0x100 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x4315f9 Code: fd ff 48 81 c4 80 00 00 00 e9 f1 fe ff ff 0f 1f 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 ab b4 fd ff c3 66 2e 0f 1f 84 00 00 00 00 RSP: 002b:00007ffdb26d9c78 EFLAGS: 00000246 ORIG_RAX: 000000000000002b RAX: ffffffffffffffda RBX: 0000000000400300 RCX: 00000000004315f9 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000004 RBP: 00000000006e1018 R08: 0000000000400300 R09: 0000000000400300 R10: 0000000000400300 R11: 0000000000000246 R12: 0000000000000000 R13: 000000000040cdf0 R14: 000000000040ce80 R15: 0000000000000055 The reproducer invokes shutdown() before entering the listener status. After commit 94062790aedb ("tcp: defer shutdown(SEND_SHUTDOWN) for TCP_SYN_RECV sockets"), the above causes the child to reach the accept syscall in FIN_WAIT1 status. Eric noted we can relax the existing assertion in __inet_accept() Reported-by: Christoph Paasch Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/490 Suggested-by: Eric Dumazet Fixes: 94062790aedb ("tcp: defer shutdown(SEND_SHUTDOWN) for TCP_SYN_RECV sockets") Reviewed-by: Eric Dumazet Link: https://lore.kernel.org/r/23ab880a44d8cfd967e84de8b93dbf48848e3d8c.1716299669.git.pabeni@redhat.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit ef21007a7b581c7fe64d5a10c320880a033c837b Author: Dae R. Jeong Date: Tue May 21 19:34:38 2024 +0900 tls: fix missing memory barrier in tls_init [ Upstream commit 91e61dd7a0af660408e87372d8330ceb218be302 ] In tls_init(), a write memory barrier is missing, and store-store reordering may cause NULL dereference in tls_{setsockopt,getsockopt}. CPU0 CPU1 ----- ----- // In tls_init() // In tls_ctx_create() ctx = kzalloc() ctx->sk_proto = READ_ONCE(sk->sk_prot) -(1) // In update_sk_prot() WRITE_ONCE(sk->sk_prot, tls_prots) -(2) // In sock_common_setsockopt() READ_ONCE(sk->sk_prot)->setsockopt() // In tls_{setsockopt,getsockopt}() ctx->sk_proto->setsockopt() -(3) In the above scenario, when (1) and (2) are reordered, (3) can observe the NULL value of ctx->sk_proto, causing NULL dereference. To fix it, we rely on rcu_assign_pointer() which implies the release barrier semantic. By moving rcu_assign_pointer() after ctx->sk_proto is initialized, we can ensure that ctx->sk_proto are visible when changing sk->sk_prot. Fixes: d5bee7374b68 ("net/tls: Annotate access to sk_prot with READ_ONCE/WRITE_ONCE") Signed-off-by: Yewon Choi Signed-off-by: Dae R. Jeong Link: https://lore.kernel.org/netdev/ZU4OJG56g2V9z_H7@dragonet/T/ Link: https://lore.kernel.org/r/Zkx4vjSFp0mfpjQ2@libra05 Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 3c8ea975f4921c26b19fefebe02b7b63b66c1913 Author: Wei Fang Date: Tue May 21 10:38:00 2024 +0800 net: fec: avoid lock evasion when reading pps_enable [ Upstream commit 3b1c92f8e5371700fada307cc8fd2c51fa7bc8c1 ] The assignment of pps_enable is protected by tmreg_lock, but the read operation of pps_enable is not. So the Coverity tool reports a lock evasion warning which may cause data race to occur when running in a multithread environment. Although this issue is almost impossible to occur, we'd better fix it, at least it seems more logically reasonable, and it also prevents Coverity from continuing to issue warnings. Fixes: 278d24047891 ("net: fec: ptp: Enable PPS output based on ptp clock") Signed-off-by: Wei Fang Link: https://lore.kernel.org/r/20240521023800.17102-1-wei.fang@nxp.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 05785e818a9a9cdb290788406fc3a6ef92c6ab63 Author: Jacob Keller Date: Mon May 20 17:21:27 2024 -0700 Revert "ixgbe: Manual AN-37 for troublesome link partners for X550 SFI" [ Upstream commit b35b1c0b4e166a427395deaf61e3140495dfcb89 ] This reverts commit 565736048bd5f9888990569993c6b6bfdf6dcb6d. According to the commit, it implements a manual AN-37 for some "troublesome" Juniper MX5 switches. This appears to be a workaround for a particular switch. It has been reported that this causes a severe breakage for other switches, including a Cisco 3560CX-12PD-S. The code appears to be a workaround for a specific switch which fails to link in SFI mode. It expects to see AN-37 auto negotiation in order to link. The Cisco switch is not expecting AN-37 auto negotiation. When the device starts the manual AN-37, the Cisco switch decides that the port is confused and stops attempting to link with it. This persists until a power cycle. A simple driver unload and reload does not resolve the issue, even if loading with a version of the driver which lacks this workaround. The authors of the workaround commit have not responded with clarifications, and the result of the workaround is complete failure to connect with other switches. This appears to be a case where the driver can either "correctly" link with the Juniper MX5 switch, at the cost of bricking the link with the Cisco switch, or it can behave properly for the Cisco switch, but fail to link with the Junipir MX5 switch. I do not know enough about the standards involved to clearly determine whether either switch is at fault or behaving incorrectly. Nor do I know whether there exists some alternative fix which corrects behavior with both switches. Revert the workaround for the Juniper switch. Fixes: 565736048bd5 ("ixgbe: Manual AN-37 for troublesome link partners for X550 SFI") Link: https://lore.kernel.org/netdev/cbe874db-9ac9-42b8-afa0-88ea910e1e99@intel.com/T/ Link: https://forum.proxmox.com/threads/intel-x553-sfp-ixgbe-no-go-on-pve8.135129/#post-612291 Signed-off-by: Jacob Keller Cc: Jeff Daly Cc: kernel.org-fo5k2w@ycharbi.fr Reviewed-by: Simon Horman Link: https://lore.kernel.org/r/20240520-net-2024-05-20-revert-silicom-switch-workaround-v1-1-50f80f261c94@intel.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 287d520fc534e5e03968575baa5837ee01a2710a Author: Charlie Jenkins Date: Thu Apr 25 12:58:03 2024 -0700 riscv: selftests: Add hwprobe binaries to .gitignore [ Upstream commit f8ea6ab92748e69216b44b07ea7213cb02070dba ] The cbo and which-cpu hwprobe selftests leave their artifacts in the kernel tree and end up being tracked by git. Add the binaries to the hwprobe selftest .gitignore so this no longer happens. Signed-off-by: Charlie Jenkins Fixes: a29e2a48afe3 ("RISC-V: selftests: Add CBO tests") Fixes: ef7d6abb2cf5 ("RISC-V: selftests: Add which-cpus hwprobe test") Reviewed-by: Muhammad Usama Anjum Reviewed-by: Andrew Jones Link: https://lore.kernel.org/r/20240425-gitignore_hwprobe_artifacts-v1-1-dfc5a20da469@rivosinc.com Signed-off-by: Palmer Dabbelt Signed-off-by: Sasha Levin commit 795065ce081aff175fe5e4eede327f8d49264629 Author: Matthew Bystrin Date: Tue May 21 22:13:13 2024 +0300 riscv: stacktrace: fixed walk_stackframe() [ Upstream commit a2a4d4a6a0bf5eba66f8b0b32502cc20d82715a0 ] If the load access fault occures in a leaf function (with CONFIG_FRAME_POINTER=y), when wrong stack trace will be displayed: [] regmap_mmio_read32le+0xe/0x1c ---[ end trace 0000000000000000 ]--- Registers dump: ra 0xffffffff80485758 sp 0xffffffc80200b9a0 fp 0xffffffc80200b9b0 pc 0xffffffff804853ba Stack dump: 0xffffffc80200b9a0: 0xffffffc80200b9e0 0xffffffc80200b9e0 0xffffffc80200b9b0: 0xffffffff8116d7e8 0x0000000000000100 0xffffffc80200b9c0: 0xffffffd8055b9400 0xffffffd8055b9400 0xffffffc80200b9d0: 0xffffffc80200b9f0 0xffffffff8047c526 0xffffffc80200b9e0: 0xffffffc80200ba30 0xffffffff8047fe9a The assembler dump of the function preambula: add sp,sp,-16 sd s0,8(sp) add s0,sp,16 In the fist stack frame, where ra is not stored on the stack we can observe: 0(sp) 8(sp) .---------------------------------------------. sp->| frame->fp | frame->ra (saved fp) | |---------------------------------------------| fp->| .... | .... | |---------------------------------------------| | | | and in the code check is performed: if (regs && (regs->epc == pc) && (frame->fp & 0x7)) I see no reason to check frame->fp value at all, because it is can be uninitialized value on the stack. A better way is to check frame->ra to be an address on the stack. After the stacktrace shows as expect: [] regmap_mmio_read32le+0xe/0x1c [] regmap_mmio_read+0x24/0x52 [] _regmap_bus_reg_read+0x1a/0x22 [] _regmap_read+0x5c/0xea [] _regmap_update_bits+0x76/0xc0 ... ---[ end trace 0000000000000000 ]--- As pointed by Samuel Holland it is incorrect to remove check of the stackframe entirely. Changes since v2 [2]: - Add accidentally forgotten curly brace Changes since v1 [1]: - Instead of just dropping frame->fp check, replace it with validation of frame->ra, which should be a stack address. - Move frame pointer validation into the separate function. [1] https://lore.kernel.org/linux-riscv/20240426072701.6463-1-dev.mbstr@gmail.com/ [2] https://lore.kernel.org/linux-riscv/20240521131314.48895-1-dev.mbstr@gmail.com/ Fixes: f766f77a74f5 ("riscv/stacktrace: Fix stack output without ra on the stack top") Signed-off-by: Matthew Bystrin Reviewed-by: Samuel Holland Link: https://lore.kernel.org/r/20240521191727.62012-1-dev.mbstr@gmail.com Signed-off-by: Palmer Dabbelt Signed-off-by: Sasha Levin commit f8fce43e08fe14d35f94c1372db2845e57eeecd6 Author: Frank Li Date: Mon May 6 12:40:08 2024 -0400 i3c: master: svc: change ENXIO to EAGAIN when IBI occurs during start frame [ Upstream commit 7f3d633b460be5553a65a247def5426d16805e72 ] svc_i3c_master_xfer() returns error ENXIO if an In-Band Interrupt (IBI) occurs when the host starts the frame. Change error code to EAGAIN to inform the client driver that this situation has occurred and to try again sometime later. Fixes: 5e5e3c92e748 ("i3c: master: svc: fix wrong data return when IBI happen during start frame") Signed-off-by: Frank Li Reviewed-by: Miquel Raynal Link: https://lore.kernel.org/r/20240506164009.21375-2-Frank.Li@nxp.com Signed-off-by: Alexandre Belloni Signed-off-by: Sasha Levin commit 83e00e3be3258c724d016bc3f46827ffbd216588 Author: Charlie Jenkins Date: Thu May 2 21:50:51 2024 -0700 riscv: cpufeature: Fix extension subset checking [ Upstream commit e67e98ee8952c7d5ce986d1dc6f8221ab8674afa ] This loop is supposed to check if ext->subset_ext_ids[j] is valid, rather than if ext->subset_ext_ids[i] is valid, before setting the extension id ext->subset_ext_ids[j] in isainfo->isa. Signed-off-by: Charlie Jenkins Reviewed-by: Conor Dooley Reviewed-by: Alexandre Ghiti Reviewed-by: Andrew Jones Fixes: 0d8295ed975b ("riscv: add ISA extension parsing for scalar crypto") Link: https://lore.kernel.org/r/20240502-cpufeature_fixes-v4-2-b3d1a088722d@rivosinc.com Signed-off-by: Palmer Dabbelt Signed-off-by: Sasha Levin commit 3e916ddc3c0b622bca5c01f5955168ef78eb66a6 Author: Charlie Jenkins Date: Thu May 2 21:50:50 2024 -0700 riscv: cpufeature: Fix thead vector hwcap removal [ Upstream commit e482eab4d1eb31031eff2b6afb71776483101979 ] The riscv_cpuinfo struct that contains mvendorid and marchid is not populated until all harts are booted which happens after the DT parsing. Use the mvendorid/marchid from the boot hart to determine if the DT contains an invalid V. Fixes: d82f32202e0d ("RISC-V: Ignore V from the riscv,isa DT property on older T-Head CPUs") Signed-off-by: Charlie Jenkins Reviewed-by: Conor Dooley Reviewed-by: Guo Ren Link: https://lore.kernel.org/r/20240502-cpufeature_fixes-v4-1-b3d1a088722d@rivosinc.com Signed-off-by: Palmer Dabbelt Signed-off-by: Sasha Levin commit bb61a84793858330ba2ca1d202d3779096f6fb54 Author: Jiri Pirko Date: Fri Apr 26 17:08:45 2024 +0200 virtio: delete vq in vp_find_vqs_msix() when request_irq() fails [ Upstream commit 89875151fccdd024d571aa884ea97a0128b968b6 ] When request_irq() fails, error path calls vp_del_vqs(). There, as vq is present in the list, free_irq() is called for the same vector. That causes following splat: [ 0.414355] Trying to free already-free IRQ 27 [ 0.414403] WARNING: CPU: 1 PID: 1 at kernel/irq/manage.c:1899 free_irq+0x1a1/0x2d0 [ 0.414510] Modules linked in: [ 0.414540] CPU: 1 PID: 1 Comm: swapper/0 Not tainted 6.9.0-rc4+ #27 [ 0.414540] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-1.fc39 04/01/2014 [ 0.414540] RIP: 0010:free_irq+0x1a1/0x2d0 [ 0.414540] Code: 1e 00 48 83 c4 08 48 89 e8 5b 5d 41 5c 41 5d 41 5e 41 5f c3 cc cc cc cc 90 8b 74 24 04 48 c7 c7 98 80 6c b1 e8 00 c9 f7 ff 90 <0f> 0b 90 90 48 89 ee 4c 89 ef e8 e0 20 b8 00 49 8b 47 40 48 8b 40 [ 0.414540] RSP: 0000:ffffb71480013ae0 EFLAGS: 00010086 [ 0.414540] RAX: 0000000000000000 RBX: ffffa099c2722000 RCX: 0000000000000000 [ 0.414540] RDX: 0000000000000000 RSI: ffffb71480013998 RDI: 0000000000000001 [ 0.414540] RBP: 0000000000000246 R08: 00000000ffffdfff R09: 0000000000000001 [ 0.414540] R10: 00000000ffffdfff R11: ffffffffb18729c0 R12: ffffa099c1c91760 [ 0.414540] R13: ffffa099c1c916a4 R14: ffffa099c1d2f200 R15: ffffa099c1c91600 [ 0.414540] FS: 0000000000000000(0000) GS:ffffa099fec40000(0000) knlGS:0000000000000000 [ 0.414540] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 0.414540] CR2: 0000000000000000 CR3: 0000000008e3e001 CR4: 0000000000370ef0 [ 0.414540] Call Trace: [ 0.414540] [ 0.414540] ? __warn+0x80/0x120 [ 0.414540] ? free_irq+0x1a1/0x2d0 [ 0.414540] ? report_bug+0x164/0x190 [ 0.414540] ? handle_bug+0x3b/0x70 [ 0.414540] ? exc_invalid_op+0x17/0x70 [ 0.414540] ? asm_exc_invalid_op+0x1a/0x20 [ 0.414540] ? free_irq+0x1a1/0x2d0 [ 0.414540] vp_del_vqs+0xc1/0x220 [ 0.414540] vp_find_vqs_msix+0x305/0x470 [ 0.414540] vp_find_vqs+0x3e/0x1a0 [ 0.414540] vp_modern_find_vqs+0x1b/0x70 [ 0.414540] init_vqs+0x387/0x600 [ 0.414540] virtnet_probe+0x50a/0xc80 [ 0.414540] virtio_dev_probe+0x1e0/0x2b0 [ 0.414540] really_probe+0xc0/0x2c0 [ 0.414540] ? __pfx___driver_attach+0x10/0x10 [ 0.414540] __driver_probe_device+0x73/0x120 [ 0.414540] driver_probe_device+0x1f/0xe0 [ 0.414540] __driver_attach+0x88/0x180 [ 0.414540] bus_for_each_dev+0x85/0xd0 [ 0.414540] bus_add_driver+0xec/0x1f0 [ 0.414540] driver_register+0x59/0x100 [ 0.414540] ? __pfx_virtio_net_driver_init+0x10/0x10 [ 0.414540] virtio_net_driver_init+0x90/0xb0 [ 0.414540] do_one_initcall+0x58/0x230 [ 0.414540] kernel_init_freeable+0x1a3/0x2d0 [ 0.414540] ? __pfx_kernel_init+0x10/0x10 [ 0.414540] kernel_init+0x1a/0x1c0 [ 0.414540] ret_from_fork+0x31/0x50 [ 0.414540] ? __pfx_kernel_init+0x10/0x10 [ 0.414540] ret_from_fork_asm+0x1a/0x30 [ 0.414540] Fix this by calling deleting the current vq when request_irq() fails. Fixes: 0b0f9dc52ed0 ("Revert "virtio_pci: use shared interrupts for virtqueues"") Signed-off-by: Jiri Pirko Message-Id: <20240426150845.3999481-1-jiri@resnulli.us> Signed-off-by: Michael S. Tsirkin Signed-off-by: Sasha Levin commit 9fc3ea3c0754186a6563d973cbd56ee3a46ecba8 Author: David Stevens Date: Thu Mar 21 10:24:44 2024 +0900 virtio_balloon: Give the balloon its own wakeup source [ Upstream commit 810d831bbbf3cbd86e5aa91c8485b4d35186144d ] Wakeup sources don't support nesting multiple events, so sharing a single object between multiple drivers can result in one driver overriding the wakeup event processing period specified by another driver. Have the virtio balloon driver use the wakeup source of the device it is bound to rather than the wakeup source of the parent device, to avoid conflicts with the transport layer. Note that although the virtio balloon's virtio_device itself isn't what actually wakes up the device, it is responsible for processing wakeup events. In the same way that EPOLLWAKEUP uses a dedicated wakeup_source to prevent suspend when userspace is processing wakeup events, a dedicated wakeup_source is necessary when processing wakeup events in a higher layer in the kernel. Fixes: b12fbc3f787e ("virtio_balloon: stay awake while adjusting balloon") Signed-off-by: David Stevens Acked-by: David Hildenbrand Message-Id: <20240321012445.1593685-2-stevensd@google.com> Signed-off-by: Michael S. Tsirkin Signed-off-by: Sasha Levin commit 2ed5f5a46df011570f47ea9aa1e5255e1d14dd5b Author: Horatiu Vultur Date: Fri May 17 15:58:08 2024 +0200 net: lan966x: Remove ptp traps in case the ptp is not enabled. [ Upstream commit eda40be3a5ff3fdce513d2bcfeaca8cc16cf962a ] Lan966x is adding ptp traps to redirect the ptp frames to the CPU such that the HW will not forward these frames anywhere. The issue is that in case ptp is not enabled and the timestamping source is et to HWTSTAMP_SOURCE_NETDEV then these traps would not be removed on the error path. Fix this by removing the traps in this case as they are not needed. Fixes: 54e1ed69c40a ("net: lan966x: convert to ndo_hwtstamp_get() and ndo_hwtstamp_set()") Suggested-by: Vladimir Oltean Reviewed-by: Vladimir Oltean Signed-off-by: Horatiu Vultur Link: https://lore.kernel.org/r/20240517135808.3025435-1-horatiu.vultur@microchip.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 08611d65715cc835513efc9b24de83ae6da3c7ab Author: Yang Li Date: Mon May 20 13:42:39 2024 +0800 rv: Update rv_en(dis)able_monitor doc to match kernel-doc [ Upstream commit 1e8b7b3dbb3103d577a586ca72bc329f7b67120b ] The patch updates the function documentation comment for rv_en(dis)able_monitor to adhere to the kernel-doc specification. Link: https://lore.kernel.org/linux-trace-kernel/20240520054239.61784-1-yang.lee@linux.alibaba.com Fixes: 102227b970a15 ("rv: Add Runtime Verification (RV) interface") Signed-off-by: Yang Li Signed-off-by: Steven Rostedt (Google) Signed-off-by: Sasha Levin commit c27a2f7668e215c1ebbccd96fab27a220a93f1f7 Author: Jiangfeng Xiao Date: Mon May 20 21:34:37 2024 +0800 arm64: asm-bug: Add .align 2 to the end of __BUG_ENTRY [ Upstream commit ffbf4fb9b5c12ff878a10ea17997147ea4ebea6f ] When CONFIG_DEBUG_BUGVERBOSE=n, we fail to add necessary padding bytes to bug_table entries, and as a result the last entry in a bug table will be ignored, potentially leading to an unexpected panic(). All prior entries in the table will be handled correctly. The arm64 ABI requires that struct fields of up to 8 bytes are naturally-aligned, with padding added within a struct such that struct are suitably aligned within arrays. When CONFIG_DEBUG_BUGVERPOSE=y, the layout of a bug_entry is: struct bug_entry { signed int bug_addr_disp; // 4 bytes signed int file_disp; // 4 bytes unsigned short line; // 2 bytes unsigned short flags; // 2 bytes } ... with 12 bytes total, requiring 4-byte alignment. When CONFIG_DEBUG_BUGVERBOSE=n, the layout of a bug_entry is: struct bug_entry { signed int bug_addr_disp; // 4 bytes unsigned short flags; // 2 bytes < implicit padding > // 2 bytes } ... with 8 bytes total, with 6 bytes of data and 2 bytes of trailing padding, requiring 4-byte alginment. When we create a bug_entry in assembly, we align the start of the entry to 4 bytes, which implicitly handles padding for any prior entries. However, we do not align the end of the entry, and so when CONFIG_DEBUG_BUGVERBOSE=n, the final entry lacks the trailing padding bytes. For the main kernel image this is not a problem as find_bug() doesn't depend on the trailing padding bytes when searching for entries: for (bug = __start___bug_table; bug < __stop___bug_table; ++bug) if (bugaddr == bug_addr(bug)) return bug; However for modules, module_bug_finalize() depends on the trailing bytes when calculating the number of entries: mod->num_bugs = sechdrs[i].sh_size / sizeof(struct bug_entry); ... and as the last bug_entry lacks the necessary padding bytes, this entry will not be counted, e.g. in the case of a single entry: sechdrs[i].sh_size == 6 sizeof(struct bug_entry) == 8; sechdrs[i].sh_size / sizeof(struct bug_entry) == 0; Consequently module_find_bug() will miss the last bug_entry when it does: for (i = 0; i < mod->num_bugs; ++i, ++bug) if (bugaddr == bug_addr(bug)) goto out; ... which can lead to a kenrel panic due to an unhandled bug. This can be demonstrated with the following module: static int __init buginit(void) { WARN(1, "hello\n"); return 0; } static void __exit bugexit(void) { } module_init(buginit); module_exit(bugexit); MODULE_LICENSE("GPL"); ... which will trigger a kernel panic when loaded: ------------[ cut here ]------------ hello Unexpected kernel BRK exception at EL1 Internal error: BRK handler: 00000000f2000800 [#1] PREEMPT SMP Modules linked in: hello(O+) CPU: 0 PID: 50 Comm: insmod Tainted: G O 6.9.1 #8 Hardware name: linux,dummy-virt (DT) pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : buginit+0x18/0x1000 [hello] lr : buginit+0x18/0x1000 [hello] sp : ffff800080533ae0 x29: ffff800080533ae0 x28: 0000000000000000 x27: 0000000000000000 x26: ffffaba8c4e70510 x25: ffff800080533c30 x24: ffffaba8c4a28a58 x23: 0000000000000000 x22: 0000000000000000 x21: ffff3947c0eab3c0 x20: ffffaba8c4e3f000 x19: ffffaba846464000 x18: 0000000000000006 x17: 0000000000000000 x16: ffffaba8c2492834 x15: 0720072007200720 x14: 0720072007200720 x13: ffffaba8c49b27c8 x12: 0000000000000312 x11: 0000000000000106 x10: ffffaba8c4a0a7c8 x9 : ffffaba8c49b27c8 x8 : 00000000ffffefff x7 : ffffaba8c4a0a7c8 x6 : 80000000fffff000 x5 : 0000000000000107 x4 : 0000000000000000 x3 : 0000000000000000 x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff3947c0eab3c0 Call trace: buginit+0x18/0x1000 [hello] do_one_initcall+0x80/0x1c8 do_init_module+0x60/0x218 load_module+0x1ba4/0x1d70 __do_sys_init_module+0x198/0x1d0 __arm64_sys_init_module+0x1c/0x28 invoke_syscall+0x48/0x114 el0_svc_common.constprop.0+0x40/0xe0 do_el0_svc+0x1c/0x28 el0_svc+0x34/0xd8 el0t_64_sync_handler+0x120/0x12c el0t_64_sync+0x190/0x194 Code: d0ffffe0 910003fd 91000000 9400000b (d4210000) ---[ end trace 0000000000000000 ]--- Kernel panic - not syncing: BRK handler: Fatal exception Fix this by always aligning the end of a bug_entry to 4 bytes, which is correct regardless of CONFIG_DEBUG_BUGVERBOSE. Fixes: 9fb7410f955f ("arm64/BUG: Use BRK instruction for generic BUG traps") Signed-off-by: Yuanbin Xie Signed-off-by: Jiangfeng Xiao Reviewed-by: Mark Rutland Link: https://lore.kernel.org/r/1716212077-43826-1-git-send-email-xiaojiangfeng@huawei.com Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit 246c901e65e77f035c56d6374fad448e30751121 Author: Aaron Conole Date: Thu May 16 16:09:41 2024 -0400 openvswitch: Set the skbuff pkt_type for proper pmtud support. [ Upstream commit 30a92c9e3d6b073932762bef2ac66f4ee784c657 ] Open vSwitch is originally intended to switch at layer 2, only dealing with Ethernet frames. With the introduction of l3 tunnels support, it crossed into the realm of needing to care a bit about some routing details when making forwarding decisions. If an oversized packet would need to be fragmented during this forwarding decision, there is a chance for pmtu to get involved and generate a routing exception. This is gated by the skbuff->pkt_type field. When a flow is already loaded into the openvswitch module this field is set up and transitioned properly as a packet moves from one port to another. In the case that a packet execute is invoked after a flow is newly installed this field is not properly initialized. This causes the pmtud mechanism to omit sending the required exception messages across the tunnel boundary and a second attempt needs to be made to make sure that the routing exception is properly setup. To fix this, we set the outgoing packet's pkt_type to PACKET_OUTGOING, since it can only get to the openvswitch module via a port device or packet command. Even for bridge ports as users, the pkt_type needs to be reset when doing the transmit as the packet is truly outgoing and routing needs to get involved post packet transformations, in the case of VXLAN/GENEVE/udp-tunnel packets. In general, the pkt_type on output gets ignored, since we go straight to the driver, but in the case of tunnel ports they go through IP routing layer. This issue is periodically encountered in complex setups, such as large openshift deployments, where multiple sets of tunnel traversal occurs. A way to recreate this is with the ovn-heater project that can setup a networking environment which mimics such large deployments. We need larger environments for this because we need to ensure that flow misses occur. In these environment, without this patch, we can see: ./ovn_cluster.sh start podman exec ovn-chassis-1 ip r a 170.168.0.5/32 dev eth1 mtu 1200 podman exec ovn-chassis-1 ip netns exec sw01p1 ip r flush cache podman exec ovn-chassis-1 ip netns exec sw01p1 \ ping 21.0.0.3 -M do -s 1300 -c2 PING 21.0.0.3 (21.0.0.3) 1300(1328) bytes of data. From 21.0.0.3 icmp_seq=2 Frag needed and DF set (mtu = 1142) --- 21.0.0.3 ping statistics --- ... Using tcpdump, we can also see the expected ICMP FRAG_NEEDED message is not sent into the server. With this patch, setting the pkt_type, we see the following: podman exec ovn-chassis-1 ip netns exec sw01p1 \ ping 21.0.0.3 -M do -s 1300 -c2 PING 21.0.0.3 (21.0.0.3) 1300(1328) bytes of data. From 21.0.0.3 icmp_seq=1 Frag needed and DF set (mtu = 1222) ping: local error: message too long, mtu=1222 --- 21.0.0.3 ping statistics --- ... In this case, the first ping request receives the FRAG_NEEDED message and a local routing exception is created. Tested-by: Jaime Caamano Reported-at: https://issues.redhat.com/browse/FDP-164 Fixes: 58264848a5a7 ("openvswitch: Add vxlan tunneling support.") Signed-off-by: Aaron Conole Acked-by: Eelco Chaudron Link: https://lore.kernel.org/r/20240516200941.16152-1-aconole@redhat.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit c59d8b1d9408235da98152c010db63f0774e9db5 Author: Olga Kornievskaia Date: Tue May 7 11:15:45 2024 -0400 pNFS/filelayout: fixup pNfs allocation modes [ Upstream commit 3ebcb24646f8c5bfad2866892d3f3cff05514452 ] Change left over allocation flags. Fixes: a245832aaa99 ("pNFS/files: Ensure pNFS allocation modes are consistent with nfsiod") Signed-off-by: Olga Kornievskaia Reviewed-by: Benjamin Coddington Signed-off-by: Trond Myklebust Signed-off-by: Sasha Levin commit 237340dee373b97833a491d2e99fcf1d4a9adafd Author: Kuniyuki Iwashima Date: Fri May 17 18:16:26 2024 +0900 tcp: Fix shift-out-of-bounds in dctcp_update_alpha(). [ Upstream commit 3ebc46ca8675de6378e3f8f40768e180bb8afa66 ] In dctcp_update_alpha(), we use a module parameter dctcp_shift_g as follows: alpha -= min_not_zero(alpha, alpha >> dctcp_shift_g); ... delivered_ce <<= (10 - dctcp_shift_g); It seems syzkaller started fuzzing module parameters and triggered shift-out-of-bounds [0] by setting 100 to dctcp_shift_g: memcpy((void*)0x20000080, "/sys/module/tcp_dctcp/parameters/dctcp_shift_g\000", 47); res = syscall(__NR_openat, /*fd=*/0xffffffffffffff9cul, /*file=*/0x20000080ul, /*flags=*/2ul, /*mode=*/0ul); memcpy((void*)0x20000000, "100\000", 4); syscall(__NR_write, /*fd=*/r[0], /*val=*/0x20000000ul, /*len=*/4ul); Let's limit the max value of dctcp_shift_g by param_set_uint_minmax(). With this patch: # echo 10 > /sys/module/tcp_dctcp/parameters/dctcp_shift_g # cat /sys/module/tcp_dctcp/parameters/dctcp_shift_g 10 # echo 11 > /sys/module/tcp_dctcp/parameters/dctcp_shift_g -bash: echo: write error: Invalid argument [0]: UBSAN: shift-out-of-bounds in net/ipv4/tcp_dctcp.c:143:12 shift exponent 100 is too large for 32-bit type 'u32' (aka 'unsigned int') CPU: 0 PID: 8083 Comm: syz-executor345 Not tainted 6.9.0-05151-g1b294a1f3561 #2 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014 Call Trace: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x201/0x300 lib/dump_stack.c:114 ubsan_epilogue lib/ubsan.c:231 [inline] __ubsan_handle_shift_out_of_bounds+0x346/0x3a0 lib/ubsan.c:468 dctcp_update_alpha+0x540/0x570 net/ipv4/tcp_dctcp.c:143 tcp_in_ack_event net/ipv4/tcp_input.c:3802 [inline] tcp_ack+0x17b1/0x3bc0 net/ipv4/tcp_input.c:3948 tcp_rcv_state_process+0x57a/0x2290 net/ipv4/tcp_input.c:6711 tcp_v4_do_rcv+0x764/0xc40 net/ipv4/tcp_ipv4.c:1937 sk_backlog_rcv include/net/sock.h:1106 [inline] __release_sock+0x20f/0x350 net/core/sock.c:2983 release_sock+0x61/0x1f0 net/core/sock.c:3549 mptcp_subflow_shutdown+0x3d0/0x620 net/mptcp/protocol.c:2907 mptcp_check_send_data_fin+0x225/0x410 net/mptcp/protocol.c:2976 __mptcp_close+0x238/0xad0 net/mptcp/protocol.c:3072 mptcp_close+0x2a/0x1a0 net/mptcp/protocol.c:3127 inet_release+0x190/0x1f0 net/ipv4/af_inet.c:437 __sock_release net/socket.c:659 [inline] sock_close+0xc0/0x240 net/socket.c:1421 __fput+0x41b/0x890 fs/file_table.c:422 task_work_run+0x23b/0x300 kernel/task_work.c:180 exit_task_work include/linux/task_work.h:38 [inline] do_exit+0x9c8/0x2540 kernel/exit.c:878 do_group_exit+0x201/0x2b0 kernel/exit.c:1027 __do_sys_exit_group kernel/exit.c:1038 [inline] __se_sys_exit_group kernel/exit.c:1036 [inline] __x64_sys_exit_group+0x3f/0x40 kernel/exit.c:1036 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xe4/0x240 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x67/0x6f RIP: 0033:0x7f6c2b5005b6 Code: Unable to access opcode bytes at 0x7f6c2b50058c. RSP: 002b:00007ffe883eb948 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7 RAX: ffffffffffffffda RBX: 00007f6c2b5862f0 RCX: 00007f6c2b5005b6 RDX: 0000000000000001 RSI: 000000000000003c RDI: 0000000000000001 RBP: 0000000000000001 R08: 00000000000000e7 R09: ffffffffffffffc0 R10: 0000000000000006 R11: 0000000000000246 R12: 00007f6c2b5862f0 R13: 0000000000000001 R14: 0000000000000000 R15: 0000000000000001 Reported-by: syzkaller Reported-by: Yue Sun Reported-by: xingwei lee Closes: https://lore.kernel.org/netdev/CAEkJfYNJM=cw-8x7_Vmj1J6uYVCWMbbvD=EFmDPVBGpTsqOxEA@mail.gmail.com/ Fixes: e3118e8359bb ("net: tcp: add DCTCP congestion control algorithm") Signed-off-by: Kuniyuki Iwashima Reviewed-by: Simon Horman Link: https://lore.kernel.org/r/20240517091626.32772-1-kuniyu@amazon.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 4a2c18d3bec3001b0f6f43946ad6be43051f64f6 Author: Neha Malcom Francis Date: Tue May 21 15:17:58 2024 +0530 regulator: tps6594-regulator: Correct multi-phase configuration [ Upstream commit 74b38cd77d3eb63c6d0ad9cf2ae59812ae54d3ee ] According to the TPS6594 PMIC Manual (linked) 8.3.2.1.4 Multi-Phase BUCK Regulator Configurations section, the PMIC ignores all the other bucks' except the primary buck's regulator registers. This is BUCK1 for configurations BUCK12, BUCK123 and BUCK1234 while it is BUCK3 for BUCK34. Correct the registers mapped for these configurations accordingly. Fixes: f17ccc5deb4d ("regulator: tps6594-regulator: Add driver for TI TPS6594 regulators") Link: https://www.ti.com/lit/gpn/tps6594-q1 Signed-off-by: Neha Malcom Francis Link: https://msgid.link/r/20240521094758.2190331-1-n-francis@ti.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 9046b387389e11ff21e589a0b6896301f801a4c2 Author: Hangbin Liu Date: Fri May 17 09:03:27 2024 +0800 selftests/net: use tc rule to filter the na packet [ Upstream commit ea63ac14292564eefc7dffe868ed354ff9ed6f4b ] Test arp_ndisc_untracked_subnets use tcpdump to filter the unsolicited and untracked na messages. It set -e before calling tcpdump. But if tcpdump filters 0 packet, it will return none zero, and cause the script to exit. Instead of using slow tcpdump to capture packets, let's using tc rule to filter out the na message. At the same time, fix function setup_v6 which only needs one parameter. Move all the related helpers from forwarding lib.sh to net lib.sh. Fixes: 0ea7b0a454ca ("selftests: net: arp_ndisc_untracked_subnets: test for arp_accept and accept_untracked_na") Signed-off-by: Hangbin Liu Reviewed-by: Simon Horman Link: https://lore.kernel.org/r/20240517010327.2631319-1-liuhangbin@gmail.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit c6cd6858a3b9b1b57710d594fff3a95b968e2beb Author: Petr Machata Date: Fri Apr 12 19:03:04 2024 +0200 selftests: net: Unify code of busywait() and slowwait() [ Upstream commit a4022a332f437ae5b10921d66058ce98a2db2c20 ] Bodies of busywait() and slowwait() functions are almost identical. Extract the common code into a helper, loopy_wait, and convert busywait() and slowwait() into trivial wrappers. Moreover, the fact that slowwait() uses seconds for units is really not intuitive, and the comment does not help much. Instead make the unit part of the name of the argument to further clarify what units are expected. Cc: Hangbin Liu Signed-off-by: Petr Machata Reviewed-by: Benjamin Poirier Reviewed-by: Hangbin Liu Signed-off-by: Paolo Abeni Stable-dep-of: ea63ac142925 ("selftests/net: use tc rule to filter the na packet") Signed-off-by: Sasha Levin commit 3f082b64890ee22337e7cab7a552a4d7ef2ff5ca Author: Petr Machata Date: Tue Mar 26 17:54:37 2024 +0100 selftests: forwarding: Convert log_test() to recognize RET values [ Upstream commit a923af1ceee744c187d1c08a0d7dc9e8ab7ca482 ] In a previous patch, the interpretation of RET value was changed to mean the kselftest framework constant with the test outcome: $ksft_pass, $ksft_xfail, etc. Update log_test() to recognize the various possible RET values. Then have EXIT_STATUS track the RET value of the current test. This differs subtly from the way RET tracks the value: while for RET we want to recognize XFAIL as a separate status, for purposes of exit code, we want to to conflate XFAIL and PASS, because they both communicate non-failure. Thus add a new helper, ksft_exit_status_merge(). With this log_test_skip() and log_test_xfail() can be reexpressed as thin wrappers around log_test. Signed-off-by: Petr Machata Link: https://lore.kernel.org/r/e5f807cb5476ab795fd14ac74da53a731a9fc432.1711464583.git.petrm@nvidia.com Signed-off-by: Jakub Kicinski Stable-dep-of: ea63ac142925 ("selftests/net: use tc rule to filter the na packet") Signed-off-by: Sasha Levin commit 4c1ed242ec8c904cb0273d5e035df73500e92f98 Author: Petr Machata Date: Tue Mar 26 17:54:36 2024 +0100 selftests: forwarding: Have RET track kselftest framework constants [ Upstream commit 596c8819cb78c047acc0cab03a863a9983a3cc62 ] The variable RET keeps track of whether the test under execution has so far failed or not. Currently it works in binary fashion: zero means everything is fine, non-zero means something failed. log_test() then uses the value to given a human-readable message. In order to allow log_test() to report skips and xfails, the semantics of RET need to be more fine-grained. Therefore have RET value be one of kselftest framework constants: $ksft_fail, $ksft_xfail, etc. The current logic in check_err() is such that first non-zero value of RET trumps all those that follow. But that is not right when RET has more fine-grained value semantics. Different outcomes have different weights. The results of PASS and XFAIL are mostly the same: they both communicate a test that did not go wrong. SKIP communicates lack of tooling, which the user should go and try to fix, and as such should not be overridden by the passes. So far, the higher-numbered statuses can be considered weightier. But FAIL should be the weightiest. Add a helper, ksft_status_merge(), which merges two statuses in a way that respects the above conditions. Express it in a generic manner, because exit status merge is subtly different, and we want to reuse the same logic. Use the new helper when setting RET in check_err(). Re-express check_fail() in terms of check_err() to avoid duplication. Signed-off-by: Petr Machata Link: https://lore.kernel.org/r/7dfff51cc925c7a3ac879b9050a0d6a327c8d21f.1711464583.git.petrm@nvidia.com Signed-off-by: Jakub Kicinski Stable-dep-of: ea63ac142925 ("selftests/net: use tc rule to filter the na packet") Signed-off-by: Sasha Levin commit ad50696e53073fc58a1fcf6e5ed6235c7cae0458 Author: Petr Machata Date: Tue Mar 26 17:54:34 2024 +0100 selftests: forwarding: Change inappropriate log_test_skip() calls [ Upstream commit 677f394956e808c709c18b92bd01d19f14a96dd5 ] The SKIP return should be used for cases where tooling of the machine under test is lacking. For cases where HW is lacking, the appropriate outcome is XFAIL. This is the case with ethtool_rmon and mlxsw_lib. For these, introduce a new helper, log_test_xfail(). Do the same for router_mpath_nh_lib. Note that it will be fixed using a more reusable way in a following patch. For the two resource_scale selftests, the log should simply not be written, because there is no problem. Cc: Tobias Waldekranz Signed-off-by: Petr Machata Link: https://lore.kernel.org/r/3d668d8fb6fa0d9eeb47ce6d9e54114348c7c179.1711464583.git.petrm@nvidia.com Signed-off-by: Jakub Kicinski Stable-dep-of: ea63ac142925 ("selftests/net: use tc rule to filter the na packet") Signed-off-by: Sasha Levin commit f6a99ef4e056c20a138a95cc51332b2b96c8f383 Author: Hangbin Liu Date: Fri May 17 08:54:35 2024 +0800 ipv6: sr: fix memleak in seg6_hmac_init_algo [ Upstream commit efb9f4f19f8e37fde43dfecebc80292d179f56c6 ] seg6_hmac_init_algo returns without cleaning up the previous allocations if one fails, so it's going to leak all that memory and the crypto tfms. Update seg6_hmac_exit to only free the memory when allocated, so we can reuse the code directly. Fixes: bf355b8d2c30 ("ipv6: sr: add core files for SR HMAC support") Reported-by: Sabrina Dubroca Closes: https://lore.kernel.org/netdev/Zj3bh-gE7eT6V6aH@hog/ Signed-off-by: Hangbin Liu Reviewed-by: Simon Horman Reviewed-by: Sabrina Dubroca Link: https://lore.kernel.org/r/20240517005435.2600277-1-liuhangbin@gmail.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 4708f49add84a57ce0ccc7bf9a6269845c631cc3 Author: Kuniyuki Iwashima Date: Thu May 16 22:48:35 2024 +0900 af_unix: Update unix_sk(sk)->oob_skb under sk_receive_queue lock. [ Upstream commit 9841991a446c87f90f66f4b9fee6fe934c1336a2 ] Billy Jheng Bing-Jhong reported a race between __unix_gc() and queue_oob(). __unix_gc() tries to garbage-collect close()d inflight sockets, and then if the socket has MSG_OOB in unix_sk(sk)->oob_skb, GC will drop the reference and set NULL to it locklessly. However, the peer socket still can send MSG_OOB message and queue_oob() can update unix_sk(sk)->oob_skb concurrently, leading NULL pointer dereference. [0] To fix the issue, let's update unix_sk(sk)->oob_skb under the sk_receive_queue's lock and take it everywhere we touch oob_skb. Note that we defer kfree_skb() in manage_oob() to silence lockdep false-positive (See [1]). [0]: BUG: kernel NULL pointer dereference, address: 0000000000000008 PF: supervisor write access in kernel mode PF: error_code(0x0002) - not-present page PGD 8000000009f5e067 P4D 8000000009f5e067 PUD 9f5d067 PMD 0 Oops: 0002 [#1] PREEMPT SMP PTI CPU: 3 PID: 50 Comm: kworker/3:1 Not tainted 6.9.0-rc5-00191-gd091e579b864 #110 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 Workqueue: events delayed_fput RIP: 0010:skb_dequeue (./include/linux/skbuff.h:2386 ./include/linux/skbuff.h:2402 net/core/skbuff.c:3847) Code: 39 e3 74 3e 8b 43 10 48 89 ef 83 e8 01 89 43 10 49 8b 44 24 08 49 c7 44 24 08 00 00 00 00 49 8b 14 24 49 c7 04 24 00 00 00 00 <48> 89 42 08 48 89 10 e8 e7 c5 42 00 4c 89 e0 5b 5d 41 5c c3 cc cc RSP: 0018:ffffc900001bfd48 EFLAGS: 00000002 RAX: 0000000000000000 RBX: ffff8880088f5ae8 RCX: 00000000361289f9 RDX: 0000000000000000 RSI: 0000000000000206 RDI: ffff8880088f5b00 RBP: ffff8880088f5b00 R08: 0000000000080000 R09: 0000000000000001 R10: 0000000000000003 R11: 0000000000000001 R12: ffff8880056b6a00 R13: ffff8880088f5280 R14: 0000000000000001 R15: ffff8880088f5a80 FS: 0000000000000000(0000) GS:ffff88807dd80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000008 CR3: 0000000006314000 CR4: 00000000007506f0 PKRU: 55555554 Call Trace: unix_release_sock (net/unix/af_unix.c:654) unix_release (net/unix/af_unix.c:1050) __sock_release (net/socket.c:660) sock_close (net/socket.c:1423) __fput (fs/file_table.c:423) delayed_fput (fs/file_table.c:444 (discriminator 3)) process_one_work (kernel/workqueue.c:3259) worker_thread (kernel/workqueue.c:3329 kernel/workqueue.c:3416) kthread (kernel/kthread.c:388) ret_from_fork (arch/x86/kernel/process.c:153) ret_from_fork_asm (arch/x86/entry/entry_64.S:257) Modules linked in: CR2: 0000000000000008 Link: https://lore.kernel.org/netdev/a00d3993-c461-43f2-be6d-07259c98509a@rbox.co/ [1] Fixes: 1279f9d9dec2 ("af_unix: Call kfree_skb() for dead unix_(sk)->oob_skb in GC.") Reported-by: Billy Jheng Bing-Jhong Signed-off-by: Kuniyuki Iwashima Link: https://lore.kernel.org/r/20240516134835.8332-1-kuniyu@amazon.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit eda9ad82e6aa6cfef47cffe89333d3fa2ebb9877 Author: Matti Vaittinen Date: Mon May 20 15:36:55 2024 +0300 regulator: tps6287x: Force writing VSEL bit [ Upstream commit 1ace99d7c7c4c801c0660246f741ff846a9b8e3c ] The data-sheet for TPS6287x-Q1 https://www.ti.com/lit/ds/symlink/tps62873-q1.pdf states at chapter 9.3.6.1 Output Voltage Range: "Note that every change to the VRANGE[1:0] bits must be followed by a write to the VSET register, even if the value of the VSET[7:0] bits does not change." The current implementation of the driver uses the regulator_set_voltage_sel_pickable_regmap() helper which further uses regmap_update_bits() to write the VSET-register. The regmap_update_bits() will not access the hardware if the new register value is same as old. It is worth noting that this is true also when the register is marked volatile, which I can't say is wrong because 'read-mnodify-write'-cycle with a volatile register is in any case something user should carefully consider. The 'range_applied_by_vsel'-flag in regulator desc was added to force the vsel register upodates by using regmap_write_bits(). This variant will always unconditionally write the bits to the hardware. It is worth noting that the vsel is now forced to be written to the hardware, whether the range was changed or not. This may cause a performance drop if users are wrtiting same voltage value repeteadly. It would be possible to read the range register to determine if it was changed, but this would be a performance issue for users who don't use reg cache for vsel. Always write the VSET register to the hardware regardless the cache. Signed-off-by: Matti Vaittinen Fixes: 7b0518fbf2be ("regulator: Add support for TI TPS6287x regulators") Link: https://msgid.link/r/ZktD50C5twF1EuKu@fedora Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit bc6d709844ee57dffd9e53e7ab2524e9d6edeb5e Author: Matti Vaittinen Date: Mon May 20 15:31:33 2024 +0300 regulator: pickable ranges: don't always cache vsel [ Upstream commit f4f4276f985a5aac7b310a4ed040b47e275e7591 ] Some PMICs treat the vsel_reg same as apply-bit. Eg, when voltage range is changed, the new voltage setting is not taking effect until the vsel register is written. Add a flag 'range_applied_by_vsel' to the regulator desc to indicate this behaviour and to force the vsel value to be written to hardware if range was changed, even if the old selector was same as the new one. Signed-off-by: Matti Vaittinen Link: https://msgid.link/r/ZktCpcGZdgHWuN_L@fedora Signed-off-by: Mark Brown Stable-dep-of: 1ace99d7c7c4 ("regulator: tps6287x: Force writing VSEL bit") Signed-off-by: Sasha Levin commit c393f7890a90a4c216a121df2974dee98834d922 Author: Dan Aloni Date: Mon May 6 12:37:59 2024 +0300 rpcrdma: fix handling for RDMA_CM_EVENT_DEVICE_REMOVAL [ Upstream commit 4836da219781ec510c4c0303df901aa643507a7a ] Under the scenario of IB device bonding, when bringing down one of the ports, or all ports, we saw xprtrdma entering a non-recoverable state where it is not even possible to complete the disconnect and shut it down the mount, requiring a reboot. Following debug, we saw that transport connect never ended after receiving the RDMA_CM_EVENT_DEVICE_REMOVAL callback. The DEVICE_REMOVAL callback is irrespective of whether the CM_ID is connected, and ESTABLISHED may not have happened. So need to work with each of these states accordingly. Fixes: 2acc5cae2923 ('xprtrdma: Prevent dereferencing r_xprt->rx_ep after it is freed') Cc: Sagi Grimberg Signed-off-by: Dan Aloni Reviewed-by: Sagi Grimberg Reviewed-by: Chuck Lever Signed-off-by: Trond Myklebust Signed-off-by: Sasha Levin commit b966ef66b9c978f89b37aaa2cb3caf0f24da7cf5 Author: Dan Aloni Date: Thu Apr 25 13:49:38 2024 +0300 sunrpc: fix NFSACL RPC retry on soft mount [ Upstream commit 0dc9f430027b8bd9073fdafdfcdeb1a073ab5594 ] It used to be quite awhile ago since 1b63a75180c6 ('SUNRPC: Refactor rpc_clone_client()'), in 2012, that `cl_timeout` was copied in so that all mount parameters propagate to NFSACL clients. However since that change, if mount options as follows are given: soft,timeo=50,retrans=16,vers=3 The resultant NFSACL client receives: cl_softrtry: 1 cl_timeout: to_initval=60000, to_maxval=60000, to_increment=0, to_retries=2, to_exponential=0 These values lead to NFSACL operations not being retried under the condition of transient network outages with soft mount. Instead, getacl call fails after 60 seconds with EIO. The simple fix is to pass the existing client's `cl_timeout` as the new client timeout. Cc: Chuck Lever Cc: Benjamin Coddington Link: https://lore.kernel.org/all/20231105154857.ryakhmgaptq3hb6b@gmail.com/T/ Fixes: 1b63a75180c6 ('SUNRPC: Refactor rpc_clone_client()') Signed-off-by: Dan Aloni Reviewed-by: Benjamin Coddington Signed-off-by: Trond Myklebust Signed-off-by: Sasha Levin commit dc4004638410d2b3e40eb9c99e7a53160e2fb96f Author: Martin Kaiser Date: Sun Apr 14 19:01:09 2024 +0200 nfs: keep server info for remounts [ Upstream commit b322bf9e983addedff0894c55e92d58f4d16d92a ] With newer kernels that use fs_context for nfs mounts, remounts fail with -EINVAL. $ mount -t nfs -o nolock 10.0.0.1:/tmp/test /mnt/test/ $ mount -t nfs -o remount /mnt/test/ mount: mounting 10.0.0.1:/tmp/test on /mnt/test failed: Invalid argument For remounts, the nfs server address and port are populated by nfs_init_fs_context and later overwritten with 0x00 bytes by nfs23_parse_monolithic. The remount then fails as the server address is invalid. Fix this by not overwriting nfs server info in nfs23_parse_monolithic if we're doing a remount. Fixes: f2aedb713c28 ("NFS: Add fs_context support.") Signed-off-by: Martin Kaiser Signed-off-by: Trond Myklebust Signed-off-by: Sasha Levin commit 14fac5fd17e2ef7714ef4fbd9a7819db100962fd Author: Benjamin Coddington Date: Wed Apr 17 14:49:29 2024 -0400 NFSv4: Fixup smatch warning for ambiguous return [ Upstream commit 37ffe06537af3e3ec212e7cbe941046fce0a822f ] Dan Carpenter reports smatch warning for nfs4_try_migration() when a memory allocation failure results in a zero return value. In this case, a transient allocation failure error will likely be retried the next time the server responds with NFS4ERR_MOVED. We can fixup the smatch warning with a small refactor: attempt all three allocations before testing and returning on a failure. Reported-by: Dan Carpenter Fixes: c3ed222745d9 ("NFSv4: Fix free of uninitialized nfs4_label on referral lookup.") Signed-off-by: Benjamin Coddington Reviewed-by: Dan Carpenter Reviewed-by: Chuck Lever Signed-off-by: Trond Myklebust Signed-off-by: Sasha Levin commit ddcf2bb619e3955f0e372d4bd8558758fd56303f Author: Shenghao Ding Date: Sat May 18 22:15:46 2024 +0800 ASoC: tas2781: Fix wrong loading calibrated data sequence [ Upstream commit b195acf5266d2dee4067f89345c3e6b88d925311 ] Calibrated data will be set to default after loading DSP config params, which will cause speaker protection work abnormally. Reload calibrated data after loading DSP config params. Remove declaration of unused API which load calibrated data in wrong sequence, changed the copyright year and correct file name in license header. Fixes: ef3bcde75d06 ("ASoC: tas2781: Add tas2781 driver") Signed-off-by: Shenghao Ding Link: https://msgid.link/r/20240518141546.1742-1-shenghao-ding@ti.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit ae44c5756bff3a6873c3ffe8f58653bd4c955023 Author: Shenghao Ding Date: Sat May 18 11:35:15 2024 +0800 ASoC: tas2552: Add TX path for capturing AUDIO-OUT data [ Upstream commit 7078ac4fd179a68d0bab448004fcd357e7a45f8d ] TAS2552 is a Smartamp with I/V sense data, add TX path to support capturing I/V data. Fixes: 38803ce7b53b ("ASoC: codecs: tas*: merge .digital_mute() into .mute_stream()") Signed-off-by: Shenghao Ding Link: https://msgid.link/r/20240518033515.866-1-shenghao-ding@ti.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 017ff397624930fd7ac7f1761f3c9d6a7100f68c Author: Ryosuke Yasuoka Date: Sun May 19 18:43:03 2024 +0900 nfc: nci: Fix uninit-value in nci_rx_work [ Upstream commit e4a87abf588536d1cdfb128595e6e680af5cf3ed ] syzbot reported the following uninit-value access issue [1] nci_rx_work() parses received packet from ndev->rx_q. It should be validated header size, payload size and total packet size before processing the packet. If an invalid packet is detected, it should be silently discarded. Fixes: d24b03535e5e ("nfc: nci: Fix uninit-value in nci_dev_up and nci_ntf_packet") Reported-and-tested-by: syzbot+d7b4dc6cd50410152534@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=d7b4dc6cd50410152534 [1] Signed-off-by: Ryosuke Yasuoka Reviewed-by: Krzysztof Kozlowski Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 5ff5697129778a05ef515763cf7bc4fec6f14d79 Author: Taehee Yoo Date: Sat May 18 13:20:52 2024 +0000 selftests: net: kill smcrouted in the cleanup logic in amt.sh [ Upstream commit cc563e749810f5636451d4b833fbd689899ecdb9 ] The amt.sh requires smcrouted for multicasting routing. So, it starts smcrouted before forwarding tests. It must be stopped after all tests, but it isn't. To fix this issue, it kills smcrouted in the cleanup logic. Fixes: c08e8baea78e ("selftests: add amt interface selftest script") Signed-off-by: Taehee Yoo Reviewed-by: Simon Horman Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit f5fec1588642e415a3d72e02140160661b303940 Author: Andrea Mayer Date: Fri May 17 18:45:41 2024 +0200 ipv6: sr: fix missing sk_buff release in seg6_input_core [ Upstream commit 5447f9708d9e4c17a647b16a9cb29e9e02820bd9 ] The seg6_input() function is responsible for adding the SRH into a packet, delegating the operation to the seg6_input_core(). This function uses the skb_cow_head() to ensure that there is sufficient headroom in the sk_buff for accommodating the link-layer header. In the event that the skb_cow_header() function fails, the seg6_input_core() catches the error but it does not release the sk_buff, which will result in a memory leak. This issue was introduced in commit af3b5158b89d ("ipv6: sr: fix BUG due to headroom too small after SRH push") and persists even after commit 7a3f5b0de364 ("netfilter: add netfilter hooks to SRv6 data plane"), where the entire seg6_input() code was refactored to deal with netfilter hooks. The proposed patch addresses the identified memory leak by requiring the seg6_input_core() function to release the sk_buff in the event that skb_cow_head() fails. Fixes: af3b5158b89d ("ipv6: sr: fix BUG due to headroom too small after SRH push") Signed-off-by: Andrea Mayer Reviewed-by: Simon Horman Reviewed-by: David Ahern Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 605c18f6f6b66bad3d935b92f7a5da254afad05f Author: Florian Fainelli Date: Thu May 16 09:56:30 2024 -0700 net: Always descend into dsa/ folder with CONFIG_NET_DSA enabled [ Upstream commit b1fa60ec252fba39130107074becd12d0b3f83ec ] Stephen reported that he was unable to get the dsa_loop driver to get probed, and the reason ended up being because he had CONFIG_FIXED_PHY=y in his kernel configuration. As Masahiro explained it: "obj-m += dsa/" means everything under dsa/ must be modular. If there is a built-in object under dsa/ with CONFIG_NET_DSA=m, you cannot do "obj-$(CONFIG_NET_DSA) += dsa/". You need to change it back to "obj-y += dsa/". This was the case here whereby CONFIG_NET_DSA=m, and so the obj-$(CONFIG_FIXED_PHY) += dsa_loop_bdinfo.o rule is not executed and the DSA loop mdio_board info structure is not registered with the kernel, and eventually the device is simply not found. To preserve the intention of the original commit of limiting the amount of folder descending, conditionally descend into drivers/net/dsa when CONFIG_NET_DSA is enabled. Fixes: 227d72063fcc ("dsa: simplify Kconfig symbols and dependencies") Reported-by: Stephen Langstaff Signed-off-by: Florian Fainelli Reviewed-by: Vladimir Oltean Reviewed-by: Alexander Lobakin Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit f130577db7eb303722e44353c2061f0b1b1761be Author: Masahiro Yamada Date: Sun Feb 4 21:20:03 2024 +0900 x86/kconfig: Select ARCH_WANT_FRAME_POINTERS again when UNWINDER_FRAME_POINTER=y [ Upstream commit 66ee3636eddcc82ab82b539d08b85fb5ac1dff9b ] It took me some time to understand the purpose of the tricky code at the end of arch/x86/Kconfig.debug. Without it, the following would be shown: WARNING: unmet direct dependencies detected for FRAME_POINTER because 81d387190039 ("x86/kconfig: Consolidate unwinders into multiple choice selection") removed 'select ARCH_WANT_FRAME_POINTERS'. The correct and more straightforward approach should have been to move it where 'select FRAME_POINTER' is located. Several architectures properly handle the conditional selection of ARCH_WANT_FRAME_POINTERS. For example, 'config UNWINDER_FRAME_POINTER' in arch/arm/Kconfig.debug. Fixes: 81d387190039 ("x86/kconfig: Consolidate unwinders into multiple choice selection") Signed-off-by: Masahiro Yamada Signed-off-by: Borislav Petkov (AMD) Acked-by: Josh Poimboeuf Link: https://lore.kernel.org/r/20240204122003.53795-1-masahiroy@kernel.org Signed-off-by: Sasha Levin commit cde22f8a50877feae95386db717d4bf644026e8d Author: Kees Cook Date: Tue May 14 16:37:48 2024 -0700 ubsan: Restore dependency on ARCH_HAS_UBSAN [ Upstream commit 890a64810d59b1a58ed26efc28cfd821fc068e84 ] While removing CONFIG_UBSAN_SANITIZE_ALL, ARCH_HAS_UBSAN wasn't correctly depended on. Restore this, as we do not want to attempt UBSAN builds unless it's actually been tested on a given architecture. Reported-by: Masahiro Yamada Closes: https://lore.kernel.org/all/20240514095427.541201-1-masahiroy@kernel.org Fixes: 918327e9b7ff ("ubsan: Remove CONFIG_UBSAN_SANITIZE_ALL") Link: https://lore.kernel.org/r/20240514233747.work.441-kees@kernel.org Signed-off-by: Kees Cook Signed-off-by: Sasha Levin commit 3d0693a75f4aba3b21aabc31261e9e6aa42775b8 Author: Namhyung Kim Date: Tue May 14 11:00:50 2024 -0700 perf/arm-dmc620: Fix lockdep assert in ->event_init() [ Upstream commit a4c5a457c6107dfe9dc65a104af1634811396bac ] for_each_sibling_event() checks leader's ctx but it doesn't have the ctx yet if it's the leader. Like in perf_event_validate_size(), we should skip checking siblings in that case. Acked-by: Mark Rutland Fixes: f3c0eba28704 ("perf: Add a few assertions") Reported-by: Greg Thelen Cc: Robin Murphy Cc: Tuan Phan Signed-off-by: Namhyung Kim Reviewed-by: Robin Murphy Link: https://lore.kernel.org/r/20240514180050.182454-1-namhyung@kernel.org Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit 855dced6a161934504387d82caa9cbf827fb6b9d Author: Roger Pau Monne Date: Mon Apr 29 17:50:53 2024 +0200 xen/x86: add extra pages to unpopulated-alloc if available [ Upstream commit a6aa4eb994ee9ced905743817c5de8451d26b911 ] Commit 262fc47ac174 ('xen/balloon: don't use PV mode extra memory for zone device allocations') removed the addition of the extra memory ranges to the unpopulated range allocator, using those only for the balloon driver. This forces the unpopulated allocator to attach hotplug ranges even when spare memory (as part of the extra memory ranges) is available. Furthermore, on PVH domains it defeats the purpose of commit 38620fc4e893 ('x86/xen: attempt to inflate the memory balloon on PVH'), as extra memory ranges would only be used to map foreign memory if the kernel is built without XEN_UNPOPULATED_ALLOC support. Fix this by adding a helpers that adds the extra memory ranges to the list of unpopulated pages, and zeroes the ranges so they are not also consumed by the balloon driver. This should have been part of 38620fc4e893, hence the fixes tag. Note the current logic relies on unpopulated_init() (and hence arch_xen_unpopulated_init()) always being called ahead of balloon_init(), so that the extra memory regions are consumed by arch_xen_unpopulated_init(). Fixes: 38620fc4e893 ('x86/xen: attempt to inflate the memory balloon on PVH') Signed-off-by: Roger Pau Monné Reviewed-by: Juergen Gross Link: https://lore.kernel.org/r/20240429155053.72509-1-roger.pau@citrix.com Signed-off-by: Juergen Gross Signed-off-by: Sasha Levin commit c87c9a8a66ea3a913b26bd9ec93ec14e6b5a3c63 Author: Matti Vaittinen Date: Thu May 16 11:54:41 2024 +0300 regulator: bd71828: Don't overwrite runtime voltages [ Upstream commit 0f9f7c63c415e287cd57b5c98be61eb320dedcfc ] Some of the regulators on the BD71828 have common voltage setting for RUN/SUSPEND/IDLE/LPSR states. The enable control can be set for each state though. The driver allows setting the voltage values for these states via device-tree. As a side effect, setting the voltages for SUSPEND/IDLE/LPSR will also change the RUN level voltage which is not desired and can break the system. The comment in code reflects this behaviour, but it is likely to not make people any happier. The right thing to do is to allow setting the enable/disable state at SUSPEND/IDLE/LPSR via device-tree, but to disallow setting state specific voltages for those regulators. BUCK1 is a bit different. It only shares the SUSPEND and LPSR state voltages. The former behaviour of allowing to silently overwrite the SUSPEND state voltage by LPSR state voltage is also changed here so that the SUSPEND voltage is prioritized over LPSR voltage. Prevent setting PMIC state specific voltages for regulators which do not support it. Signed-off-by: Matti Vaittinen Fixes: 522498f8cb8c ("regulator: bd71828: Basic support for ROHM bd71828 PMIC regulators") Link: https://msgid.link/r/e1883ae1e3ae5668f1030455d4750923561f3d68.1715848512.git.mazziesaccount@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit d37192627f10c82a8bee7e1b2b3f07428b6f8c3f Author: Waiman Long Date: Wed May 15 10:30:59 2024 -0400 blk-cgroup: Properly propagate the iostat update up the hierarchy [ Upstream commit 9d230c09964e6e18c8f6e4f0d41ee90eef45ec1c ] During a cgroup_rstat_flush() call, the lowest level of nodes are flushed first before their parents. Since commit 3b8cc6298724 ("blk-cgroup: Optimize blkcg_rstat_flush()"), iostat propagation was still done to the parent. Grandparent, however, may not get the iostat update if the parent has no blkg_iostat_set queued in its lhead lockless list. Fix this iostat propagation problem by queuing the parent's global blkg->iostat into one of its percpu lockless lists to make sure that the delta will always be propagated up to the grandparent and so on toward the root blkcg. Note that successive calls to __blkcg_rstat_flush() are serialized by the cgroup_rstat_lock. So no special barrier is used in the reading and writing of blkg->iostat.lqueued. Fixes: 3b8cc6298724 ("blk-cgroup: Optimize blkcg_rstat_flush()") Reported-by: Dan Schatzberg Closes: https://lore.kernel.org/lkml/ZkO6l%2FODzadSgdhC@dschatzberg-fedora-PF3DHTBV/ Signed-off-by: Waiman Long Reviewed-by: Ming Lei Acked-by: Tejun Heo Link: https://lore.kernel.org/r/20240515143059.276677-1-longman@redhat.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 785298ab6b802afa75089239266b6bbea590809c Author: Ming Lei Date: Wed May 15 09:31:57 2024 +0800 blk-cgroup: fix list corruption from reorder of WRITE ->lqueued [ Upstream commit d0aac2363549e12cc79b8e285f13d5a9f42fd08e ] __blkcg_rstat_flush() can be run anytime, especially when blk_cgroup_bio_start is being executed. If WRITE of `->lqueued` is re-ordered with READ of 'bisc->lnode.next' in the loop of __blkcg_rstat_flush(), `next_bisc` can be assigned with one stat instance being added in blk_cgroup_bio_start(), then the local list in __blkcg_rstat_flush() could be corrupted. Fix the issue by adding one barrier. Cc: Tejun Heo Cc: Waiman Long Fixes: 3b8cc6298724 ("blk-cgroup: Optimize blkcg_rstat_flush()") Signed-off-by: Ming Lei Link: https://lore.kernel.org/r/20240515013157.443672-3-ming.lei@redhat.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 89bb36c72e1951843f9e04dc84412e31fcc849a9 Author: Ming Lei Date: Wed May 15 09:31:56 2024 +0800 blk-cgroup: fix list corruption from resetting io stat [ Upstream commit 6da6680632792709cecf2b006f2fe3ca7857e791 ] Since commit 3b8cc6298724 ("blk-cgroup: Optimize blkcg_rstat_flush()"), each iostat instance is added to blkcg percpu list, so blkcg_reset_stats() can't reset the stat instance by memset(), otherwise the llist may be corrupted. Fix the issue by only resetting the counter part. Cc: Tejun Heo Cc: Waiman Long Cc: Jay Shin Fixes: 3b8cc6298724 ("blk-cgroup: Optimize blkcg_rstat_flush()") Signed-off-by: Ming Lei Acked-by: Tejun Heo Reviewed-by: Waiman Long Link: https://lore.kernel.org/r/20240515013157.443672-2-ming.lei@redhat.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 4d3dbaa252257d20611c3647290e6171f1bbd6c8 Author: Sungwoo Kim Date: Sat May 4 15:23:29 2024 -0400 Bluetooth: L2CAP: Fix div-by-zero in l2cap_le_flowctl_init() [ Upstream commit a5b862c6a221459d54e494e88965b48dcfa6cc44 ] l2cap_le_flowctl_init() can cause both div-by-zero and an integer overflow since hdev->le_mtu may not fall in the valid range. Move MTU from hci_dev to hci_conn to validate MTU and stop the connection process earlier if MTU is invalid. Also, add a missing validation in read_buffer_size() and make it return an error value if the validation fails. Now hci_conn_add() returns ERR_PTR() as it can fail due to the both a kzalloc failure and invalid MTU value. divide error: 0000 [#1] PREEMPT SMP KASAN NOPTI CPU: 0 PID: 67 Comm: kworker/u5:0 Tainted: G W 6.9.0-rc5+ #20 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 Workqueue: hci0 hci_rx_work RIP: 0010:l2cap_le_flowctl_init+0x19e/0x3f0 net/bluetooth/l2cap_core.c:547 Code: e8 17 17 0c 00 66 41 89 9f 84 00 00 00 bf 01 00 00 00 41 b8 02 00 00 00 4c 89 fe 4c 89 e2 89 d9 e8 27 17 0c 00 44 89 f0 31 d2 <66> f7 f3 89 c3 ff c3 4d 8d b7 88 00 00 00 4c 89 f0 48 c1 e8 03 42 RSP: 0018:ffff88810bc0f858 EFLAGS: 00010246 RAX: 00000000000002a0 RBX: 0000000000000000 RCX: dffffc0000000000 RDX: 0000000000000000 RSI: ffff88810bc0f7c0 RDI: ffffc90002dcb66f RBP: ffff88810bc0f880 R08: aa69db2dda70ff01 R09: 0000ffaaaaaaaaaa R10: 0084000000ffaaaa R11: 0000000000000000 R12: ffff88810d65a084 R13: dffffc0000000000 R14: 00000000000002a0 R15: ffff88810d65a000 FS: 0000000000000000(0000) GS:ffff88811ac00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020000100 CR3: 0000000103268003 CR4: 0000000000770ef0 PKRU: 55555554 Call Trace: l2cap_le_connect_req net/bluetooth/l2cap_core.c:4902 [inline] l2cap_le_sig_cmd net/bluetooth/l2cap_core.c:5420 [inline] l2cap_le_sig_channel net/bluetooth/l2cap_core.c:5486 [inline] l2cap_recv_frame+0xe59d/0x11710 net/bluetooth/l2cap_core.c:6809 l2cap_recv_acldata+0x544/0x10a0 net/bluetooth/l2cap_core.c:7506 hci_acldata_packet net/bluetooth/hci_core.c:3939 [inline] hci_rx_work+0x5e5/0xb20 net/bluetooth/hci_core.c:4176 process_one_work kernel/workqueue.c:3254 [inline] process_scheduled_works+0x90f/0x1530 kernel/workqueue.c:3335 worker_thread+0x926/0xe70 kernel/workqueue.c:3416 kthread+0x2e3/0x380 kernel/kthread.c:388 ret_from_fork+0x5c/0x90 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 Modules linked in: ---[ end trace 0000000000000000 ]--- Fixes: 6ed58ec520ad ("Bluetooth: Use LE buffers for LE traffic") Suggested-by: Luiz Augusto von Dentz Signed-off-by: Sungwoo Kim Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 7860dcbaf5137baf9029b0817c402e7fbf4c2b44 Author: Iulia Tanasescu Date: Tue Apr 2 14:39:31 2024 +0300 Bluetooth: ISO: Handle PA sync when no BIGInfo reports are generated [ Upstream commit d356c924e7a3adbea1e3e4ff4e098bcd9b99a82d ] In case of a Broadcast Source that has PA enabled but no active BIG, a Broadcast Sink needs to establish PA sync and parse BASE from PA reports. This commit moves the allocation of a PA sync hcon from the BIGInfo advertising report event to the PA sync established event. After the first complete PA report, the hcon is notified to the ISO layer. A child socket is allocated and enqueued in the parent's accept queue. BIGInfo reports also need to be processed, to extract the encryption field and inform userspace. After the first BIGInfo report is received, the PA sync hcon is notified again to the ISO layer. Since a socket will be found this time, the socket state will transition to BT_CONNECTED and the userspace will be woken up using sk_state_change. Signed-off-by: Iulia Tanasescu Signed-off-by: Luiz Augusto von Dentz Stable-dep-of: a5b862c6a221 ("Bluetooth: L2CAP: Fix div-by-zero in l2cap_le_flowctl_init()") Signed-off-by: Sasha Levin commit ca5ad9c231c2fc69526d25436ba592633d7db1e4 Author: Mohamed Ahmed Date: Thu May 9 23:43:52 2024 +0300 drm/nouveau: use tile_mode and pte_kind for VM_BIND bo allocations [ Upstream commit 959314c438caf1b62d787f02d54a193efda38880 ] Allow PTE kind and tile mode on BO create with VM_BIND, and add a GETPARAM to indicate this change. This is needed to support modifiers in NVK and ensure correctness when dealing with the nouveau GL driver. The userspace modifiers implementation this is for can be found here: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24795 Fixes: b88baab82871 ("drm/nouveau: implement new VM_BIND uAPI") Signed-off-by: Mohamed Ahmed Reviewed-by: Faith Ekstrand Signed-off-by: Danilo Krummrich Link: https://patchwork.freedesktop.org/patch/msgid/20240509204352.7597-1-mohamedahmedegypt2001@gmail.com Signed-off-by: Sasha Levin commit 831af90f503df7a006383b9e18bb0c75fe1a5240 Author: Takashi Iwai Date: Mon May 13 08:40:08 2024 +0200 ALSA: hda/realtek: Drop doubly quirk entry for 103c:8a2e [ Upstream commit d731b1ed15052580b7b2f40559021012d280f1d9 ] There are two quirk entries for SSID 103c:8a2e. Drop the latter one that isn't applied in anyway. As both point to the same quirk action, there is no actual behavior change. Fixes: aa8e3ef4fe53 ("ALSA: hda/realtek: Add quirks for various HP ENVY models") Link: https://lore.kernel.org/r/20240513064010.17546-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit c064b80316b7337d341fd47ca6ac602476b099d2 Author: Bard Liao Date: Thu May 9 11:36:58 2024 -0500 ASoC: rt715-sdca-sdw: Fix wrong complete waiting in rt715_dev_resume() [ Upstream commit c8bdf9e727acb6e1b37febf422ef1751e5a2c7d1 ] enumeration_complete will be completed when a peripheral is attached. And initialization_complete will be completed when a peripheral is initialized. rt715_dev_resume() should wait for initialization_complete instead of enumeration_complete. the issue exists since commit 20d17057f0a8 ("ASoC: rt715-sdca: Add RT715 sdca vendor-specific driver"), but the commit can only apply to commit f892e66fcabc ("ASoC: rt-sdw*: add __func__ to all error logs"). Fixes: f892e66fcabc ("ASoC: rt-sdw*: add __func__ to all error logs") Signed-off-by: Bard Liao Signed-off-by: Pierre-Louis Bossart Link: https://lore.kernel.org/r/20240509163658.68062-1-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 7a7d7dac4d63bf3d77295a46035cf501c7825d23 Author: Hsin-Te Yuan Date: Thu May 9 07:31:29 2024 +0000 ASoC: mediatek: mt8192: fix register configuration for tdm [ Upstream commit a85ed162f0efcfdd664954414a05d1d560cc95dc ] For DSP_A, data is a BCK cycle behind LRCK trigger edge. For DSP_B, this delay doesn't exist. Fix the delay configuration to match the standard. Fixes: 52fcd65414abfc ("ASoC: mediatek: mt8192: support tdm in platform driver") Signed-off-by: Hsin-Te Yuan Reviewed-by: AngeloGioacchino Del Regno Reviewed-by: Chen-Yu Tsai Link: https://lore.kernel.org/r/20240509-8192-tdm-v1-1-530b54645763@chromium.org Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 60d5e087e5f334475b032ad7e6ad849fb998f303 Author: Richard Fitzgerald Date: Wed May 8 11:08:11 2024 +0100 ALSA: hda: cs35l56: Fix lifetime of cs_dsp instance [ Upstream commit d344873c4cbde249b7152d36a273bcc45864001e ] The cs_dsp instance is initialized in the driver probe() so it should be freed in the driver remove(). Also fix a missing call to cs_dsp_remove() in the error path of cs35l56_hda_common_probe(). The call to cs_dsp_remove() was being done in the component unbind callback cs35l56_hda_unbind(). This meant that if the driver was unbound and then re-bound it would be using an uninitialized cs_dsp instance. It is best to initialize the cs_dsp instance in probe() so that it can return an error if it fails. The component binding API doesn't have any error handling so there's no way to handle a failure if cs_dsp was initialized in the bind. Signed-off-by: Richard Fitzgerald Fixes: 73cfbfa9caea ("ALSA: hda/cs35l56: Add driver for Cirrus Logic CS35L56 amplifier") Link: https://lore.kernel.org/r/20240508100811.49514-1-rf@opensource.cirrus.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 94f579306d700da92dd28ecfca2e72ec6c45b90b Author: Richard Fitzgerald Date: Wed May 8 11:03:47 2024 +0100 ALSA: hda: hda_component: Initialize shared data during bind callback [ Upstream commit ec6f32bc924d1c00cbcd5672510758f7088f2513 ] Move the initialization of the shared struct hda_component array into hda_component_manager_bind(). The purpose of the manager bind() callback is to allow it to perform initialization before binding in the component drivers. This is the correct place to initialize the shared data. The original implementation initialized the shared data in hda_component_manager_init(). This is only done once during probe() of the manager driver. So if the component binding was unbound and then rebound, the shared data would not be re-initialized. Signed-off-by: Richard Fitzgerald Fixes: fd895a74dc1d ("ALSA: hda: realtek: Move hda_component implementation to module") Link: https://lore.kernel.org/r/20240508100347.47283-1-rf@opensource.cirrus.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 3291486af5636540980ea55bae985f3eaa5b0740 Author: Richard Fitzgerald Date: Wed May 8 10:56:27 2024 +0100 ALSA: hda/cs_dsp_ctl: Use private_free for control cleanup [ Upstream commit 172811e3a557d8681a5e2d0f871dc04a2d17eb13 ] Use the control private_free callback to free the associated data block. This ensures that the memory won't leak, whatever way the control gets destroyed. The original implementation didn't actually remove the ALSA controls in hda_cs_dsp_control_remove(). It only freed the internal tracking structure. This meant it was possible to remove/unload the amp driver while leaving its ALSA controls still present in the soundcard. Obviously attempting to access them could cause segfaults or at least dereferencing stale pointers. Signed-off-by: Richard Fitzgerald Fixes: 3233b978af23 ("ALSA: hda: hda_cs_dsp_ctl: Add Library to support CS_DSP ALSA controls") Link: https://lore.kernel.org/r/20240508095627.44476-1-rf@opensource.cirrus.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit dd9787d7723482be3dd27be1949451de393cfbee Author: Oliver Upton Date: Wed May 8 07:19:52 2024 +0000 KVM: arm64: Destroy mpidr_data for 'late' vCPU creation [ Upstream commit ce5d2448eb8fe83aed331db53a08612286a137dd ] A particularly annoying userspace could create a vCPU after KVM has computed mpidr_data for the VM, either by racing against VGIC initialization or having a userspace irqchip. In any case, this means mpidr_data no longer fully describes the VM, and attempts to find the new vCPU with kvm_mpidr_to_vcpu() will fail. The fix is to discard mpidr_data altogether, as it is only a performance optimization and not required for correctness. In all likelihood KVM will recompute the mappings when KVM_RUN is called on the new vCPU. Note that reads of mpidr_data are not guarded by a lock; promote to RCU to cope with the possibility of mpidr_data being invalidated at runtime. Fixes: 54a8006d0b49 ("KVM: arm64: Fast-track kvm_mpidr_to_vcpu() when mpidr_data is available") Signed-off-by: Oliver Upton Link: https://lore.kernel.org/r/20240508071952.2035422-1-oliver.upton@linux.dev Signed-off-by: Marc Zyngier Signed-off-by: Sasha Levin commit 801aee63e5e4a94b37db03d4de2f143bb17f301f Author: Christophe JAILLET Date: Sun Jan 28 12:34:25 2024 +0100 KVM: PPC: Book3S HV nestedv2: Fix an error handling path in gs_msg_ops_kvmhv_nestedv2_config_fill_info() [ Upstream commit b52e8cd3f835869370f8540f1bc804a47a47f02b ] The return value of kvmppc_gse_put_buff_info() is not assigned to 'rc' and 'rc' is uninitialized at this point. So the error handling can not work. Assign the expected value to 'rc' to fix the issue. Fixes: 19d31c5f1157 ("KVM: PPC: Add support for nestedv2 guests") Signed-off-by: Christophe JAILLET Reviewed-by: Vaibhav Jain Signed-off-by: Michael Ellerman Link: https://msgid.link/a7ed4cc12e0a0bbd97fac44fe6c222d1c393ec95.1706441651.git.christophe.jaillet@wanadoo.fr Signed-off-by: Sasha Levin commit 6638a7073b4f77a4d8e1717a9c760ec825123f48 Author: Vaibhav Jain Date: Mon Apr 15 09:27:29 2024 +0530 KVM: PPC: Book3S HV nestedv2: Cancel pending DEC exception [ Upstream commit 7be6ce7043b4cf293c8826a48fd9f56931cef2cf ] This reverts commit 180c6b072bf3 ("KVM: PPC: Book3S HV nestedv2: Do not cancel pending decrementer exception") [1] which prevented canceling a pending HDEC exception for nestedv2 KVM guests. It was done to avoid overhead of a H_GUEST_GET_STATE hcall to read the 'DEC expiry TB' register which was higher compared to handling extra decrementer exceptions. However recent benchmarks indicate that overhead of not handling 'DECR' expiry for Nested KVM Guest(L2) is higher and results in much larger exits to Pseries Host(L1) as indicated by the Unixbench-arithoh bench[2] Metric | Current upstream | Revert [1] | Difference % ======================================================================== arithoh-count (10) | 3244831634 | 3403089673 | +04.88% kvm_hv:kvm_guest_exit | 513558 | 152441 | -70.32% probe:kvmppc_gsb_recv | 28060 | 28110 | +00.18% N=1 As indicated by the data above that reverting [1] results in substantial reduction in number of L2->L1 exits with only slight increase in number of H_GUEST_GET_STATE hcalls to read the value of 'DEC expiry TB'. This results in an overall ~4% improvement of arithoh[2] throughput. [1] commit 180c6b072bf3 ("KVM: PPC: Book3S HV nestedv2: Do not cancel pending decrementer exception") [2] https://github.com/kdlucas/byte-unixbench/ Fixes: 180c6b072bf3 ("KVM: PPC: Book3S HV nestedv2: Do not cancel pending decrementer exception") Signed-off-by: Vaibhav Jain Signed-off-by: Michael Ellerman Link: https://msgid.link/20240415035731.103097-1-vaibhav@linux.ibm.com Signed-off-by: Sasha Levin commit 0d5c13227bf28b3461127f5b27da8775afa780a2 Author: Christophe Leroy Date: Tue Mar 5 16:36:23 2024 +0100 powerpc/bpf/32: Fix failing test_bpf tests [ Upstream commit 8ecf3c1dab1c675721d3d0255556abe2306fa340 ] Recent additions in BPF like cpu v4 instructions, test_bpf module exhibits the following failures: test_bpf: #82 ALU_MOVSX | BPF_B jited:1 ret 2 != 1 (0x2 != 0x1)FAIL (1 times) test_bpf: #83 ALU_MOVSX | BPF_H jited:1 ret 2 != 1 (0x2 != 0x1)FAIL (1 times) test_bpf: #84 ALU64_MOVSX | BPF_B jited:1 ret 2 != 1 (0x2 != 0x1)FAIL (1 times) test_bpf: #85 ALU64_MOVSX | BPF_H jited:1 ret 2 != 1 (0x2 != 0x1)FAIL (1 times) test_bpf: #86 ALU64_MOVSX | BPF_W jited:1 ret 2 != 1 (0x2 != 0x1)FAIL (1 times) test_bpf: #165 ALU_SDIV_X: -6 / 2 = -3 jited:1 ret 2147483645 != -3 (0x7ffffffd != 0xfffffffd)FAIL (1 times) test_bpf: #166 ALU_SDIV_K: -6 / 2 = -3 jited:1 ret 2147483645 != -3 (0x7ffffffd != 0xfffffffd)FAIL (1 times) test_bpf: #169 ALU_SMOD_X: -7 % 2 = -1 jited:1 ret 1 != -1 (0x1 != 0xffffffff)FAIL (1 times) test_bpf: #170 ALU_SMOD_K: -7 % 2 = -1 jited:1 ret 1 != -1 (0x1 != 0xffffffff)FAIL (1 times) test_bpf: #172 ALU64_SMOD_K: -7 % 2 = -1 jited:1 ret 1 != -1 (0x1 != 0xffffffff)FAIL (1 times) test_bpf: #313 BSWAP 16: 0x0123456789abcdef -> 0xefcd eBPF filter opcode 00d7 (@2) unsupported jited:0 301 PASS test_bpf: #314 BSWAP 32: 0x0123456789abcdef -> 0xefcdab89 eBPF filter opcode 00d7 (@2) unsupported jited:0 555 PASS test_bpf: #315 BSWAP 64: 0x0123456789abcdef -> 0x67452301 eBPF filter opcode 00d7 (@2) unsupported jited:0 268 PASS test_bpf: #316 BSWAP 64: 0x0123456789abcdef >> 32 -> 0xefcdab89 eBPF filter opcode 00d7 (@2) unsupported jited:0 269 PASS test_bpf: #317 BSWAP 16: 0xfedcba9876543210 -> 0x1032 eBPF filter opcode 00d7 (@2) unsupported jited:0 460 PASS test_bpf: #318 BSWAP 32: 0xfedcba9876543210 -> 0x10325476 eBPF filter opcode 00d7 (@2) unsupported jited:0 320 PASS test_bpf: #319 BSWAP 64: 0xfedcba9876543210 -> 0x98badcfe eBPF filter opcode 00d7 (@2) unsupported jited:0 222 PASS test_bpf: #320 BSWAP 64: 0xfedcba9876543210 >> 32 -> 0x10325476 eBPF filter opcode 00d7 (@2) unsupported jited:0 273 PASS test_bpf: #344 BPF_LDX_MEMSX | BPF_B eBPF filter opcode 0091 (@5) unsupported jited:0 432 PASS test_bpf: #345 BPF_LDX_MEMSX | BPF_H eBPF filter opcode 0089 (@5) unsupported jited:0 381 PASS test_bpf: #346 BPF_LDX_MEMSX | BPF_W eBPF filter opcode 0081 (@5) unsupported jited:0 505 PASS test_bpf: #490 JMP32_JA: Unconditional jump: if (true) return 1 eBPF filter opcode 0006 (@1) unsupported jited:0 261 PASS test_bpf: Summary: 1040 PASSED, 10 FAILED, [924/1038 JIT'ed] Fix them by adding missing processing. Fixes: daabb2b098e0 ("bpf/tests: add tests for cpuv4 instructions") Signed-off-by: Christophe Leroy Signed-off-by: Michael Ellerman Link: https://msgid.link/91de862dda99d170697eb79ffb478678af7e0b27.1709652689.git.christophe.leroy@csgroup.eu Signed-off-by: Sasha Levin commit 08169cc8e15e3be0ce8eb701f2db063ebfc795d8 Author: Yoann Congal Date: Sun May 5 10:03:41 2024 +0200 printk: Fix LOG_CPU_MAX_BUF_SHIFT when BASE_SMALL is enabled [ Upstream commit 320bf43190514be5c00e11f47ec2160dd3993844 ] LOG_CPU_MAX_BUF_SHIFT default value depends on BASE_SMALL: config LOG_CPU_MAX_BUF_SHIFT default 12 if !BASE_SMALL default 0 if BASE_SMALL But, BASE_SMALL is a config of type int and "!BASE_SMALL" is always evaluated to true whatever is the value of BASE_SMALL. This patch fixes this by using the correct conditional operator for int type : BASE_SMALL != 0. Note: This changes CONFIG_LOG_CPU_MAX_BUF_SHIFT=12 to CONFIG_LOG_CPU_MAX_BUF_SHIFT=0 for BASE_SMALL defconfigs, but that will not be a big impact due to this code in kernel/printk/printk.c: /* by default this will only continue through for large > 64 CPUs */ if (cpu_extra <= __LOG_BUF_LEN / 2) return; Systems using CONFIG_BASE_SMALL and having 64+ CPUs should be quite rare. John Ogness (printk reviewer) wrote: > For printk this will mean that BASE_SMALL systems were probably > previously allocating/using the dynamic ringbuffer and now they will > just continue to use the static ringbuffer. Which is fine and saves > memory (as it should). Petr Mladek (printk maintainer) wrote: > More precisely, it allocated the buffer dynamically when the sum > of per-CPU-extra space exceeded half of the default static ring > buffer. This happened for systems with more than 64 CPUs with > the default config values. Reported-by: Geert Uytterhoeven Closes: https://lore.kernel.org/all/CAMuHMdWm6u1wX7efZQf=2XUAHascps76YQac6rdnQGhc8nop_Q@mail.gmail.com/ Reported-by: Vegard Nossum Closes: https://lore.kernel.org/all/f6856be8-54b7-0fa0-1d17-39632bf29ada@oracle.com/ Fixes: 4e244c10eab3 ("kconfig: remove unneeded symbol_empty variable") Reviewed-by: Petr Mladek Reviewed-by: Masahiro Yamada Signed-off-by: Yoann Congal Link: https://lore.kernel.org/r/20240505080343.1471198-2-yoann.congal@smile.fr Signed-off-by: Petr Mladek Signed-off-by: Sasha Levin commit 599001dcb6ad806a21568933812bfde6916e9923 Author: Zhu Yanjun Date: Mon May 6 09:55:38 2024 +0200 null_blk: Fix the WARNING: modpost: missing MODULE_DESCRIPTION() [ Upstream commit 9e6727f824edcdb8fdd3e6e8a0862eb49546e1cd ] No functional changes intended. Fixes: f2298c0403b0 ("null_blk: multi queue aware block test driver") Signed-off-by: Zhu Yanjun Reviewed-by: Chaitanya Kulkarni Link: https://lore.kernel.org/r/20240506075538.6064-1-yanjun.zhu@linux.dev Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit f2089037e265ba59ad4c20504470c3d13f342dfe Author: Shenghao Ding Date: Sun May 5 20:23:45 2024 +0800 ASoC: tas2781: Fix a warning reported by robot kernel test [ Upstream commit 1ae14f3520b1a0ad144610a3f592c81a3e81cd1b ] Fix a warning reported by robot kernel test that 'fw_entry' in function 'tas2781_load_calibration' is used uninitialized with compiler sh4-linux-gcc (GCC) 13.2.0, an update of copyright and a correction of the comments. Fixes: ef3bcde75d06 ("ASoc: tas2781: Add tas2781 driver") Signed-off-by: Shenghao Ding Link: https://lore.kernel.org/r/20240505122346.1326-1-shenghao-ding@ti.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 617e3d1680504a3f9d88e1582892c68be155498f Author: Konrad Dybcio Date: Fri Apr 12 10:53:25 2024 +0200 drm/msm/a6xx: Avoid a nullptr dereference when speedbin setting fails [ Upstream commit 46d4efcccc688cbacdd70a238bedca510acaa8e4 ] Calling a6xx_destroy() before adreno_gpu_init() leads to a null pointer dereference on: msm_gpu_cleanup() : platform_set_drvdata(gpu->pdev, NULL); as gpu->pdev is only assigned in: a6xx_gpu_init() |_ adreno_gpu_init |_ msm_gpu_init() Instead of relying on handwavy null checks down the cleanup chain, explicitly de-allocate the LLC data and free a6xx_gpu instead. Fixes: 76efc2453d0e ("drm/msm/gpu: Fix crash during system suspend after unbind") Signed-off-by: Konrad Dybcio Patchwork: https://patchwork.freedesktop.org/patch/588919/ Signed-off-by: Rob Clark Signed-off-by: Sasha Levin commit 80b4604d303a6350a9e85a583fddcc603fe16225 Author: Zan Dobersek Date: Tue Apr 9 14:57:00 2024 +0200 drm/msm/adreno: fix CP cycles stat retrieval on a7xx [ Upstream commit 328660262df89ab64031059909d763f7a8af9570 ] a7xx_submit() should use the a7xx variant of the RBBM_PERFCTR_CP register for retrieving the CP cycles value before and after the submitted command stream execution. Signed-off-by: Zan Dobersek Fixes: af66706accdf ("drm/msm/a6xx: Add skeleton A7xx support") Patchwork: https://patchwork.freedesktop.org/patch/588445/ Signed-off-by: Rob Clark Signed-off-by: Sasha Levin commit a393849881ce6a344956cbec8b7e3682ba4361e6 Author: Benjamin Gray Date: Wed Apr 17 21:23:17 2024 +1000 selftests/powerpc/dexcr: Add -no-pie to hashchk tests [ Upstream commit d7228a58d9438d6f219dc7f33eab0d1980b3bd2f ] The hashchk tests want to verify that the hash key is changed over exec. It does so by calculating hashes at the same address across an exec. This is made simpler by disabling PIE functionality, so we can re-execute ourselves and be using the same addresses in the child. While -fno-pie is already added, -no-pie is also required. Fixes: bdb07f35a52f ("selftests/powerpc/dexcr: Add hashst/hashchk test") Signed-off-by: Benjamin Gray Signed-off-by: Michael Ellerman Link: https://msgid.link/20240417112325.728010-2-bgray@linux.ibm.com Signed-off-by: Sasha Levin commit 3e2208cac63b73ce0b744082891cd31a96ec2e23 Author: Vijendar Mukunda Date: Thu May 2 19:33:25 2024 +0530 ASoC: amd: acp: fix for acp platform device creation failure [ Upstream commit 09068d624c490c0e89f33f963c402f1859964467 ] ACP pin configuration varies based on acp version. ACP PCI driver should read the ACP PIN config value and based on config value, it has to create a platform device in below two conditions. 1) If ACP PDM configuration is selected from BIOS and ACP PDM controller exists. 2) If ACP I2S configuration is selected from BIOS. Other than above scenarios, ACP PCI driver should skip the platform device creation logic, i.e. ACP PCI driver probe sequence should never fail if other acp pin configuration is selected. It should skip platform device creation logic. check_acp_pdm() function was implemented for ACP6.x platforms to check ACP PDM configuration. Previously, this code was safe guarded by FLAG_AMD_LEGACY_ONLY_DMIC flag check. This implementation breaks audio use cases for Huawei Matebooks which are based on ACP3.x varaint uses I2S configuration. In current scenario, check_acp_pdm() function returns -ENODEV value which results in ACP PCI driver probe failure without creating a platform device even in case of valid ACP pin configuration. Implement check_acp_config() as a common function which invokes platform specific acp pin configuration check functions for ACP3.x, ACP6.0 & ACP6.3 & ACP7.0 variants and checks for ACP PDM controller. Closes: https://bugzilla.kernel.org/show_bug.cgi?id=218780 Fixes: 4af565de9f8c ("ASoC: amd: acp: fix for acp pdm configuration check") Signed-off-by: Vijendar Mukunda Link: https://lore.kernel.org/r/20240502140340.4049021-1-Vijendar.Mukunda@amd.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 603661357056b5e5ba6d86f505fbc936eff396ba Author: Sean Anderson Date: Fri Mar 8 15:47:41 2024 -0500 drm: zynqmp_dpsub: Always register bridge [ Upstream commit be3f3042391d061cfca2bd22630e0d101acea5fc ] We must always register the DRM bridge, since zynqmp_dp_hpd_work_func calls drm_bridge_hpd_notify, which in turn expects hpd_mutex to be initialized. We do this before zynqmp_dpsub_drm_init since that calls drm_bridge_attach. This fixes the following lockdep warning: [ 19.217084] ------------[ cut here ]------------ [ 19.227530] DEBUG_LOCKS_WARN_ON(lock->magic != lock) [ 19.227768] WARNING: CPU: 0 PID: 140 at kernel/locking/mutex.c:582 __mutex_lock+0x4bc/0x550 [ 19.241696] Modules linked in: [ 19.244937] CPU: 0 PID: 140 Comm: kworker/0:4 Not tainted 6.6.20+ #96 [ 19.252046] Hardware name: xlnx,zynqmp (DT) [ 19.256421] Workqueue: events zynqmp_dp_hpd_work_func [ 19.261795] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 19.269104] pc : __mutex_lock+0x4bc/0x550 [ 19.273364] lr : __mutex_lock+0x4bc/0x550 [ 19.277592] sp : ffffffc085c5bbe0 [ 19.281066] x29: ffffffc085c5bbe0 x28: 0000000000000000 x27: ffffff88009417f8 [ 19.288624] x26: ffffff8800941788 x25: ffffff8800020008 x24: ffffffc082aa3000 [ 19.296227] x23: ffffffc080d90e3c x22: 0000000000000002 x21: 0000000000000000 [ 19.303744] x20: 0000000000000000 x19: ffffff88002f5210 x18: 0000000000000000 [ 19.311295] x17: 6c707369642e3030 x16: 3030613464662072 x15: 0720072007200720 [ 19.318922] x14: 0000000000000000 x13: 284e4f5f4e524157 x12: 0000000000000001 [ 19.326442] x11: 0001ffc085c5b940 x10: 0001ff88003f388b x9 : 0001ff88003f3888 [ 19.334003] x8 : 0001ff88003f3888 x7 : 0000000000000000 x6 : 0000000000000000 [ 19.341537] x5 : 0000000000000000 x4 : 0000000000001668 x3 : 0000000000000000 [ 19.349054] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffffff88003f3880 [ 19.356581] Call trace: [ 19.359160] __mutex_lock+0x4bc/0x550 [ 19.363032] mutex_lock_nested+0x24/0x30 [ 19.367187] drm_bridge_hpd_notify+0x2c/0x6c [ 19.371698] zynqmp_dp_hpd_work_func+0x44/0x54 [ 19.376364] process_one_work+0x3ac/0x988 [ 19.380660] worker_thread+0x398/0x694 [ 19.384736] kthread+0x1bc/0x1c0 [ 19.388241] ret_from_fork+0x10/0x20 [ 19.392031] irq event stamp: 183 [ 19.395450] hardirqs last enabled at (183): [] finish_task_switch.isra.0+0xa8/0x2d4 [ 19.405140] hardirqs last disabled at (182): [] __schedule+0x714/0xd04 [ 19.413612] softirqs last enabled at (114): [] srcu_invoke_callbacks+0x158/0x23c [ 19.423128] softirqs last disabled at (110): [] srcu_invoke_callbacks+0x158/0x23c [ 19.432614] ---[ end trace 0000000000000000 ]--- Fixes: eb2d64bfcc17 ("drm: xlnx: zynqmp_dpsub: Report HPD through the bridge") Signed-off-by: Sean Anderson Reviewed-by: Laurent Pinchart Reviewed-by: Tomi Valkeinen Signed-off-by: Tomi Valkeinen Link: https://patchwork.freedesktop.org/patch/msgid/20240308204741.3631919-1-sean.anderson@linux.dev (cherry picked from commit 61ba791c4a7a09a370c45b70a81b8c7d4cf6b2ae) Signed-off-by: Maarten Lankhorst Signed-off-by: Sasha Levin commit 6ad1ffb66846bfbdb93a127204b0bb5b1be02331 Author: Luca Ceresoli Date: Fri Apr 26 14:22:59 2024 +0200 Revert "drm/bridge: ti-sn65dsi83: Fix enable error path" [ Upstream commit ad81feb5b6f1f5461641706376dcf7a9914ed2e7 ] This reverts commit 8a91b29f1f50ce7742cdbe5cf11d17f128511f3f. The regulator_disable() added by the original commit solves one kind of regulator imbalance but adds another one as it allows the regulator to be disabled one more time than it is enabled in the following scenario: 1. Start video pipeline -> sn65dsi83_atomic_pre_enable -> regulator_enable 2. PLL lock fails -> regulator_disable 3. Stop video pipeline -> sn65dsi83_atomic_disable -> regulator_disable The reason is clear from the code flow, which looks like this (after removing unrelated code): static void sn65dsi83_atomic_pre_enable() { regulator_enable(ctx->vcc); if (PLL failed locking) { regulator_disable(ctx->vcc); <---- added by patch being reverted return; } } static void sn65dsi83_atomic_disable() { regulator_disable(ctx->vcc); } The use case for introducing the additional regulator_disable() was removing the module for debugging (see link below for the discussion). If the module is removed after a .atomic_pre_enable, i.e. with an active pipeline from the DRM point of view, .atomic_disable is not called and thus the regulator would not be disabled. According to the discussion however there is no actual use case for removing the module with an active pipeline, except for debugging/development. On the other hand, the occurrence of a PLL lock failure is possible due to any physical reason (e.g. a temporary hardware failure for electrical reasons) so handling it gracefully should be supported. As there is no way for .atomic[_pre]_enable to report an error to the core, the only clean way to support it is calling regulator_disabled() only in .atomic_disable, unconditionally, as it was before. Link: https://lore.kernel.org/all/15244220.uLZWGnKmhe@steina-w/ Fixes: 8a91b29f1f50 ("drm/bridge: ti-sn65dsi83: Fix enable error path") Reviewed-by: Alexander Stein Signed-off-by: Luca Ceresoli Signed-off-by: Robert Foss Link: https://patchwork.freedesktop.org/patch/msgid/20240426122259.46808-1-luca.ceresoli@bootlin.com (cherry picked from commit 2940ee03b23281071620dda1d790cd644dabd394) Signed-off-by: Maarten Lankhorst Signed-off-by: Sasha Levin commit f8668524522f08244a22819a5f17350399f9fc3e Author: Hans Verkuil Date: Tue Apr 30 11:13:47 2024 +0100 media: cec: core: avoid confusing "transmit timed out" message [ Upstream commit cbe499977bc36fedae89f0a0d7deb4ccde9798fe ] If, when waiting for a transmit to finish, the wait is interrupted, then you might get a "transmit timed out" message, even though the transmit was interrupted and did not actually time out. Set transmit_in_progress_aborted to true if the wait_for_completion_killable() call was interrupted and ensure that the transmit is properly marked as ABORTED. Signed-off-by: Hans Verkuil Reported-by: Yang, Chenyuan Closes: https://lore.kernel.org/linux-media/PH7PR11MB57688E64ADE4FE82E658D86DA09EA@PH7PR11MB5768.namprd11.prod.outlook.com/ Fixes: 590a8e564c6e ("media: cec: abort if the current transmit was canceled") Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit f817bb3d8ca3596e84d179be3bec2ce3e2f09ddc Author: Hans Verkuil Date: Thu Feb 22 16:17:33 2024 +0000 media: cec: core: avoid recursive cec_claim_log_addrs [ Upstream commit 47c82aac10a6954d68f29f10d9758d016e8e5af1 ] Keep track if cec_claim_log_addrs() is running, and return -EBUSY if it is when calling CEC_ADAP_S_LOG_ADDRS. This prevents a case where cec_claim_log_addrs() could be called while it was still in progress. Signed-off-by: Hans Verkuil Reported-by: Yang, Chenyuan Closes: https://lore.kernel.org/linux-media/PH7PR11MB57688E64ADE4FE82E658D86DA09EA@PH7PR11MB5768.namprd11.prod.outlook.com/ Fixes: ca684386e6e2 ("[media] cec: add HDMI CEC framework (api)") Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 08ec03dec7070502b97aaa9703074a2d3985d34e Author: Hans Verkuil Date: Fri Feb 23 12:25:55 2024 +0000 media: cec: cec-api: add locking in cec_release() [ Upstream commit 42bcaacae924bf18ae387c3f78c202df0b739292 ] When cec_release() uses fh->msgs it has to take fh->lock, otherwise the list can get corrupted. Signed-off-by: Hans Verkuil Reported-by: Yang, Chenyuan Closes: https://lore.kernel.org/linux-media/PH7PR11MB57688E64ADE4FE82E658D86DA09EA@PH7PR11MB5768.namprd11.prod.outlook.com/ Fixes: ca684386e6e2 ("[media] cec: add HDMI CEC framework (api)") Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit cd5943a68143c6e34c93d1179bfbfb06280376a6 Author: Hans Verkuil Date: Fri Feb 23 12:24:38 2024 +0000 media: cec: cec-adap: always cancel work in cec_transmit_msg_fh [ Upstream commit 9fe2816816a3c765dff3b88af5b5c3d9bbb911ce ] Do not check for !data->completed, just always call cancel_delayed_work_sync(). This fixes a small race condition. Signed-off-by: Hans Verkuil Reported-by: Yang, Chenyuan Closes: https://lore.kernel.org/linux-media/PH7PR11MB57688E64ADE4FE82E658D86DA09EA@PH7PR11MB5768.namprd11.prod.outlook.com/ Fixes: 490d84f6d73c ("media: cec: forgot to cancel delayed work") Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit bbc2ba6a39b13192c29c983e719daf545ea56960 Author: Randy Dunlap Date: Wed Sep 27 05:04:38 2023 +0100 media: sunxi: a83-mips-csi2: also select GENERIC_PHY [ Upstream commit 8237026159cb6760ad22e28d57b9a1c53b612d3a ] When selecting GENERIC_PHY_MIPI_DPHY, also select GENERIC_PHY to prevent kconfig warnings: WARNING: unmet direct dependencies detected for GENERIC_PHY_MIPI_DPHY Depends on [n]: GENERIC_PHY [=n] Selected by [y]: - VIDEO_SUN8I_A83T_MIPI_CSI2 [=y] && MEDIA_SUPPORT [=y] && MEDIA_PLATFORM_SUPPORT [=y] && MEDIA_PLATFORM_DRIVERS [=y] && V4L_PLATFORM_DRIVERS [=y] && VIDEO_DEV [=y] && (ARCH_SUNXI || COMPILE_TEST [=y]) && PM [=y] && COMMON_CLK [=y] && RESET_CONTROLLER [=y] Fixes: 94d7fd9692b5 ("media: sunxi: Depend on GENERIC_PHY_MIPI_DPHY") Reported-by: kernel test robot Closes: https://lore.kernel.org/r/ZQ/WS8HC1A3F0Qn8@rli9-mobl Link: https://lore.kernel.org/linux-media/20230927040438.5589-1-rdunlap@infradead.org Signed-off-by: Randy Dunlap Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit eef8d414b07a1e85c1367324fb6c6a46b79269bd Author: Li Zhijian Date: Sun Apr 28 11:07:48 2024 +0800 cxl/region: Fix cxlr_pmem leaks [ Upstream commit 1c987cf22d6b65ade46145c03eef13f0e3e81d83 ] Before this error path, cxlr_pmem pointed to a kzalloc() memory, free it to avoid this memory leaking. Fixes: f17b558d6663 ("cxl/pmem: Refactor nvdimm device registration, delete the workqueue") Signed-off-by: Li Zhijian Reviewed-by: Dan Williams Reviewed-by: Jonathan Cameron Link: https://lore.kernel.org/r/20240428030748.318985-1-lizhijian@fujitsu.com Signed-off-by: Dave Jiang Signed-off-by: Sasha Levin commit d54aaeb1cb1e7e9f46a6c23c3fb230f6f9709bef Author: Alison Schofield Date: Tue Apr 30 10:28:03 2024 -0700 cxl/trace: Correct DPA field masks for general_media & dram events [ Upstream commit 2042d11cb57b7e0cbda7910e5ff80e9e8bf0ae17 ] The length of Physical Address in General Media and DRAM event records is 64-bit, so the field mask for extracting the DPA should be 64-bit also, otherwise the trace event reports DPA's with the upper 32 bits of a DPA address masked off. If users do DPA-to-HPA translations this could lead to incorrect page retirement decisions. Use GENMASK_ULL() for CXL_DPA_MASK to get all the DPA address bits. Tidy up CXL_DPA_FLAGS_MASK by using GENMASK() to only mask the exact flag bits. These bits are defined as part of the event record physical address descriptions of General Media and DRAM events in CXL Spec 3.1 Section 8.2.9.2 Events. Fixes: d54a531a430b ("cxl/mem: Trace General Media Event Record") Co-developed-by: Shiyang Ruan Signed-off-by: Shiyang Ruan Signed-off-by: Alison Schofield Reviewed-by: Ira Weiny Reviewed-by: Jonathan Cameron Link: https://lore.kernel.org/r/2867fc43c57720a4a15a3179431829b8dbd2dc16.1714496730.git.alison.schofield@intel.com Signed-off-by: Dave Jiang Signed-off-by: Sasha Levin commit f2a7fcba1af73936215a071a845fb6b9284fa06d Author: Tiwei Bie Date: Tue Apr 23 20:58:55 2024 +0800 um: Fix the declaration of kasan_map_memory [ Upstream commit 6a85e34c4d07d2ec0c153067baff338ac0db55ca ] Make it match its definition (size_t vs unsigned long). And declare it in a shared header to fix the -Wmissing-prototypes warning, as it is defined in the user code and called in the kernel code. Fixes: 5b301409e8bc ("UML: add support for KASAN under x86_64") Signed-off-by: Tiwei Bie Signed-off-by: Richard Weinberger Signed-off-by: Sasha Levin commit f51fc9dff2eebdc67ef1c5e3f2020a9b8649866c Author: Tiwei Bie Date: Tue Apr 23 20:58:54 2024 +0800 um: Fix the -Wmissing-prototypes warning for get_thread_reg [ Upstream commit 3144013e48f4f6e5127223c4ebc488016815dedb ] The get_thread_reg function is defined in the user code, and is called by the kernel code. It should be declared in a shared header. Fixes: dbba7f704aa0 ("um: stop polluting the namespace with registers.h contents") Signed-off-by: Tiwei Bie Signed-off-by: Richard Weinberger Signed-off-by: Sasha Levin commit 13b659211f730bb8fbc99225066a8392e3f4219b Author: Tiwei Bie Date: Tue Apr 23 20:58:53 2024 +0800 um: Fix the -Wmissing-prototypes warning for __switch_mm [ Upstream commit 2cbade17b18c0f0fd9963f26c9fc9b057eb1cb3a ] The __switch_mm function is defined in the user code, and is called by the kernel code. It should be declared in a shared header. Fixes: 4dc706c2f292 ("um: take um_mmu.h to asm/mmu.h, clean asm/mmu_context.h a bit") Signed-off-by: Tiwei Bie Signed-off-by: Richard Weinberger Signed-off-by: Sasha Levin commit 5bfa4e8fc85a000b3fa4eb08c1618a042c938c68 Author: Peter Ujfalusi Date: Fri Apr 26 10:38:58 2024 -0500 ASoC: SOF: debug: Handle cases when fw_lib_prefix is not set, NULL [ Upstream commit b32487ca7b51ce430f15ec785269f11c25a6a560 ] The firmware libraries are not supported by IPC3, the fw_lib_path is not a valid parameter and it is always NULL. Do not create the debugfs file for IPC3 at all as it is not applicable. With IPC4 some vendors/platforms might not support loadable libraries and the fw_lib_prefix is left to NULL to indicate this. Handle such case with allocating "Not supported" string. Reviewed-by: Marc Herbert Fixes: 17f4041244e6 ("ASoC: SOF: debug: show firmware/topology prefix/names") Signed-off-by: Peter Ujfalusi Signed-off-by: Pierre-Louis Bossart Link: https://lore.kernel.org/r/20240426153902.39560-2-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 9d8dec43895b86a5148ec3c68bd2a49dc59e10bd Author: Shrikanth Hegde Date: Fri Apr 12 14:50:47 2024 +0530 powerpc/pseries: Add failure related checks for h_get_mpp and h_get_ppp [ Upstream commit 6d4341638516bf97b9a34947e0bd95035a8230a5 ] Couple of Minor fixes: - hcall return values are long. Fix that for h_get_mpp, h_get_ppp and parse_ppp_data - If hcall fails, values set should be at-least zero. It shouldn't be uninitialized values. Fix that for h_get_mpp and h_get_ppp Signed-off-by: Shrikanth Hegde Signed-off-by: Michael Ellerman Link: https://msgid.link/20240412092047.455483-3-sshegde@linux.ibm.com Signed-off-by: Sasha Levin commit ec50b5ad169b1bde447fe4a3c8c652828ead8cf3 Author: Dongliang Mu Date: Thu Jun 2 06:50:24 2022 +0100 media: flexcop-usb: fix sanity check of bNumEndpoints [ Upstream commit f62dc8f6bf82d1b307fc37d8d22cc79f67856c2f ] Commit d725d20e81c2 ("media: flexcop-usb: sanity checking of endpoint type ") adds a sanity check for endpoint[1], but fails to modify the sanity check of bNumEndpoints. Fix this by modifying the sanity check of bNumEndpoints to 2. Link: https://lore.kernel.org/linux-media/20220602055027.849014-1-dzm91@hust.edu.cn Fixes: d725d20e81c2 ("media: flexcop-usb: sanity checking of endpoint type") Signed-off-by: Dongliang Mu Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 40d47c2e843848f5228534d870b5146d5bf9fc13 Author: Hans de Goede Date: Wed Apr 24 14:28:11 2024 +0200 platform/x86: thinkpad_acpi: Take hotkey_mutex during hotkey_exit() [ Upstream commit e397c564298c2e91aea3887990da8e8eddb65277 ] hotkey_exit() already takes the mutex around the hotkey_poll_stop_sync() call, but not around the other calls. commit 38831eaf7d4c ("platform/x86: thinkpad_acpi: use lockdep annotations") has added lockdep_assert_held() checks to various hotkey functions. These lockdep_assert_held() checks fail causing WARN() backtraces in dmesg due to missing locking in hotkey_exit(), fix this. Fixes: 38831eaf7d4c ("platform/x86: thinkpad_acpi: use lockdep annotations") Tested-by: Mark Pearson Signed-off-by: Hans de Goede Reviewed-by: Mark Pearson Reviewed-by: Ilpo Järvinen Link: https://lore.kernel.org/r/20240424122834.19801-2-hdegoede@redhat.com Signed-off-by: Sasha Levin commit 76538a32eaf130d0ae94cbdb38ba07654013ffdb Author: David E. Box Date: Wed Apr 10 19:58:54 2024 -0700 tools/arch/x86/intel_sdsi: Fix meter_certificate decoding [ Upstream commit 09d70ded6c566fd00886be32c26d0b2004ef239c ] Fix errors in the calculation of the start position of the counters and in the display loop. While here, use a #define for the bundle count and size. Fixes: 7fdc03a7370f ("tools/arch/x86: intel_sdsi: Add support for reading meter certificates") Signed-off-by: David E. Box Reviewed-by: Kuppuswamy Sathyanarayanan Reviewed-by: Ilpo Järvinen Link: https://lore.kernel.org/r/20240411025856.2782476-8-david.e.box@linux.intel.com Signed-off-by: Hans de Goede Signed-off-by: Sasha Levin commit 0eabae256243c66d1c51f5dbadfa741b4aaa9eee Author: David E. Box Date: Wed Apr 10 19:58:53 2024 -0700 tools/arch/x86/intel_sdsi: Fix meter_show display [ Upstream commit 76f2bc17428c890754d11aa6aea14b332ba130c5 ] Fixes sdsi_meter_cert_show() to correctly decode and display the meter certificate output. Adds and displays a missing version field, displays the ASCII name of the signature, and fixes the print alignment. Fixes: 7fdc03a7370f ("tools/arch/x86: intel_sdsi: Add support for reading meter certificates") Signed-off-by: David E. Box Reviewed-by: Kuppuswamy Sathyanarayanan Reviewed-by: Ilpo Järvinen Link: https://lore.kernel.org/r/20240411025856.2782476-7-david.e.box@linux.intel.com Signed-off-by: Hans de Goede Signed-off-by: Sasha Levin commit c43c212be0f6ff3c026c98969c6c2cad7bfe4af3 Author: David E. Box Date: Wed Apr 10 19:58:52 2024 -0700 tools/arch/x86/intel_sdsi: Fix maximum meter bundle length [ Upstream commit a66f962f67ebbbdf7c82c6652180930c0169cf13 ] The maximum number of bundles in the meter certificate was set to 8 which is much less than the maximum. Instead, since the bundles appear at the end of the file, set it based on the remaining file size from the bundle start position. Fixes: 7fdc03a7370f ("tools/arch/x86: intel_sdsi: Add support for reading meter certificates") Signed-off-by: David E. Box Reviewed-by: Ilpo Järvinen Link: https://lore.kernel.org/r/20240411025856.2782476-6-david.e.box@linux.intel.com Signed-off-by: Hans de Goede Signed-off-by: Sasha Levin commit 56c5f1b7f09d8ef8f0e46adb9125bf95505824bc Author: Eugen Hristev Date: Thu Dec 28 13:32:40 2023 +0200 media: mediatek: vcodec: fix possible unbalanced PM counter [ Upstream commit c28d4921a1e3ce0a0374b7e9d68593be8802c42a ] It is possible that mtk_vcodec_enc_pw_on fails, and in that scenario the PM counter is not incremented, and subsequent call to mtk_vcodec_enc_pw_off decrements the counter, leading to a PM imbalance. Fix by bailing out of venc_if_encode in the case when mtk_vcodec_enc_pw_on fails. Fixes: 4e855a6efa54 ("[media] vcodec: mediatek: Add Mediatek V4L2 Video Encoder Driver") Signed-off-by: Eugen Hristev Reviewed-by: AngeloGioacchino Del Regno Signed-off-by: Andrzej Pietrasiewicz Signed-off-by: Sebastian Fricke Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit f1b6a016dfa45cedc080d36fa5d6f22237d80e8b Author: Srinivasan Shanmugam Date: Thu Apr 25 11:22:32 2024 +0530 drm/amdgpu: Fix buffer size in gfx_v9_4_3_init_ cp_compute_microcode() and rlc_microcode() [ Upstream commit acce6479e30f73ab0872e93a75aed1fb791d04ec ] The function gfx_v9_4_3_init_microcode in gfx_v9_4_3.c was generating about potential truncation of output when using the snprintf function. The issue was due to the size of the buffer 'ucode_prefix' being too small to accommodate the maximum possible length of the string being written into it. The string being written is "amdgpu/%s_mec.bin" or "amdgpu/%s_rlc.bin", where %s is replaced by the value of 'chip_name'. The length of this string without the %s is 16 characters. The warning message indicated that 'chip_name' could be up to 29 characters long, resulting in a total of 45 characters, which exceeds the buffer size of 30 characters. To resolve this issue, the size of the 'ucode_prefix' buffer has been reduced from 30 to 15. This ensures that the maximum possible length of the string being written into the buffer will not exceed its size, thus preventing potential buffer overflow and truncation issues. Fixes the below with gcc W=1: drivers/gpu/drm/amd/amdgpu/gfx_v9_4_3.c: In function ‘gfx_v9_4_3_early_init’: drivers/gpu/drm/amd/amdgpu/gfx_v9_4_3.c:379:52: warning: ‘%s’ directive output may be truncated writing up to 29 bytes into a region of size 23 [-Wformat-truncation=] 379 | snprintf(fw_name, sizeof(fw_name), "amdgpu/%s_rlc.bin", chip_name); | ^~ ...... 439 | r = gfx_v9_4_3_init_rlc_microcode(adev, ucode_prefix); | ~~~~~~~~~~~~ drivers/gpu/drm/amd/amdgpu/gfx_v9_4_3.c:379:9: note: ‘snprintf’ output between 16 and 45 bytes into a destination of size 30 379 | snprintf(fw_name, sizeof(fw_name), "amdgpu/%s_rlc.bin", chip_name); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ drivers/gpu/drm/amd/amdgpu/gfx_v9_4_3.c:413:52: warning: ‘%s’ directive output may be truncated writing up to 29 bytes into a region of size 23 [-Wformat-truncation=] 413 | snprintf(fw_name, sizeof(fw_name), "amdgpu/%s_mec.bin", chip_name); | ^~ ...... 443 | r = gfx_v9_4_3_init_cp_compute_microcode(adev, ucode_prefix); | ~~~~~~~~~~~~ drivers/gpu/drm/amd/amdgpu/gfx_v9_4_3.c:413:9: note: ‘snprintf’ output between 16 and 45 bytes into a destination of size 30 413 | snprintf(fw_name, sizeof(fw_name), "amdgpu/%s_mec.bin", chip_name); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Fixes: 86301129698b ("drm/amdgpu: split gc v9_4_3 functionality from gc v9_0") Cc: Hawking Zhang Cc: Christian König Cc: Alex Deucher Cc: Lijo Lazar Signed-off-by: Srinivasan Shanmugam Suggested-by: Lijo Lazar Reviewed-by: Lijo Lazar Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 6175e4442e8c620ced69167fab003e7ff55303bd Author: Le Ma Date: Wed Apr 17 17:57:52 2024 +0800 drm/amdgpu: init microcode chip name from ip versions [ Upstream commit 92ed1e9cd5f6cc4f8c9a9ba6c4d2d2bbc6221296 ] To adapt to different gc versions in gfx_v9_4_3.c file. Signed-off-by: Le Ma Reviewed-by: Hawking Zhang Reviewed-by: Lijo Lazar Signed-off-by: Alex Deucher Stable-dep-of: acce6479e30f ("drm/amdgpu: Fix buffer size in gfx_v9_4_3_init_ cp_compute_microcode() and rlc_microcode()") Signed-off-by: Sasha Levin commit a5fc298fa8f67cf1f0e1fc126eab70578cd40adc Author: Marek Szyprowski Date: Mon Oct 9 14:10:18 2023 +0200 Input: cyapa - add missing input core locking to suspend/resume functions [ Upstream commit 7b4e0b39182cf5e677c1fc092a3ec40e621c25b6 ] Grab input->mutex during suspend/resume functions like it is done in other input drivers. This fixes the following warning during system suspend/resume cycle on Samsung Exynos5250-based Snow Chromebook: ------------[ cut here ]------------ WARNING: CPU: 1 PID: 1680 at drivers/input/input.c:2291 input_device_enabled+0x68/0x6c Modules linked in: ... CPU: 1 PID: 1680 Comm: kworker/u4:12 Tainted: G W 6.6.0-rc5-next-20231009 #14109 Hardware name: Samsung Exynos (Flattened Device Tree) Workqueue: events_unbound async_run_entry_fn unwind_backtrace from show_stack+0x10/0x14 show_stack from dump_stack_lvl+0x58/0x70 dump_stack_lvl from __warn+0x1a8/0x1cc __warn from warn_slowpath_fmt+0x18c/0x1b4 warn_slowpath_fmt from input_device_enabled+0x68/0x6c input_device_enabled from cyapa_gen3_set_power_mode+0x13c/0x1dc cyapa_gen3_set_power_mode from cyapa_reinitialize+0x10c/0x15c cyapa_reinitialize from cyapa_resume+0x48/0x98 cyapa_resume from dpm_run_callback+0x90/0x298 dpm_run_callback from device_resume+0xb4/0x258 device_resume from async_resume+0x20/0x64 async_resume from async_run_entry_fn+0x40/0x15c async_run_entry_fn from process_scheduled_works+0xbc/0x6a8 process_scheduled_works from worker_thread+0x188/0x454 worker_thread from kthread+0x108/0x140 kthread from ret_from_fork+0x14/0x28 Exception stack(0xf1625fb0 to 0xf1625ff8) ... ---[ end trace 0000000000000000 ]--- ... ------------[ cut here ]------------ WARNING: CPU: 1 PID: 1680 at drivers/input/input.c:2291 input_device_enabled+0x68/0x6c Modules linked in: ... CPU: 1 PID: 1680 Comm: kworker/u4:12 Tainted: G W 6.6.0-rc5-next-20231009 #14109 Hardware name: Samsung Exynos (Flattened Device Tree) Workqueue: events_unbound async_run_entry_fn unwind_backtrace from show_stack+0x10/0x14 show_stack from dump_stack_lvl+0x58/0x70 dump_stack_lvl from __warn+0x1a8/0x1cc __warn from warn_slowpath_fmt+0x18c/0x1b4 warn_slowpath_fmt from input_device_enabled+0x68/0x6c input_device_enabled from cyapa_gen3_set_power_mode+0x13c/0x1dc cyapa_gen3_set_power_mode from cyapa_reinitialize+0x10c/0x15c cyapa_reinitialize from cyapa_resume+0x48/0x98 cyapa_resume from dpm_run_callback+0x90/0x298 dpm_run_callback from device_resume+0xb4/0x258 device_resume from async_resume+0x20/0x64 async_resume from async_run_entry_fn+0x40/0x15c async_run_entry_fn from process_scheduled_works+0xbc/0x6a8 process_scheduled_works from worker_thread+0x188/0x454 worker_thread from kthread+0x108/0x140 kthread from ret_from_fork+0x14/0x28 Exception stack(0xf1625fb0 to 0xf1625ff8) ... ---[ end trace 0000000000000000 ]--- Fixes: d69f0a43c677 ("Input: use input_device_enabled()") Signed-off-by: Marek Szyprowski Reviewed-by: Andrzej Pietrasiewicz Link: https://lore.kernel.org/r/20231009121018.1075318-1-m.szyprowski@samsung.com Signed-off-by: Dmitry Torokhov Signed-off-by: Sasha Levin commit 88cf16aba1322b04127078d479b2ad39033def92 Author: Kees Cook Date: Fri Apr 19 07:01:52 2024 -0700 string: Prepare to merge strcat KUnit tests into string_kunit.c [ Upstream commit 6e4ef1429f3be236e145c6115b539acdbd2e299c ] The test naming convention differs between string_kunit.c and strcat_kunit.c. Move "test" to the beginning of the function name. Reviewed-by: Andy Shevchenko Tested-by: Ivan Orlov Link: https://lore.kernel.org/r/20240419140155.3028912-3-keescook@chromium.org Signed-off-by: Kees Cook Stable-dep-of: 5bb288c4abc2 ("scsi: mptfusion: Avoid possible run-time warning with long manufacturer strings") Signed-off-by: Sasha Levin commit 0a9f90dcbb5cc0fa3a8e758368c09915387dc7d8 Author: Kees Cook Date: Fri Apr 19 07:01:50 2024 -0700 string: Prepare to merge strscpy_kunit.c into string_kunit.c [ Upstream commit b03442f761aae4bbb093a281ad2205bc346188f5 ] In preparation for moving the strscpy_kunit.c tests into string_kunit.c, rename "tc" to "strscpy_check" for better readability. Reviewed-by: Andy Shevchenko Tested-by: Ivan Orlov Link: https://lore.kernel.org/r/20240419140155.3028912-1-keescook@chromium.org Signed-off-by: Kees Cook Stable-dep-of: 5bb288c4abc2 ("scsi: mptfusion: Avoid possible run-time warning with long manufacturer strings") Signed-off-by: Sasha Levin commit 5570ca9719decb00bfbb815005ce9cc18c5900f8 Author: Ivan Orlov Date: Thu Apr 18 00:30:33 2024 +0100 string_kunit: Add test cases for str*cmp functions [ Upstream commit 9259a4721699947ceb397037991c0e4acc496b21 ] Currently, str*cmp functions (strcmp, strncmp, strcasecmp and strncasecmp) are not covered with tests. Extend the `string_kunit.c` test by adding the test cases for them. This patch adds 8 more test cases: 1) strcmp test 2) strcmp test on long strings (2048 chars) 3) strncmp test 4) strncmp test on long strings (2048 chars) 5) strcasecmp test 6) strcasecmp test on long strings 7) strncasecmp test 8) strncasecmp test on long strings These test cases aim at covering as many edge cases as possible, including the tests on empty strings, situations when the different symbol is placed at the end of one of the strings, etc. Signed-off-by: Ivan Orlov Reviewed-by: Andy Shevchenko Link: https://lore.kernel.org/r/20240417233033.717596-1-ivan.orlov0322@gmail.com Signed-off-by: Kees Cook Stable-dep-of: 5bb288c4abc2 ("scsi: mptfusion: Avoid possible run-time warning with long manufacturer strings") Signed-off-by: Sasha Levin commit 850f4a965229f226e687efc2efd776da1e97492b Author: Adam Ford Date: Mon Apr 22 05:33:52 2024 -0500 drm/bridge: imx: Fix unmet depenency for PHY_FSL_SAMSUNG_HDMI_PHY [ Upstream commit cbdbd9ca718e6efbc77b97ddf0b19b0cd46ac36c ] When enabling i.MX8MP DWC HDMI driver, it automatically selects PHY_FSL_SAMSUNG_HDMI_PHY, since it wont' work without the phy. This may cause some Kconfig warnings during various build tests. Fix this by implying the phy instead of selecting the phy. To prevent this from happening with the DRM_IMX8MP_HDMI_PVI, also imply it instead of selecting it. Fixes: 1f36d634670d ("drm/bridge: imx: add bridge wrapper driver for i.MX8MP DWC HDMI") Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202404190103.lLm8LtuP-lkp@intel.com/ Signed-off-by: Adam Ford Reviewed-by: Laurent Pinchart Signed-off-by: Robert Foss Link: https://patchwork.freedesktop.org/patch/msgid/20240422103352.8886-1-aford173@gmail.com Signed-off-by: Sasha Levin commit b9cbe1c8911e754af6f84dd7dd47e248d8ba7a53 Author: Maxime Ripard Date: Wed Mar 27 11:57:02 2024 +0100 drm: Make drivers depends on DRM_DW_HDMI [ Upstream commit c0e0f139354c01e0213204e4a96e7076e5a3e396 ] DRM_DW_HDMI has a number of dependencies that might not be enabled. However, drivers were used to selecting it while not enforcing the DRM_DW_HDMI dependencies. This could result in Kconfig warnings (and further build breakages) such as: Kconfig warnings: (for reference only) WARNING: unmet direct dependencies detected for DRM_DW_HDMI Depends on [n]: HAS_IOMEM [=y] && DRM [=m] && DRM_BRIDGE [=y] && DRM_DISPLAY_HELPER [=n] Selected by [m]: - DRM_SUN8I_DW_HDMI [=m] && HAS_IOMEM [=y] && DRM_SUN4I [=m] Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202403262127.kZkttfNz-lkp@intel.com/ Acked-by: Jani Nikula Link: https://lore.kernel.org/r/20240327-kms-kconfig-helpers-v3-7-eafee11b84b3@kernel.org Signed-off-by: Maxime Ripard Stable-dep-of: cbdbd9ca718e ("drm/bridge: imx: Fix unmet depenency for PHY_FSL_SAMSUNG_HDMI_PHY") Signed-off-by: Sasha Levin commit a08492832cc4cacc24e0612f483c86ca899b9261 Author: Dan Carpenter Date: Mon Apr 22 12:32:44 2024 +0300 media: stk1160: fix bounds checking in stk1160_copy_video() [ Upstream commit faa4364bef2ec0060de381ff028d1d836600a381 ] The subtract in this condition is reversed. The ->length is the length of the buffer. The ->bytesused is how many bytes we have copied thus far. When the condition is reversed that means the result of the subtraction is always negative but since it's unsigned then the result is a very high positive value. That means the overflow check is never true. Additionally, the ->bytesused doesn't actually work for this purpose because we're not writing to "buf->mem + buf->bytesused". Instead, the math to calculate the destination where we are writing is a bit involved. You calculate the number of full lines already written, multiply by two, skip a line if necessary so that we start on an odd numbered line, and add the offset into the line. To fix this buffer overflow, just take the actual destination where we are writing, if the offset is already out of bounds print an error and return. Otherwise, write up to buf->length bytes. Fixes: 9cb2173e6ea8 ("[media] media: Add stk1160 new driver (easycap replacement)") Signed-off-by: Dan Carpenter Reviewed-by: Ricardo Ribalda Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 9a4a5d7b513c596749ee6ec4eebba78a53fa2bdc Author: Michael Walle Date: Sun Feb 25 08:19:33 2024 +0200 drm/bridge: tc358775: fix support for jeida-18 and jeida-24 [ Upstream commit 30ea09a182cb37c4921b9d477ed18107befe6d78 ] The bridge always uses 24bpp internally. Therefore, for jeida-18 mapping we need to discard the lowest two bits for each channel and thus starting with LV_[RGB]2. jeida-24 has the same mapping but uses four lanes instead of three, with the forth pair transmitting the lowest two bits of each channel. Thus, the mapping between jeida-18 and jeida-24 is actually the same, except that one channel is turned off (by selecting the RGB666 format in VPCTRL). While at it, remove the bogus comment about the hardware default because the default is overwritten in any case. Tested with a jeida-18 display (Evervision VGG644804). Fixes: b26975593b17 ("display/drm/bridge: TC358775 DSI/LVDS driver") Signed-off-by: Michael Walle Signed-off-by: Tony Lindgren Reviewed-by: Robert Foss Signed-off-by: Robert Foss Link: https://patchwork.freedesktop.org/patch/msgid/20240225062008.33191-5-tony@atomide.com Signed-off-by: Sasha Levin commit 9078630ed7f8f25d65d11823e7f2b11a8e2f4f0f Author: Aleksandr Mishin Date: Mon Apr 8 11:55:23 2024 +0300 drm/msm/dpu: Add callback function pointer check before its call [ Upstream commit 530f272053a5e72243a9cb07bb1296af6c346002 ] In dpu_core_irq_callback_handler() callback function pointer is compared to NULL, but then callback function is unconditionally called by this pointer. Fix this bug by adding conditional return. Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: c929ac60b3ed ("drm/msm/dpu: allow just single IRQ callback") Signed-off-by: Aleksandr Mishin Reviewed-by: Dmitry Baryshkov Patchwork: https://patchwork.freedesktop.org/patch/588237/ Link: https://lore.kernel.org/r/20240408085523.12231-1-amishin@t-argos.ru Signed-off-by: Dmitry Baryshkov Signed-off-by: Sasha Levin commit cceef44b34819c24bb6ed70dce5b524bd3e368d1 Author: Konstantin Komarov Date: Tue Apr 16 09:43:58 2024 +0300 fs/ntfs3: Use variable length array instead of fixed size [ Upstream commit 1997cdc3e727526aa5d84b32f7cbb3f56459b7ef ] Should fix smatch warning: ntfs_set_label() error: __builtin_memcpy() 'uni->name' too small (20 vs 256) Fixes: 4534a70b7056f ("fs/ntfs3: Add headers and misc files") Reported-by: kernel test robot Reported-by: Dan Carpenter Closes: https://lore.kernel.org/r/202401091421.3RJ24Mn3-lkp@intel.com/ Signed-off-by: Konstantin Komarov Signed-off-by: Sasha Levin commit 847db4049f6189427ddaefcfc967d4d235b73c57 Author: Konstantin Komarov Date: Tue Apr 16 09:45:09 2024 +0300 fs/ntfs3: Use 64 bit variable to avoid 32 bit overflow [ Upstream commit e931f6b630ffb22d66caab202a52aa8cbb10c649 ] For example, in the expression: vbo = 2 * vbo + skip Fixes: b46acd6a6a627 ("fs/ntfs3: Add NTFS journal") Signed-off-by: Konstantin Komarov Signed-off-by: Sasha Levin commit ff1068929459347f9e47f8d14c409dcf938c2641 Author: Konstantin Komarov Date: Tue Apr 16 09:54:34 2024 +0300 fs/ntfs3: Check 'folio' pointer for NULL [ Upstream commit 1cd6c96219c429ebcfa8e79a865277376c563803 ] It can be NULL if bmap is called. Fixes: 82cae269cfa95 ("fs/ntfs3: Add initialization of super block") Signed-off-by: Konstantin Komarov Signed-off-by: Sasha Levin commit 742c2187b9875b27cf1514390391a245a64b06df Author: Johannes Berg Date: Thu Mar 28 10:06:36 2024 +0100 um: vector: fix bpfflash parameter evaluation [ Upstream commit 584ed2f76ff5fe360d87a04d17b6520c7999e06b ] With W=1 the build complains about a pointer compared to zero, clearly the result should've been compared. Fixes: 9807019a62dc ("um: Loadable BPF "Firmware" for vector drivers") Signed-off-by: Johannes Berg Reviewed-by: Tiwei Bie Signed-off-by: Richard Weinberger Signed-off-by: Sasha Levin commit 73b8e21f76c7dda4905655d2e2c17dc5a73b87f1 Author: Roberto Sassu Date: Thu Mar 7 11:49:26 2024 +0100 um: Add winch to winch_handlers before registering winch IRQ [ Upstream commit a0fbbd36c156b9f7b2276871d499c9943dfe5101 ] Registering a winch IRQ is racy, an interrupt may occur before the winch is added to the winch_handlers list. If that happens, register_winch_irq() adds to that list a winch that is scheduled to be (or has already been) freed, causing a panic later in winch_cleanup(). Avoid the race by adding the winch to the winch_handlers list before registering the IRQ, and rolling back if um_request_irq() fails. Fixes: 42a359e31a0e ("uml: SIGIO support cleanup") Signed-off-by: Roberto Sassu Reviewed-by: Johannes Berg Signed-off-by: Richard Weinberger Signed-off-by: Sasha Levin commit e1c261ca708584f57ca816c2dd58783fef2b3c02 Author: Duoming Zhou Date: Wed Mar 6 17:12:59 2024 +0800 um: Fix return value in ubd_init() [ Upstream commit 31a5990ed253a66712d7ddc29c92d297a991fdf2 ] When kmalloc_array() fails to allocate memory, the ubd_init() should return -ENOMEM instead of -1. So, fix it. Fixes: f88f0bdfc32f ("um: UBD Improvements") Signed-off-by: Duoming Zhou Reviewed-by: Johannes Berg Signed-off-by: Richard Weinberger Signed-off-by: Sasha Levin commit 25b4c66e38c74428bb02aacc3b9d8b467265ba2b Author: Neil Armstrong Date: Wed Apr 3 09:46:35 2024 +0200 drm/meson: gate px_clk when setting rate [ Upstream commit 5c9837374ecf55a1fa3b7622d365a0456960270f ] Disable the px_clk when setting the rate to recover a fully configured and correctly reset VCLK clock tree after the rate is set. Fixes: 77d9e1e6b846 ("drm/meson: add support for MIPI-DSI transceiver") Reviewed-by: Nicolas Belin Link: https://lore.kernel.org/r/20240403-amlogic-v6-4-upstream-dsi-ccf-vim3-v12-4-99ecdfdc87fc@linaro.org Signed-off-by: Neil Armstrong Link: https://patchwork.freedesktop.org/patch/msgid/20240403-amlogic-v6-4-upstream-dsi-ccf-vim3-v12-4-99ecdfdc87fc@linaro.org Signed-off-by: Sasha Levin commit a144007f40b96559fc7abf81d21cb5e4b9d457bd Author: Wojciech Macek Date: Wed Apr 17 10:38:19 2024 +0000 drm/mediatek: dp: Fix mtk_dp_aux_transfer return value [ Upstream commit 8431fff9e0f3fc1c5844cf99a73b49b63ceed481 ] In case there is no DP device attached to the port the transfer function should return IO error, similar to what other drivers do. In case EAGAIN is returned then any read from /dev/drm_dp_aux device ends up in an infinite loop as the upper layers constantly repeats the transfer request. Fixes: f70ac097a2cf ("drm/mediatek: Add MT8195 Embedded DisplayPort driver") Signed-off-by: Wojciech Macek Reviewed-by: AngeloGioacchino Del Regno Reviewed-by: CK Hu Link: https://patchwork.kernel.org/project/dri-devel/patch/20240417103819.990512-1-wmacek@chromium.org/ Signed-off-by: Chun-Kuang Hu Signed-off-by: Sasha Levin commit 57692bf821e6e41926d48ce9409df419fd5c8d98 Author: Marijn Suijten Date: Wed Apr 17 01:57:44 2024 +0200 drm/msm/dpu: Allow configuring multiple active DSC blocks [ Upstream commit ca97fa419dfe62a384fdea8b33553c4d6afe034e ] Just like the active interface and writeback block in ctl_intf_cfg_v1(), and later the rest of the blocks in followup active-CTL fixes or reworks, multiple calls to this function should enable additional DSC blocks instead of overwriting the blocks that are enabled. This pattern is observed in an active-CTL scenario since DPU 5.0.0 where for example bonded-DSI uses a single CTL to drive multiple INTFs, and each encoder calls this function individually with the INTF (hence the pre-existing update instead of overwrite of this bitmask) and DSC blocks it wishes to be enabled, and expects them to be OR'd into the bitmask. The reverse already exists in reset_intf_cfg_v1() where only specified DSC blocks are removed out of the CTL_DSC_ACTIVE bitmask (same for all other blocks and ACTIVE bitmasks), leaving the rest enabled. Fixes: 77f6da90487c ("drm/msm/disp/dpu1: Add DSC support in hw_ctl") Signed-off-by: Marijn Suijten Reviewed-by: Dmitry Baryshkov Patchwork: https://patchwork.freedesktop.org/patch/589902/ Link: https://lore.kernel.org/r/20240417-drm-msm-initial-dualpipe-dsc-fixes-v1-4-78ae3ee9a697@somainline.org Signed-off-by: Dmitry Baryshkov Signed-off-by: Sasha Levin commit 3d5d9bc7abbb5e659ec01ba29bb18f78853d5a24 Author: Marijn Suijten Date: Wed Apr 17 01:57:43 2024 +0200 drm/msm/dpu: Always flush the slave INTF on the CTL [ Upstream commit 2b938c3ab0a69ec6ea587bbf6fc2aec3db4a8736 ] As we can clearly see in a downstream kernel [1], flushing the slave INTF is skipped /only if/ the PPSPLIT topology is active. However, when DPU was originally submitted to mainline PPSPLIT was no longer part of it (seems to have been ripped out before submission), but this clause was incorrectly ported from the original SDE driver. Given that there is no support for PPSPLIT (currently), flushing the slave INTF should /never/ be skipped (as the `if (ppsplit && !master) goto skip;` clause downstream never becomes true). [1]: https://git.codelinaro.org/clo/la/platform/vendor/opensource/display-drivers/-/blob/display-kernel.lnx.5.4.r1-rel/msm/sde/sde_encoder_phys_cmd.c?ref_type=heads#L1131-1139 Fixes: 25fdd5933e4c ("drm/msm: Add SDM845 DPU support") Signed-off-by: Marijn Suijten Reviewed-by: Dmitry Baryshkov Patchwork: https://patchwork.freedesktop.org/patch/589901/ Link: https://lore.kernel.org/r/20240417-drm-msm-initial-dualpipe-dsc-fixes-v1-3-78ae3ee9a697@somainline.org Signed-off-by: Dmitry Baryshkov Signed-off-by: Sasha Levin commit d7ffc80045cf9bce4b4af21712b00a67e641ec77 Author: Marijn Suijten Date: Wed Apr 17 01:57:41 2024 +0200 drm/msm/dsi: Print dual-DSI-adjusted pclk instead of original mode pclk [ Upstream commit f12e0e12524a34bf145f7b80122e653ffe3d130a ] When dual-DSI (bonded DSI) was added in commit ed9976a09b48 ("drm/msm/dsi: adjust dsi timing for dual dsi mode") some DBG() prints were not updated, leading to print the original mode->clock rather than the adjusted (typically the mode clock divided by two, though more recently also adjusted for DSC compression) msm_host->pixel_clk_rate which is passed to clk_set_rate() just below. Fix that by printing the actual pixel_clk_rate that is being set. Fixes: ed9976a09b48 ("drm/msm/dsi: adjust dsi timing for dual dsi mode") Signed-off-by: Marijn Suijten Reviewed-by: Dmitry Baryshkov Patchwork: https://patchwork.freedesktop.org/patch/589896/ Link: https://lore.kernel.org/r/20240417-drm-msm-initial-dualpipe-dsc-fixes-v1-1-78ae3ee9a697@somainline.org Signed-off-by: Dmitry Baryshkov Signed-off-by: Sasha Levin commit e4a2f7db6e79e608c037214e7b6982fc220c498d Author: Fabio Estevam Date: Sun Apr 14 18:09:06 2024 -0300 media: ov2680: Do not fail if data-lanes property is absent [ Upstream commit 24034af644fc01126bec9850346a06ef1450181f ] Since commit 63b0cd30b78e ("media: ov2680: Add bus-cfg / endpoint property verification") the ov2680 driver no longer probes when the 'data-lanes' property is absent. The OV2680 sensor has only one data lane, so there is no need for describing it the devicetree. Remove the unnecessary data-lanes property check. Suggested-by: Sakari Ailus Fixes: 63b0cd30b78e ("media: ov2680: Add bus-cfg / endpoint property verification") Signed-off-by: Fabio Estevam Reviewed-by: Hans de Goede Signed-off-by: Sakari Ailus Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 3fabde518d42fb127f265c2eebf919e199566c2b Author: Fabio Estevam Date: Thu Mar 28 19:44:13 2024 -0300 media: ov2680: Allow probing if link-frequencies is absent [ Upstream commit fd2e66abd729dae5809dbb41c6c52a6931cfa6bb ] Since commit 63b0cd30b78e ("media: ov2680: Add bus-cfg / endpoint property verification") the ov2680 no longer probes on a imx7s-warp7: ov2680 1-0036: error -EINVAL: supported link freq 330000000 not found ov2680 1-0036: probe with driver ov2680 failed with error -22 As the 'link-frequencies' property is not mandatory, allow the probe to succeed by skipping the link-frequency verification when the property is absent. Cc: stable@vger.kernel.org Fixes: 63b0cd30b78e ("media: ov2680: Add bus-cfg / endpoint property verification") Signed-off-by: Fabio Estevam Reviewed-by: Hans de Goede Signed-off-by: Sakari Ailus Signed-off-by: Hans Verkuil Stable-dep-of: 24034af644fc ("media: ov2680: Do not fail if data-lanes property is absent") Signed-off-by: Sasha Levin commit 23ea3d99a142a60e2bd21a5fb4145386f957aa7e Author: Fabio Estevam Date: Thu Mar 28 19:44:12 2024 -0300 media: ov2680: Clear the 'ret' variable on success [ Upstream commit 49a9bad83b4ab5dac1d7aba2615c77978bcf3984 ] Since commit 63b0cd30b78e ("media: ov2680: Add bus-cfg / endpoint property verification") even when the correct 'link-frequencies' property is passed in the devicetree, the driver fails to probe: ov2680 1-0036: probe with driver ov2680 failed with error -22 The reason is that the variable 'ret' may contain the -EINVAL value from a previous assignment: ret = fwnode_property_read_u32(dev_fwnode(dev), "clock-frequency", &rate); Fix the problem by clearing 'ret' on the successful path. Tested on imx7s-warp board with the following devicetree: port { ov2680_to_mipi: endpoint { remote-endpoint = <&mipi_from_sensor>; clock-lanes = <0>; data-lanes = <1>; link-frequencies = /bits/ 64 <330000000>; }; }; Cc: stable@vger.kernel.org Fixes: 63b0cd30b78e ("media: ov2680: Add bus-cfg / endpoint property verification") Suggested-by: Hans de Goede Signed-off-by: Fabio Estevam Reviewed-by: Hans de Goede Signed-off-by: Sakari Ailus Signed-off-by: Hans Verkuil Stable-dep-of: 24034af644fc ("media: ov2680: Do not fail if data-lanes property is absent") Signed-off-by: Sasha Levin commit 0f0ca547633f9c78f60453ca2133c8106b6a87c7 Author: Sakari Ailus Date: Wed Apr 10 12:58:44 2024 +0300 media: v4l: Don't turn on privacy LED if streamon fails [ Upstream commit f2bf6cd8f44781349620e30a0af8987fe9af008f ] Turn on the privacy LED only if streamon succeeds. This can be done after enabling streaming on the sensor. Fixes: b6e10ff6c23d ("media: v4l2-core: Make the v4l2-core code enable/disable the privacy LED if present") Signed-off-by: Sakari Ailus Reviewed-by: Hans de Goede Reviewed-by: Tomi Valkeinen Reviewed-by: Umang Jain Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 80a8b92950f8ee96582dba6187e3c2deca3569ea Author: Jai Luthra Date: Fri Feb 23 13:53:02 2024 +0530 media: ti: j721e-csi2rx: Fix races while restarting DMA [ Upstream commit ad79c9ecea5baa7b4f19677e4b1c881ed89b0c3b ] After the frame is submitted to DMA, it may happen that the submitted list is not updated soon enough, and the DMA callback is triggered before that. This can lead to kernel crashes, so move everything in a single lock/unlock section to prevent such races. Fixes: b4a3d877dc92 ("media: ti: Add CSI2RX support for J721E") Signed-off-by: Jai Luthra Signed-off-by: Sakari Ailus Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit dfecca6ce78875234fad87461576a7e6a8a74b51 Author: Fenglin Wu Date: Mon Apr 15 16:03:40 2024 -0700 Input: pm8xxx-vibrator - correct VIB_MAX_LEVELS calculation [ Upstream commit 48c0687a322d54ac7e7a685c0b6db78d78f593af ] The output voltage is inclusive hence the max level calculation is off-by-one-step. Correct it. iWhile we are at it also add a define for the step size instead of using the magic value. Fixes: 11205bb63e5c ("Input: add support for pm8xxx based vibrator driver") Signed-off-by: Fenglin Wu Reviewed-by: Dmitry Baryshkov Link: https://lore.kernel.org/r/20240412-pm8xxx-vibrator-new-design-v10-1-0ec0ad133866@quicinc.com Signed-off-by: Dmitry Torokhov Signed-off-by: Sasha Levin commit c890aa5efe2d3c8e28f29538ce48733b01a05be5 Author: Neil Armstrong Date: Mon Feb 26 16:22:36 2024 +0100 phy: qcom: qmp-combo: fix sm8650 voltage swing table [ Upstream commit f320268fcebcbab02631d2070fa19ad4856a5a5e ] The QMP USB3/DP PHY found in the SM8650 SoC requires a slightly different Voltage Swing table for HBR/RBR link speeds. Add a new hbr/rbr voltage switch table named "v6" used in a new sm8650 qmp_phy_cfg struct replacing the sm8550 fallback used for the sm8650 compatible. Fixes: 80c1afe8c5fe ("phy: qcom: qmp-combo: add QMP USB3/DP PHY tables for SM8650") Signed-off-by: Neil Armstrong Link: https://lore.kernel.org/r/20240226-topic-sm8650-upstream-combo-phy-swing-update-v1-1-08707ebca92a@linaro.org Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 6229529507f1d510104f39c620efe15eea226a0f Author: Uros Bizjak Date: Tue Apr 2 19:50:38 2024 +0200 x86/percpu: Use __force to cast from __percpu address space [ Upstream commit a55c1fdad5f61b4bfe42319694b23671a758cb28 ] Fix Sparse warning when casting from __percpu address space by using __force in the cast. x86 named address spaces are not considered to be subspaces of the generic (flat) address space, so explicit casts are required to convert pointers between these address spaces and the generic address space (the application should cast to uintptr_t and apply the segment base offset). The cast to uintptr_t removes __percpu address space tag and Sparse reports: warning: cast removes address space '__percpu' of expression Use __force to inform Sparse that the cast is intentional. Fixes: 9a462b9eafa6 ("x86/percpu: Use compiler segment prefix qualifier") Reported-by: Charlemagne Lasse Signed-off-by: Uros Bizjak Signed-off-by: Ingo Molnar Cc: Linus Torvalds Link: https://lore.kernel.org/r/20240402175058.52649-1-ubizjak@gmail.com Closes: https://lore.kernel.org/lkml/CAFGhKbzev7W4aHwhFPWwMZQEHenVgZUj7=aunFieVqZg3mt14A@mail.gmail.com/ Signed-off-by: Sasha Levin commit ac751e2327f0c7373216d421ede654394bd19e84 Author: Uros Bizjak Date: Fri Mar 22 11:27:14 2024 +0100 x86/percpu: Unify arch_raw_cpu_ptr() defines [ Upstream commit 4e5b0e8003df05983b6dabcdde7ff447d53b49d7 ] When building a 32-bit vDSO for a 64-bit kernel, games are played with CONFIG_X86_64. {this,raw}_cpu_read_8() macros are conditionally defined on CONFIG_X86_64 and when CONFIG_X86_64 is undefined in fake_32bit_build.h various build failures in generic percpu header files can happen. To make things worse, the build of 32-bit vDSO for a 64-bit kernel grew dependency on arch_raw_cpu_ptr() macro and the build fails if arch_raw_cpu_ptr() macro is not defined. To mitigate these issues, x86 carefully defines arch_raw_cpu_ptr() to avoid any dependency on raw_cpu_read_8() and thus CONFIG_X86_64. W/o segment register support, the definition uses size-agnostic MOV asm mnemonic and hopes that _ptr argument won't ever be 64-bit size on 32-bit targets (although newer GCCs warn for this situation with "unsupported size for integer register"), and w/ segment register support the definition uses size-agnostic __raw_cpu_read() macro. Fortunately, raw_cpu_read() is not used in 32-bit vDSO for a 64-bit kernel. However, we can't simply omit the definition of arch_raw_cpu_read(), since the build will fail when building vdso/vdso32/vclock_gettime.o. The patch defines arch_raw_cpu_ptr to BUILD_BUG() when BUILD_VDSO32_64 macro is defined. This way, we are sure that arch_raw_cpu_ptr() won't actually be used in 32-bit VDSO for a 64-bit kernel, but it is still defined to prevent build failure. Finally, we can unify arch_raw_cpu_ptr() between builds w/ and w/o x86 segment register support, substituting two tricky macro definitions with a straightforward implementation. There is no size difference and no difference in number of this_cpu_off accesses between patched and unpatched kernel when the kernel is built either w/ and w/o segment register support. Signed-off-by: Uros Bizjak Signed-off-by: Ingo Molnar Cc: Andy Lutomirski Cc: Linus Torvalds Link: https://lore.kernel.org/r/20240322102730.209141-1-ubizjak@gmail.com Stable-dep-of: a55c1fdad5f6 ("x86/percpu: Use __force to cast from __percpu address space") Signed-off-by: Sasha Levin commit 863fa285c124d9185e4ef0905215bebd6005edfa Author: Judith Mendez Date: Wed Mar 20 17:38:37 2024 -0500 mmc: sdhci_am654: Fix ITAPDLY for HS400 timing [ Upstream commit d3182932bb070e7518411fd165e023f82afd7d25 ] While STRB is currently used for DATA and CRC responses, the CMD responses from the device to the host still require ITAPDLY for HS400 timing. Currently what is stored for HS400 is the ITAPDLY from High Speed mode which is incorrect. The ITAPDLY for HS400 speed mode should be the same as ITAPDLY as HS200 timing after tuning is executed. Add the functionality to save ITAPDLY from HS200 tuning and save as HS400 ITAPDLY. Fixes: a161c45f2979 ("mmc: sdhci_am654: Enable DLL only for some speed modes") Signed-off-by: Judith Mendez Acked-by: Adrian Hunter Link: https://lore.kernel.org/r/20240320223837.959900-8-jm@ti.com Signed-off-by: Ulf Hansson Signed-off-by: Sasha Levin commit 7bd5afc017fe69999b03b0654bf250ea61648787 Author: Judith Mendez Date: Wed Mar 20 17:38:36 2024 -0500 mmc: sdhci_am654: Add ITAPDLYSEL in sdhci_j721e_4bit_set_clock [ Upstream commit 9dff65bb5e09903c27d9cff947dff4d22b6ea6a1 ] Add ITAPDLYSEL to sdhci_j721e_4bit_set_clock function. This allows to set the correct ITAPDLY for timings that do not carry out tuning. Fixes: 1accbced1c32 ("mmc: sdhci_am654: Add Support for 4 bit IP on J721E") Signed-off-by: Judith Mendez Acked-by: Adrian Hunter Link: https://lore.kernel.org/r/20240320223837.959900-7-jm@ti.com Signed-off-by: Ulf Hansson Signed-off-by: Sasha Levin commit dc335b745709d6b261dc341d4ef7dacc7675bedf Author: Judith Mendez Date: Wed Mar 20 17:38:33 2024 -0500 mmc: sdhci_am654: Add OTAP/ITAP delay enable [ Upstream commit 387c1bf7dce0dfea02080c8bdb066b5209e92155 ] Currently the OTAP/ITAP delay enable functionality is incorrect in the am654_set_clock function. The OTAP delay is not enabled when timing < SDR25 bus speed mode. The ITAP delay is not enabled for timings that do not carry out tuning. Add this OTAP/ITAP delay functionality according to the datasheet [1] OTAPDLYENA and ITAPDLYENA for MMC0. [1] https://www.ti.com/lit/ds/symlink/am62p.pdf Fixes: 8ee5fc0e0b3b ("mmc: sdhci_am654: Update OTAPDLY writes") Signed-off-by: Judith Mendez Acked-by: Adrian Hunter Link: https://lore.kernel.org/r/20240320223837.959900-4-jm@ti.com Signed-off-by: Ulf Hansson Signed-off-by: Sasha Levin commit f71c3a70725da80a9cd0715b4a16196d580b051b Author: Judith Mendez Date: Wed Mar 20 17:38:32 2024 -0500 mmc: sdhci_am654: Write ITAPDLY for DDR52 timing [ Upstream commit d465234493bb6ad1b9c10a0c9ef9881b8d85081a ] For DDR52 timing, DLL is enabled but tuning is not carried out, therefore the ITAPDLY value in PHY CTRL 4 register is not correct. Fix this by writing ITAPDLY after enabling DLL. Fixes: a161c45f2979 ("mmc: sdhci_am654: Enable DLL only for some speed modes") Signed-off-by: Judith Mendez Reviewed-by: Andrew Davis Acked-by: Adrian Hunter Link: https://lore.kernel.org/r/20240320223837.959900-3-jm@ti.com Signed-off-by: Ulf Hansson Signed-off-by: Sasha Levin commit d25972baadc5f51b883baec2f104278db20f82ab Author: Judith Mendez Date: Wed Mar 20 17:38:31 2024 -0500 mmc: sdhci_am654: Add tuning algorithm for delay chain [ Upstream commit 6231d99dd4119312ad41abf9383e18fec66cbe4b ] Currently the sdhci_am654 driver only supports one tuning algorithm which should be used only when DLL is enabled. The ITAPDLY is selected from the largest passing window and the buffer is viewed as a circular buffer. The new algorithm should be used when the delay chain is enabled. The ITAPDLY is selected from the largest passing window and the buffer is not viewed as a circular buffer. This implementation is based off of the following paper: [1]. Also add support for multiple failing windows. [1] https://www.ti.com/lit/an/spract9/spract9.pdf Fixes: 13ebeae68ac9 ("mmc: sdhci_am654: Add support for software tuning") Signed-off-by: Judith Mendez Acked-by: Adrian Hunter Link: https://lore.kernel.org/r/20240320223837.959900-2-jm@ti.com Signed-off-by: Ulf Hansson Signed-off-by: Sasha Levin commit ba6bf5bf36d29e49ee1a33a817d144cc26862a5b Author: Karel Balej Date: Fri Mar 15 12:46:14 2024 -0700 Input: ioc3kbd - add device table [ Upstream commit d40e9edcf3eb925c259df9f9dd7319a4fcbc675b ] Without the device table the driver will not auto-load when compiled as a module. Fixes: 273db8f03509 ("Input: add IOC3 serio driver") Signed-off-by: Karel Balej Link: https://lore.kernel.org/r/20240313115832.8052-1-balejk@matfyz.cz Signed-off-by: Dmitry Torokhov Signed-off-by: Sasha Levin commit 518feda4aa526ff1857376333762344412d89676 Author: Arnd Bergmann Date: Thu Mar 28 13:28:56 2024 -0700 Input: ims-pcu - fix printf string overflow [ Upstream commit bf32bceedd0453c70d9d022e2e29f98e446d7161 ] clang warns about a string overflow in this driver drivers/input/misc/ims-pcu.c:1802:2: error: 'snprintf' will always be truncated; specified size is 10, but format string expands to at least 12 [-Werror,-Wformat-truncation] drivers/input/misc/ims-pcu.c:1814:2: error: 'snprintf' will always be truncated; specified size is 10, but format string expands to at least 12 [-Werror,-Wformat-truncation] Make the buffer a little longer to ensure it always fits. Fixes: 628329d52474 ("Input: add IMS Passenger Control Unit driver") Signed-off-by: Arnd Bergmann Link: https://lore.kernel.org/r/20240326223825.4084412-7-arnd@kernel.org Signed-off-by: Dmitry Torokhov Signed-off-by: Sasha Levin commit 8830a9a81b18c397b40ee3601ae99f4d9cb8376f Author: Devyn Liu Date: Mon May 13 15:59:01 2024 +0800 gpiolib: acpi: Fix failed in acpi_gpiochip_find() by adding parent node match [ Upstream commit adbc49a5a8c6fcf7be154c2e30213bbf472940da ] Previous patch modified the standard used by acpi_gpiochip_find() to match device nodes. Using the device node set in gc->gpiodev->d- ev instead of gc->parent. However, there is a situation in gpio-dwapb where the GPIO device driver will set gc->fwnode for each port corresponding to a child node under a GPIO device, so gc->gpiodev->dev will be assigned the value of each child node in gpiochip_add_data(). gpio-dwapb.c: 128,31 static int dwapb_gpio_add_port(struct dwapb_gpio *gpio, struct dwapb_port_property *pp, unsigned int offs); port->gc.fwnode = pp->fwnode; 693,39 static int dwapb_gpio_probe; err = dwapb_gpio_add_port(gpio, &pdata->properties[i], i); When other drivers request GPIO pin resources through the GPIO device node provided by ACPI (corresponding to the parent node), the change of the matching object to gc->gpiodev->dev in acpi_gpiochip_find() only allows finding the value of each port (child node), resulting in a failed request. Reapply the condition of using gc->parent for match in acpi_gpio- chip_find() in the code can compatible with the problem of gpio-dwapb, and will not affect the two cases mentioned in the patch: 1. There is no setting for gc->fwnode. 2. The case that depends on using gc->fwnode for match. Fixes: 5062e4c14b75 ("gpiolib: acpi: use the fwnode in acpi_gpiochip_find()") Fixes: 067dbc1ea5ce ("gpiolib: acpi: Don't use GPIO chip fwnode in acpi_gpiochip_find()") Signed-off-by: Devyn Liu Reviewed-by: Mika Westerberg Tested-by: Benjamin Tissoires Signed-off-by: Andy Shevchenko Signed-off-by: Sasha Levin commit 2d42a37a4518478f075ccf848242b4a50e313a46 Author: Jason-JH.Lin Date: Fri Apr 26 10:01:21 2024 +0800 mailbox: mtk-cmdq: Fix pm_runtime_get_sync() warning in mbox shutdown [ Upstream commit 747a69a119c469121385543f21c2d08562968ccc ] The return value of pm_runtime_get_sync() in cmdq_mbox_shutdown() will return 1 when pm runtime state is active, and we don't want to get the warning message in this case. So we change the return value < 0 for WARN_ON(). Fixes: 8afe816b0c99 ("mailbox: mtk-cmdq-mailbox: Implement Runtime PM with autosuspend") Signed-off-by: Jason-JH.Lin Reviewed-by: AngeloGioacchino Del Regno Signed-off-by: Jassi Brar Signed-off-by: Sasha Levin commit a6ce2428c6d4d94118721c7b9f7121980c7040f3 Author: Tao Su Date: Thu May 9 13:31:13 2024 +0800 selftests/harness: use 1024 in place of LINE_MAX [ Upstream commit 28d2188709d9c19a7c4601c6870edd9fa0527379 ] Android was seeing a compilation error because its C library does not define LINE_MAX. Since LINE_MAX is only used to determine the size of test_name[] and 1024 should be enough for the test name, use 1024 instead of LINE_MAX. Link: https://lkml.kernel.org/r/20240509053113.43462-3-tao1.su@linux.intel.com Fixes: 38c957f07038 ("selftests: kselftest_harness: generate test name once") Signed-off-by: Tao Su Reviewed-by: Simon Horman Cc: Alexandre Belloni Cc: Bongsu Jeon Cc: Dave Hansen Cc: David S. Miller Cc: Edward Liaw Cc: Eric Dumazet Cc: Ivan Orlov Cc: Jakub Kicinski Cc: Jarkko Sakkinen Cc: Jaroslav Kysela Cc: Mark Brown Cc: Paolo Abeni Cc: Paolo Bonzini Cc: Sean Christopherson Cc: Shuah Khan Cc: Takashi Iwai Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit f2fc7dd801a210e0aed12950140582b76d876f29 Author: Joseph Qi Date: Thu Mar 14 10:17:13 2024 +0800 ocfs2: correctly use ocfs2_find_next_zero_bit() [ Upstream commit 30dd3478c3cd7d01cc5afc4952e885ba4eefb730 ] If no bits are zero, ocfs2_find_next_zero_bit() will return max size, so check the return value with -1 is meaningless. Correct this usage and cleanup the code. Link: https://lkml.kernel.org/r/20240314021713.240796-1-joseph.qi@linux.alibaba.com Signed-off-by: Joseph Qi Reviewed-by: Heming Zhao Cc: Mark Fasheh Cc: Joel Becker Cc: Junxiao Bi Cc: Changwei Ge Cc: Gang He Cc: Jun Piao Signed-off-by: Andrew Morton Stable-dep-of: 28d2188709d9 ("selftests/harness: use 1024 in place of LINE_MAX") Signed-off-by: Sasha Levin commit 93db3937721e8f83a9a545df3b6e4bc6a48c0a20 Author: Tao Su Date: Thu May 9 13:31:12 2024 +0800 Revert "selftests/harness: remove use of LINE_MAX" [ Upstream commit 6bb955fce08cbc8495a72755130d2d220994faee ] Patch series "Selftests: Fix compilation warnings due to missing _GNU_SOURCE definition", v2. Since kselftest_harness.h introduces asprintf()[1], many selftests have compilation warnings or errors due to missing _GNU_SOURCE definitions. The issue stems from a lack of a LINE_MAX definition in Android (see commit 38c957f07038), which is the reason why asprintf() was introduced. We tried adding _GNU_SOURCE definitions to more selftests to fix, but asprintf() may continue to cause problems, and since it is quite late in the 6.9 cycle, we would like to revert 809216233555 first to provide testing for forks[2]. [1] https://lore.kernel.org/all/20240411231954.62156-1-edliaw@google.com [2] https://lore.kernel.org/linux-kselftest/ZjuA3aY_iHkjP7bQ@google.com This patch (of 2): This reverts commit 8092162335554c8ef5e7f50eff68aa9cfbdbf865. asprintf() is declared in stdio.h when defining _GNU_SOURCE, but stdio.h is so common that many files don't define _GNU_SOURCE before including stdio.h, and defining _GNU_SOURCE after including stdio.h will no longer take effect, which causes warnings or even errors during compilation in many selftests. Revert 'commit 809216233555 ("selftests/harness: remove use of LINE_MAX")' as that came in quite late in the 6.9 cycle. Link: https://lkml.kernel.org/r/20240509053113.43462-1-tao1.su@linux.intel.com Link: https://lore.kernel.org/linux-kselftest/ZjuA3aY_iHkjP7bQ@google.com/ Link: https://lkml.kernel.org/r/20240509053113.43462-2-tao1.su@linux.intel.com Fixes: 809216233555 ("selftests/harness: remove use of LINE_MAX") Signed-off-by: Tao Su Reviewed-by: Simon Horman Cc: Alexandre Belloni Cc: Bongsu Jeon Cc: Dave Hansen Cc: David S. Miller Cc: Edward Liaw Cc: Eric Dumazet Cc: Ivan Orlov Cc: Jakub Kicinski Cc: Jarkko Sakkinen Cc: Jaroslav Kysela Cc: Mark Brown Cc: Paolo Abeni Cc: Paolo Bonzini Cc: Sean Christopherson Cc: Shuah Khan Cc: Takashi Iwai Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit 69c5630be81e3e0d80254026913caeea68b180b8 Author: Krzysztof Kozlowski Date: Mon Apr 1 12:00:58 2024 +0200 dt-bindings: PCI: rockchip,rk3399-pcie: Add missing maxItems to ep-gpios [ Upstream commit 52d06636a4ae4db24ebfe23fae7a525f7e983604 ] Properties with GPIOs should define number of actual GPIOs, so add missing maxItems to ep-gpios. Otherwise multiple GPIOs could be provided which is not a true hardware description. Fixes: aa222f9311e1 ("dt-bindings: PCI: Convert Rockchip RK3399 PCIe to DT schema") Link: https://lore.kernel.org/linux-pci/20240401100058.15749-1-krzysztof.kozlowski@linaro.org Signed-off-by: Krzysztof Kozlowski Signed-off-by: Krzysztof Wilczyński Acked-by: Conor Dooley Signed-off-by: Sasha Levin commit 0047f3f96e2ff51efa65a9ff82609724ef414024 Author: Sven Schnelle Date: Wed May 15 09:20:27 2024 +0200 s390/boot: Remove alt_stfle_fac_list from decompressor [ Upstream commit e7dec0b7926f3cd493c697c4c389df77e8e8a34c ] It is nowhere used in the decompressor, therefore remove it. Fixes: 17e89e1340a3 ("s390/facilities: move stfl information from lowcore to global data") Reviewed-by: Heiko Carstens Signed-off-by: Sven Schnelle Signed-off-by: Heiko Carstens Signed-off-by: Sasha Levin commit 764c1c65ad79f6694e9f51387a227ce416f0f01b Author: Harald Freudenberger Date: Mon May 13 11:21:48 2024 +0200 s390/ap: Fix bind complete udev event sent after each AP bus scan [ Upstream commit 306d6bda8f97432f9cb69b5cbd86afd3a8ca182f ] With the mentioned commit (see the fixes tag) on every AP bus scan an uevent "AP bus change bindings complete" is emitted. Furthermore if an AP device switched from one driver to another, for example by manipulating the apmask, there was never a "bindings complete" uevent generated. The "bindings complete" event should be sent once when all AP devices have been bound to device drivers and again if unbind/bind actions take place and finally all AP devices are bound again. Therefore implement this. Fixes: 778412ab915d ("s390/ap: rearm APQNs bindings complete completion") Reported-by: Marc Hartmayer Signed-off-by: Harald Freudenberger Reviewed-by: Holger Dengler Signed-off-by: Heiko Carstens Signed-off-by: Sasha Levin commit 23dbffa8bce0b311ab737a8d1e266021ea0bcc2c Author: Alexander Egorenkov Date: Fri May 10 12:41:26 2024 +0200 s390/ipl: Fix incorrect initialization of nvme dump block [ Upstream commit 7faacaeaf6ce12fae78751de5ad869d8f1e1cd7a ] Initialize the correct fields of the nvme dump block. This bug had not been detected before because first, the fcp and nvme fields of struct ipl_parameter_block are part of the same union and, therefore, overlap in memory and second, they are identical in structure and size. Fixes: d70e38cb1dee ("s390: nvme dump support") Reviewed-by: Heiko Carstens Signed-off-by: Alexander Egorenkov Signed-off-by: Alexander Gordeev Signed-off-by: Sasha Levin commit 897b948eee4ed2af2a6fad06c916096f4ddc9251 Author: Alexander Egorenkov Date: Fri May 10 12:41:25 2024 +0200 s390/ipl: Fix incorrect initialization of len fields in nvme reipl block [ Upstream commit 9c922b73acaf39f867668d9cbe5dc69c23511f84 ] Use correct symbolic constants IPL_BP_NVME_LEN and IPL_BP0_NVME_LEN to initialize nvme reipl block when 'scp_data' sysfs attribute is being updated. This bug had not been detected before because the corresponding fcp and nvme symbolic constants are equal. Fixes: 23a457b8d57d ("s390: nvme reipl") Reviewed-by: Heiko Carstens Signed-off-by: Alexander Egorenkov Signed-off-by: Alexander Gordeev Signed-off-by: Sasha Levin commit 1422de15d94701f3b1a48d17ace2ed810854f3e9 Author: Heiko Carstens Date: Mon Apr 29 14:28:48 2024 +0200 s390/stackstrace: Detect vdso stack frames [ Upstream commit 62b672c4ba90e726cc39b5c3d6dffd1ca817e143 ] Clear the backchain of the extra stack frame added by the vdso user wrapper code. This allows the user stack walker to detect and skip the non-standard stack frame. Without this an incorrect instruction pointer would be added to stack traces, and stack frame walking would be continued with a more or less random back chain. Fixes: aa44433ac4ee ("s390: add USER_STACKTRACE support") Reviewed-by: Jens Remus Signed-off-by: Heiko Carstens Signed-off-by: Alexander Gordeev Signed-off-by: Sasha Levin commit 978cef9ab0ad3cffa9f2e01a3970ce9c1678b893 Author: Heiko Carstens Date: Mon Apr 29 14:28:47 2024 +0200 s390/vdso: Introduce and use struct stack_frame_vdso_wrapper [ Upstream commit be72ea09c1a5273abf8c6c52ef53e36c701cbf6a ] Introduce and use struct stack_frame_vdso_wrapper within vdso user wrapper code. With this structure it is possible to automatically generate an asm-offset define which can be used to save and restore the return address of the calling function. Also use STACK_FRAME_USER_OVERHEAD instead of STACK_FRAME_OVERHEAD to document that the code works with user space stack frames with the standard stack frame layout. Fixes: aa44433ac4ee ("s390: add USER_STACKTRACE support") Reviewed-by: Jens Remus Signed-off-by: Heiko Carstens Signed-off-by: Alexander Gordeev Signed-off-by: Sasha Levin commit 11b96ded88f6fab2306f8165d5703f8bf25f9a72 Author: Heiko Carstens Date: Mon Apr 29 14:28:46 2024 +0200 s390/stacktrace: Improve detection of invalid instruction pointers [ Upstream commit cd58109283944ea8bdcd0a8211a86cbd2450716a ] Add basic checks to identify invalid instruction pointers when walking stack frames: Instruction pointers must - have even addresses - be larger than mmap_min_addr - lower than the asce_limit of the process Alternatively it would also be possible to walk page tables similar to fast GUP and verify that the mapping of the corresponding page is executable, however that seems to be overkill. Fixes: aa44433ac4ee ("s390: add USER_STACKTRACE support") Reviewed-by: Jens Remus Signed-off-by: Heiko Carstens Signed-off-by: Alexander Gordeev Signed-off-by: Sasha Levin commit a0ce61a56f977b2398688dc28ff1b09a2344e6bb Author: Heiko Carstens Date: Mon Apr 29 14:28:45 2024 +0200 s390/stacktrace: Skip first user stack frame [ Upstream commit 87eceb17a987802aeee718be4decd19b56fc8e33 ] When walking user stack frames the first stack frame (where the stack pointer points to) should be skipped: the return address of the current function is saved in the previous stack frame, not the current stack frame, which is allocated for to be called functions. Fixes: aa44433ac4ee ("s390: add USER_STACKTRACE support") Reviewed-by: Jens Remus Signed-off-by: Heiko Carstens Signed-off-by: Alexander Gordeev Signed-off-by: Sasha Levin commit dd69165ac3dc12d8550aeec3fc4439c084ded3d8 Author: Heiko Carstens Date: Mon Apr 29 14:28:44 2024 +0200 s390/stacktrace: Merge perf_callchain_user() and arch_stack_walk_user() [ Upstream commit ebd912ff9919a10609511383d94942362234c077 ] The two functions perf_callchain_user() and arch_stack_walk_user() are nearly identical. Reduce code duplication and add a common helper which can be called by both functions. Fixes: aa44433ac4ee ("s390: add USER_STACKTRACE support") Reviewed-by: Jens Remus Signed-off-by: Heiko Carstens Signed-off-by: Alexander Gordeev Signed-off-by: Sasha Levin commit fef7b77cdd0c6d5249982a9acbafb0d49598b80f Author: Sven Schnelle Date: Fri Apr 26 12:02:15 2024 +0200 s390/ftrace: Use unwinder instead of __builtin_return_address() [ Upstream commit cae74ba8c295bc41bda749ef27a8f2b3ee957a41 ] Using __builtin_return_address(n) might return undefined values when used with values of n outside of the stack. This was noticed when __builtin_return_address() was called in ftrace on top level functions like the interrupt handlers. As this behaviour cannot be fixed, use the s390 stack unwinder and remove the ftrace compilation flags for unwind_bc.c and stacktrace.c to prevent the unwinding function polluting function traces. Another advantage is that this also works with clang. Reviewed-by: Heiko Carstens Signed-off-by: Sven Schnelle Signed-off-by: Alexander Gordeev Stable-dep-of: ebd912ff9919 ("s390/stacktrace: Merge perf_callchain_user() and arch_stack_walk_user()") Signed-off-by: Sasha Levin commit 2db561897743167d40f5902626b1ae01af3624e9 Author: Heiko Carstens Date: Mon Apr 29 14:28:43 2024 +0200 s390/vdso: Use standard stack frame layout [ Upstream commit 185445c7c137822ad856aae91a41e199370cb534 ] By default user space is compiled with standard stack frame layout and not with the packed stack layout. The vdso code however inherited the -mpacked-stack compiler option from the kernel. Remove this option to make sure the vdso is compiled with standard stack frame layout. This makes sure that the stack frame backchain location for vdso generated stack frames is the same like for calling code (if compiled with default options). This allows to manually walk stack frames without DWARF information, like the kernel is doing it e.g. with arch_stack_walk_user(). Fixes: 4bff8cb54502 ("s390: convert to GENERIC_VDSO") Reviewed-by: Jens Remus Signed-off-by: Heiko Carstens Signed-off-by: Alexander Gordeev Signed-off-by: Sasha Levin commit 5841fc546e1f6750824d667ec78d11f89582577b Author: Jens Remus Date: Mon Apr 29 17:02:53 2024 +0200 s390/vdso: Create .build-id links for unstripped vdso files [ Upstream commit fc2f5f10f9bc5e58d38e9fda7dae107ac04a799f ] Citing Andy Lutomirski from commit dda1e95cee38 ("x86/vdso: Create .build-id links for unstripped vdso files"): "With this change, doing 'make vdso_install' and telling gdb: set debug-file-directory /lib/modules/KVER/vdso will enable vdso debugging with symbols. This is useful for testing, but kernel RPM builds will probably want to manually delete these symlinks or otherwise do something sensible when they strip the vdso/*.so files." Fixes: 4bff8cb54502 ("s390: convert to GENERIC_VDSO") Signed-off-by: Jens Remus Signed-off-by: Alexander Gordeev Signed-off-by: Sasha Levin commit 1479bf34f794de03d0bbb2dbec2b0f459ba2ddb2 Author: Jens Remus Date: Mon Apr 29 17:02:52 2024 +0200 s390/vdso: Generate unwind information for C modules [ Upstream commit 10f70525365146046dddcc3d36bfaea2aee0376a ] GDB fails to unwind vDSO functions with error message "PC not saved", for instance when stepping through gettimeofday(). Add -fasynchronous-unwind-tables to CFLAGS to generate .eh_frame DWARF unwind information for the vDSO C modules. Fixes: 4bff8cb54502 ("s390: convert to GENERIC_VDSO") Signed-off-by: Jens Remus Signed-off-by: Alexander Gordeev Signed-off-by: Sasha Levin commit a96d48f89e0383e205e0be3e1908b7bd4f68673b Author: Huacai Chen Date: Tue May 14 12:24:18 2024 +0800 LoongArch: Fix callchain parse error with kernel tracepoint events again [ Upstream commit d6af2c76399f98444a5b4de96baf4b362d9f102b ] With commit d3119bc985fb645 ("LoongArch: Fix callchain parse error with kernel tracepoint events"), perf can parse kernel callchain, but not complete and sometimes maybe error. The reason is LoongArch's unwinders (guess, prologue and orc) don't really need fp (i.e., regs[22]), and they use sp (i.e., regs[3]) as the frame address rather than the current stack pointer. Fix that by removing the assignment of regs[22], and instead assign the __builtin_frame_address(0) to regs[3]. Without fix: Children Self Command Shared Object Symbol ........ ........ ............. ................. ................ 33.91% 33.91% swapper [kernel.vmlinux] [k] __schedule | |--33.04%--__schedule | --0.87%--__arch_cpu_idle __schedule With this fix: Children Self Command Shared Object Symbol ........ ........ ............. ................. ................ 31.16% 31.16% swapper [kernel.vmlinux] [k] __schedule | |--20.63%--smpboot_entry | cpu_startup_entry | schedule_idle | __schedule | --10.53%--start_kernel cpu_startup_entry schedule_idle __schedule Fixes: d3119bc985fb645 ("LoongArch: Fix callchain parse error with kernel tracepoint events") Signed-off-by: Huacai Chen Signed-off-by: Sasha Levin commit 2a33c2b03c2903faa2185be972a715b314cfaee6 Author: Ian Rogers Date: Fri May 10 17:36:01 2024 -0700 perf pmu: Count sys and cpuid JSON events separately [ Upstream commit d9c5f5f94c2d356fdf3503f7fcaf254512bc032d ] Sys events are eagerly loaded as each event has a compat option that may mean the event is or isn't associated with the PMU. These shouldn't be counted as loaded_json_events as that is used for JSON events matching the CPUID that may or may not have been loaded. The mismatch causes issues on ARM64 that uses sys events. Fixes: e6ff1eed3584362d ("perf pmu: Lazily add JSON events") Closes: https://lore.kernel.org/lkml/20240510024729.1075732-1-justin.he@arm.com/ Reported-by: Jia He Signed-off-by: Ian Rogers Cc: Adrian Hunter Cc: Alexander Shishkin Cc: Ingo Molnar Cc: James Clark Cc: Jiri Olsa Cc: John Garry Cc: Kan Liang Cc: Mark Rutland Cc: Namhyung Kim Cc: Peter Zijlstra Link: https://lore.kernel.org/r/20240511003601.2666907-1-irogers@google.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 0675ff8fed442770a9874977429a76e80efb61ed Author: Ian Rogers Date: Thu May 2 14:35:07 2024 -0700 perf pmu: Assume sysfs events are always the same case [ Upstream commit 7b6dd7a923281a7ccb980a0f768d6926721eb3cc ] Perf event names aren't case sensitive. For sysfs events the entire directory of events is read then iterated comparing names in a case insensitive way, most often to see if an event is present. Consider: $ perf stat -e inst_retired.any true The event inst_retired.any may be present in any PMU, so every PMU's sysfs events are loaded and then searched with strcasecmp to see if any match. This event is only present on the cpu PMU as a JSON event so a lot of events were loaded from sysfs unnecessarily just to prove an event didn't exist there. This change avoids loading all the events by assuming sysfs event names are always either lower or uppercase. It uses file exists and only loads the events when the desired event is present. For the example above, the number of openat calls measured by 'perf trace' on a tigerlake laptop goes from 325 down to 255. The reduction will be larger for machines with many PMUs, particularly replicated uncore PMUs. Ensure pmu_aliases_parse() is called before all uses of the aliases list, but remove some "pmu->sysfs_aliases_loaded" tests as they are now part of the function. Reviewed-by: Kan Liang Signed-off-by: Ian Rogers Cc: Alexander Shishkin Cc: Bjorn Helgaas Cc: Ingo Molnar Cc: James Clark Cc: Jing Zhang Cc: Jiri Olsa Cc: Jonathan Corbet Cc: Mark Rutland Cc: Namhyung Kim Cc: Peter Zijlstra Cc: Randy Dunlap Cc: Ravi Bangoria Cc: Thomas Richter Link: https://lore.kernel.org/r/20240502213507.2339733-7-irogers@google.com Signed-off-by: Arnaldo Carvalho de Melo Stable-dep-of: d9c5f5f94c2d ("perf pmu: Count sys and cpuid JSON events separately") Signed-off-by: Sasha Levin commit 30716f8db676addcb10117f16c2b69f92d6b9085 Author: Ian Rogers Date: Thu Mar 7 16:19:15 2024 -0800 perf tools: Add/use PMU reverse lookup from config to name [ Upstream commit 67ee8e71daabb8632931b7559e5c8a4b69a427f8 ] Add perf_pmu__name_from_config that does a reverse lookup from a config number to an alias name. The lookup is expensive as the config is computed for every alias by filling in a perf_event_attr, but this is only done when verbose output is enabled. The lookup also only considers config, and not config1, config2 or config3. An example of the output: $ perf stat -vv -e data_read true ... perf_event_attr: type 24 (uncore_imc_free_running_0) size 136 config 0x20ff (data_read) sample_type IDENTIFIER read_format TOTAL_TIME_ENABLED|TOTAL_TIME_RUNNING disabled 1 inherit 1 exclude_guest 1 ... Committer notes: Fix the python binding build by adding dummies for not strictly needed perf_pmu__name_from_config() and perf_pmus__find_by_type(). Signed-off-by: Ian Rogers Tested-by: Arnaldo Carvalho de Melo Tested-by: Kan Liang Cc: Adrian Hunter Cc: Alexander Shishkin Cc: Ingo Molnar Cc: James Clark Cc: Jiri Olsa Cc: Mark Rutland Cc: Namhyung Kim Cc: Peter Zijlstra Cc: Ravi Bangoria Cc: Yang Jihong Link: https://lore.kernel.org/r/20240308001915.4060155-7-irogers@google.com Signed-off-by: Arnaldo Carvalho de Melo Stable-dep-of: d9c5f5f94c2d ("perf pmu: Count sys and cpuid JSON events separately") Signed-off-by: Sasha Levin commit ba3bbb34392fedcb0dd1d2a335fd8009f9fce161 Author: Ian Rogers Date: Thu Mar 7 16:19:14 2024 -0800 perf tools: Use pmus to describe type from attribute [ Upstream commit 7093882067e2e2f88d3449c35c5f0f3f566c8a26 ] When dumping a perf_event_attr, use pmus to find the PMU and its name by the type number. This allows dynamically added PMUs to be described. Before: $ perf stat -vv -e data_read true ... perf_event_attr: type 24 size 136 config 0x20ff sample_type IDENTIFIER read_format TOTAL_TIME_ENABLED|TOTAL_TIME_RUNNING disabled 1 inherit 1 exclude_guest 1 ... After: $ perf stat -vv -e data_read true ... perf_event_attr: type 24 (uncore_imc_free_running_0) size 136 config 0x20ff sample_type IDENTIFIER read_format TOTAL_TIME_ENABLED|TOTAL_TIME_RUNNING disabled 1 inherit 1 exclude_guest 1 ... However, it also means that when we have a PMU name we prefer it to a hard coded name: Before: $ perf stat -vv -e faults true ... perf_event_attr: type 1 (PERF_TYPE_SOFTWARE) size 136 config 0x2 (PERF_COUNT_SW_PAGE_FAULTS) sample_type IDENTIFIER read_format TOTAL_TIME_ENABLED|TOTAL_TIME_RUNNING disabled 1 inherit 1 enable_on_exec 1 exclude_guest 1 ... After: $ perf stat -vv -e faults true ... perf_event_attr: type 1 (software) size 136 config 0x2 (PERF_COUNT_SW_PAGE_FAULTS) sample_type IDENTIFIER read_format TOTAL_TIME_ENABLED|TOTAL_TIME_RUNNING disabled 1 inherit 1 enable_on_exec 1 exclude_guest 1 ... It feels more consistent to do this, rather than only prefer a PMU name when a hard coded name isn't available. Signed-off-by: Ian Rogers Tested-by: Arnaldo Carvalho de Melo Tested-by: Kan Liang Cc: Adrian Hunter Cc: Alexander Shishkin Cc: Ingo Molnar Cc: James Clark Cc: Jiri Olsa Cc: Mark Rutland Cc: Namhyung Kim Cc: Peter Zijlstra Cc: Ravi Bangoria Cc: Yang Jihong Link: https://lore.kernel.org/r/20240308001915.4060155-6-irogers@google.com Signed-off-by: Arnaldo Carvalho de Melo Stable-dep-of: d9c5f5f94c2d ("perf pmu: Count sys and cpuid JSON events separately") Signed-off-by: Sasha Levin commit 5e14d9883c3c0a39e3473d4720e618b7ad1dd227 Author: Ian Rogers Date: Thu May 9 22:13:09 2024 -0700 perf stat: Don't display metric header for non-leader uncore events [ Upstream commit 193a9e30207f54777ff42d0d8be8389edc522277 ] On an Intel tigerlake laptop a metric like: { "BriefDescription": "Test", "MetricExpr": "imc_free_running@data_read@ + imc_free_running@data_write@", "MetricGroup": "Test", "MetricName": "Test", "ScaleUnit": "6.103515625e-5MiB" }, Will have 4 events: uncore_imc_free_running_0/data_read/ uncore_imc_free_running_0/data_write/ uncore_imc_free_running_1/data_read/ uncore_imc_free_running_1/data_write/ If aggregration is disabled with metric-only 2 column headers are needed: $ perf stat -M test --metric-only -A -a sleep 1 Performance counter stats for 'system wide': MiB Test MiB Test CPU0 1821.0 1820.5 But when not, the counts aggregated in the metric leader and only 1 column should be shown: $ perf stat -M test --metric-only -a sleep 1 Performance counter stats for 'system wide': MiB Test 5909.4 1.001258915 seconds time elapsed Achieve this by skipping events that aren't metric leaders when printing column headers and aggregation isn't disabled. The bug is long standing, the fixes tag is set to a refactor as that is as far back as is reasonable to backport. Fixes: 088519f318be3a41 ("perf stat: Move the display functions to stat-display.c") Signed-off-by: Ian Rogers Cc: Adrian Hunter Cc: Alexander Shishkin Cc: Ingo Molnar Cc: Jiri Olsa Cc: Kaige Ye Cc: Kan Liang Cc: K Prateek Nayak Cc: Mark Rutland Cc: Namhyung Kim Cc: Peter Zijlstra Cc: Yicong Yang Link: https://lore.kernel.org/r/20240510051309.2452468-1-irogers@google.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 9816300dd636dcf35491d4d5963c5406eea601b2 Author: Namhyung Kim Date: Fri May 10 14:04:51 2024 -0700 perf annotate: Fix segfault on sample histogram [ Upstream commit 9ef30265a483f0405e4f7b3f15cda251b9a2c7da ] A symbol can have no samples, then accessing the annotated_source->samples hashmap will result in a segfault. Fixes: a3f7768bcf48281d ("perf annotate: Fix memory leak in annotated_source") Reviewed-by: Ian Rogers Signed-off-by: Namhyung Kim Cc: Adrian Hunter Cc: Ingo Molnar Cc: Jiri Olsa Cc: Kan Liang Cc: Peter Zijlstra Link: https://lore.kernel.org/r/20240510210452.2449944-1-namhyung@kernel.org Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 55706d3e4617604115ca913d5d886903ec12a33c Author: Andy Shevchenko Date: Fri May 10 18:26:22 2024 +0300 usb: fotg210: Add missing kernel doc description [ Upstream commit 4b653e82ae18f2dc91c7132b54f5785c4d56bab4 ] kernel-doc validator is not happy: warning: Function parameter or struct member 'fotg' not described in 'fotg210_vbus' Add missing description. Fixes: 3e679bde529e ("usb: fotg210-udc: Implement VBUS session") Signed-off-by: Andy Shevchenko Reviewed-by: Linus Walleij Link: https://lore.kernel.org/r/20240510152641.2421298-1-andriy.shevchenko@linux.intel.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 09ff60b3858a4c4d7d94cb69512692fb02469d1e Author: Chao Yu Date: Fri May 10 11:43:33 2024 +0800 f2fs: fix to add missing iput() in gc_data_segment() [ Upstream commit a798ff17cd2dabe47d5d4ed3d509631793c36e19 ] During gc_data_segment(), if inode state is abnormal, it missed to call iput(), fix it. Fixes: b73e52824c89 ("f2fs: reposition unlock_new_inode to prevent accessing invalid inode") Fixes: 9056d6489f5a ("f2fs: fix to do sanity check on inode type during garbage collection") Signed-off-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit f3b3f4988af70507fc5e9a91b369d6a2d89c9ff7 Author: Dan Carpenter Date: Sat Mar 16 12:45:27 2024 +0300 backlight: mp3309c: Fix signedness bug in mp3309c_parse_fwnode() [ Upstream commit e962f13b1e86272a5dcdaede2dfb649152e981e9 ] The "num_levels" variable is used to store error codes from device_property_count_u32() so it needs to be signed. This doesn't cause an issue at runtime because devm_kcalloc() won't allocate negative sizes. However, it's still worth fixing. Fixes: b54c828bdba9 ("backlight: mp3309c: Make use of device properties") Signed-off-by: Dan Carpenter Reviewed-by: Daniel Thompson Tested-by: Flavio Suligoi Reviewed-by: Andy Shevchenko Link: https://lore.kernel.org/r/74347f67-360d-4513-8939-595e3c4764fa@moroto.mountain Signed-off-by: Lee Jones Signed-off-by: Sasha Levin commit 48ef87147247ee4c80626ef65c8c7b3da05946e8 Author: Samasth Norway Ananda Date: Thu May 9 17:34:24 2024 -0700 perf daemon: Fix file leak in daemon_session__control [ Upstream commit 09541603462c399c7408d50295db99b4b8042eaa ] The open() function returns -1 on error. The 'control' and 'ack' file descriptors are both initialized with open() and further validated with 'if' statement. 'if (!control)' would evaluate to 'true' if returned value on error were '0' but it is actually '-1'. Fixes: edcaa47958c7438b ("perf daemon: Add 'ping' command") Signed-off-by: Samasth Norway Ananda Cc: Adrian Hunter Cc: Alexander Shishkin Cc: Ian Rogers Cc: Ingo Molnar Cc: Jiri Olsa Cc: Mark Rutland Cc: Namhyung Kim Cc: Peter Zijlstra Link: https://lore.kernel.org/r/20240510003424.2016914-1-samasth.norway.ananda@oracle.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 14ce6d29b47ad40adc01c9126979d3fe5cd37105 Author: Ian Rogers Date: Wed May 8 22:20:15 2024 -0700 libsubcmd: Fix parse-options memory leak [ Upstream commit 230a7a71f92212e723fa435d4ca5922de33ec88a ] If a usage string is built in parse_options_subcommand, also free it. Fixes: 901421a5bdf605d2 ("perf tools: Remove subcmd dependencies on strbuf") Signed-off-by: Ian Rogers Cc: Adrian Hunter Cc: Alexander Shishkin Cc: Ingo Molnar Cc: Jiri Olsa Cc: Josh Poimboeuf Cc: Kan Liang Cc: Mark Rutland Cc: Namhyung Kim Cc: Peter Zijlstra Link: https://lore.kernel.org/r/20240509052015.1914670-1-irogers@google.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 5172196474c25ec716ebac069e93bfa3bcf3015c Author: Wolfram Sang Date: Mon May 6 13:40:17 2024 +0200 serial: sh-sci: protect invalidating RXDMA on shutdown [ Upstream commit aae20f6e34cd0cbd67a1d0e5877561c40109a81b ] The to-be-fixed commit removed locking when invalidating the DMA RX descriptors on shutdown. It overlooked that there is still a rx_timer running which may still access the protected data. So, re-add the locking. Reported-by: Dirk Behme Closes: https://lore.kernel.org/r/ee6c9e16-9f29-450e-81da-4a8dceaa8fc7@de.bosch.com Fixes: 2c4ee23530ff ("serial: sh-sci: Postpone DMA release when falling back to PIO") Signed-off-by: Wolfram Sang Link: https://lore.kernel.org/r/20240506114016.30498-7-wsa+renesas@sang-engineering.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 533070db659a9589310a743e9de14cf9d651ffaf Author: Hou Tao Date: Thu May 9 20:21:54 2024 +0800 fuse: clear FR_SENT when re-adding requests into pending list [ Upstream commit 246014876d782bbf2e652267482cd2e799fb5fcd ] The following warning was reported by lee bruce: ------------[ cut here ]------------ WARNING: CPU: 0 PID: 8264 at fs/fuse/dev.c:300 fuse_request_end+0x685/0x7e0 fs/fuse/dev.c:300 Modules linked in: CPU: 0 PID: 8264 Comm: ab2 Not tainted 6.9.0-rc7 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) RIP: 0010:fuse_request_end+0x685/0x7e0 fs/fuse/dev.c:300 ...... Call Trace: fuse_dev_do_read.constprop.0+0xd36/0x1dd0 fs/fuse/dev.c:1334 fuse_dev_read+0x166/0x200 fs/fuse/dev.c:1367 call_read_iter include/linux/fs.h:2104 [inline] new_sync_read fs/read_write.c:395 [inline] vfs_read+0x85b/0xba0 fs/read_write.c:476 ksys_read+0x12f/0x260 fs/read_write.c:619 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xce/0x260 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f ...... The warning is due to the FUSE_NOTIFY_RESEND notify sent by the write() syscall in the reproducer program and it happens as follows: (1) calls fuse_dev_read() to read the INIT request The read succeeds. During the read, bit FR_SENT will be set on the request. (2) calls fuse_dev_write() to send an USE_NOTIFY_RESEND notify The resend notify will resend all processing requests, so the INIT request is moved from processing list to pending list again. (3) calls fuse_dev_read() with an invalid output address fuse_dev_read() will try to copy the same INIT request to the output address, but it will fail due to the invalid address, so the INIT request is ended and triggers the warning in fuse_request_end(). Fix it by clearing FR_SENT when re-adding requests into pending list. Acked-by: Miklos Szeredi Reported-by: xingwei lee Reported-by: yue sun Closes: https://lore.kernel.org/linux-fsdevel/58f13e47-4765-fce4-daf4-dffcc5ae2330@huaweicloud.com/T/#m091614e5ea2af403b259e7cea6a49e51b9ee07a7 Fixes: 760eac73f9f6 ("fuse: Introduce a new notification type for resend pending requests") Signed-off-by: Hou Tao Signed-off-by: Miklos Szeredi Signed-off-by: Sasha Levin commit a0c290ddc20f846c89d2470828e65b01afaf685c Author: Hou Tao Date: Thu May 9 20:21:53 2024 +0800 fuse: set FR_PENDING atomically in fuse_resend() [ Upstream commit 42815f8ac54c5113bf450ec4b7ccc5b62af0f6a7 ] When fuse_resend() moves the requests from processing lists to pending list, it uses __set_bit() to set FR_PENDING bit in req->flags. Using __set_bit() is not safe, because other functions may update req->flags concurrently (e.g., request_wait_answer() may call set_bit(FR_INTERRUPTED, &flags)). Fix it by using set_bit() instead. Fixes: 760eac73f9f6 ("fuse: Introduce a new notification type for resend pending requests") Signed-off-by: Hou Tao Signed-off-by: Miklos Szeredi Signed-off-by: Sasha Levin commit 5268241b41b1c5d0acca75e9b97d4fd719251c8c Author: Chao Yu Date: Fri May 10 11:33:39 2024 +0800 f2fs: compress: don't allow unaligned truncation on released compress inode [ Upstream commit 29ed2b5dd521ce7c5d8466cd70bf0cc9d07afeee ] f2fs image may be corrupted after below testcase: - mkfs.f2fs -O extra_attr,compression -f /dev/vdb - mount /dev/vdb /mnt/f2fs - touch /mnt/f2fs/file - f2fs_io setflags compression /mnt/f2fs/file - dd if=/dev/zero of=/mnt/f2fs/file bs=4k count=4 - f2fs_io release_cblocks /mnt/f2fs/file - truncate -s 8192 /mnt/f2fs/file - umount /mnt/f2fs - fsck.f2fs /dev/vdb [ASSERT] (fsck_chk_inode_blk:1256) --> ino: 0x5 has i_blocks: 0x00000002, but has 0x3 blocks [FSCK] valid_block_count matching with CP [Fail] [0x4, 0x5] [FSCK] other corrupted bugs [Fail] The reason is: partial truncation assume compressed inode has reserved blocks, after partial truncation, valid block count may change w/o .i_blocks and .total_valid_block_count update, result in corruption. This patch only allow cluster size aligned truncation on released compress inode for fixing. Fixes: c61404153eb6 ("f2fs: introduce FI_COMPRESS_RELEASED instead of using IMMUTABLE bit") Signed-off-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit 06f3d7e4605adaa23281c1143f87e41ba6bfaa63 Author: Chao Yu Date: Tue May 7 11:31:00 2024 +0800 f2fs: fix to release node block count in error path of f2fs_new_node_page() [ Upstream commit 0fa4e57c1db263effd72d2149d4e21da0055c316 ] It missed to call dec_valid_node_count() to release node block count in error path, fix it. Fixes: 141170b759e0 ("f2fs: fix to avoid use f2fs_bug_on() in f2fs_new_node_page()") Signed-off-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit 69136304fd144144a4828c7b7b149d0f80321ba4 Author: Chao Yu Date: Mon May 6 18:41:39 2024 +0800 f2fs: compress: fix to cover {reserve,release}_compress_blocks() w/ cp_rwsem lock [ Upstream commit 0a4ed2d97cb6d044196cc3e726b6699222b41019 ] It needs to cover {reserve,release}_compress_blocks() w/ cp_rwsem lock to avoid racing with checkpoint, otherwise, filesystem metadata including blkaddr in dnode, inode fields and .total_valid_block_count may be corrupted after SPO case. Fixes: ef8d563f184e ("f2fs: introduce F2FS_IOC_RELEASE_COMPRESS_BLOCKS") Fixes: c75488fb4d82 ("f2fs: introduce F2FS_IOC_RESERVE_COMPRESS_BLOCKS") Signed-off-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit 57e61036bd8fb82d4bb5392d482e1a49340a9706 Author: Chao Yu Date: Mon May 6 18:41:37 2024 +0800 f2fs: compress: fix error path of inc_valid_block_count() [ Upstream commit 043c832371cd9023fbd725138ddc6c7f288dc469 ] If inc_valid_block_count() can not allocate all requested blocks, it needs to release block count in .total_valid_block_count and resevation blocks in inode. Fixes: 54607494875e ("f2fs: compress: fix to avoid inconsistence bewteen i_blocks and dnode") Signed-off-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit f7051d9557997079e20493b5bad7dbdf82678a9d Author: Chao Yu Date: Mon May 6 18:41:36 2024 +0800 f2fs: compress: fix to update i_compr_blocks correctly [ Upstream commit 186e7d71534df4589405925caca5597af7626c12 ] Previously, we account reserved blocks and compressed blocks into @compr_blocks, then, f2fs_i_compr_blocks_update(,compr_blocks) will update i_compr_blocks incorrectly, fix it. Meanwhile, for the case all blocks in cluster were reserved, fix to update dn->ofs_in_node correctly. Fixes: eb8fbaa53374 ("f2fs: compress: fix to check unreleased compressed cluster") Signed-off-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit 870535ca0319670308807560ccfd3d0b34dc4373 Author: James Clark Date: Tue May 7 15:12:08 2024 +0100 perf symbols: Fix ownership of string in dso__load_vmlinux() [ Upstream commit 25626e19ae6df34f336f235b6b3dbd1b566d2738 ] The linked commit updated dso__load_vmlinux() to call dso__set_long_name() before loading the symbols. Loading the symbols may not succeed but dso__set_long_name() takes ownership of the string. The two callers of this function free the string themselves on failure cases, resulting in the following error: $ perf record -- ls $ perf report free(): double free detected in tcache 2 Fix it by always taking ownership of the string, even on failure. This means the string is either freed at the very first early exit condition, or later when the dso is deleted or the long name is replaced. Now no special return value is needed to signify that the caller needs to free the string. Fixes: e59fea47f83e8a9a ("perf symbols: Fix DSO kernel load and symbol process to correctly map DSO to its long_name, type and adjust_symbols") Reviewed-by: Ian Rogers Signed-off-by: James Clark Cc: Adrian Hunter Cc: Alexander Shishkin Cc: Athira Rajeev Cc: Ingo Molnar Cc: Jiri Olsa Cc: Mark Rutland Cc: Namhyung Kim Cc: Peter Zijlstra Link: https://lore.kernel.org/r/20240507141210.195939-5-james.clark@arm.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 53ba56e438ef7c88d6948d4294a807a5e581fb1b Author: James Clark Date: Tue May 7 15:12:07 2024 +0100 perf symbols: Update kcore map before merging in remaining symbols [ Upstream commit f30232b20fadea8c0f2f43f764bc06e51e8cfcdf ] When loading kcore, the main vmlinux map is updated in the same loop that merges the remaining maps. If a map that overlaps is merged in before kcore, the list can become unsortable when the main map addresses are updated. This will later trigger the check_invariants() assert: $ perf record $ perf report util/maps.c:96: check_invariants: Assertion `map__end(prev) <= map__start(map) || map__start(prev) == map__start(map)' failed. Aborted Fix it by moving the main map update prior to the loop so that maps__merge_in() can split it if necessary. Fixes: 659ad3492b913c90 ("perf maps: Switch from rbtree to lazily sorted array for addresses") Signed-off-by: James Clark Cc: Adrian Hunter Cc: Alexander Shishkin Cc: Athira Rajeev Cc: Ian Rogers Cc: Ingo Molnar Cc: Jiri Olsa Cc: Mark Rutland Cc: Namhyung Kim Cc: Peter Zijlstra Link: https://lore.kernel.org/r/20240507141210.195939-4-james.clark@arm.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 253738a2e59681eb1c6772c385b7b81d675f7718 Author: James Clark Date: Tue May 7 15:12:05 2024 +0100 perf symbols: Remove map from list before updating addresses [ Upstream commit 9fe410a7ef483a9aca08bf620d8ddfd35ac99bc7 ] Make the order of operations remove, update, add. Updating addresses before the map is removed causes the ordering check to fail when the map is removed. This can be reproduced when running Perf on an Arm system with a static kernel and Perf uses kcore rather than other sources: $ perf record -- ls $ perf report util/maps.c:96: check_invariants: Assertion `map__end(prev) <= map__start(map) || map__start(prev) == map__start(map)' failed Fixes: 659ad3492b913c90 ("perf maps: Switch from rbtree to lazily sorted array for addresses") Signed-off-by: James Clark Cc: Adrian Hunter Cc: Alexander Shishkin Cc: Athira Rajeev Cc: Ian Rogers Cc: Ingo Molnar Cc: Jiri Olsa Cc: Mark Rutland Cc: Namhyung Kim Cc: Peter Zijlstra Link: https://lore.kernel.org/r/20240507141210.195939-2-james.clark@arm.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit b9684ba58ea31b9b00806b54a860b1db2392187e Author: James Clark Date: Wed May 8 15:14:57 2024 +0100 perf dwarf-aux: Fix build with HAVE_DWARF_CFI_SUPPORT [ Upstream commit c9d492378faec5c1fb8ea1534c620f7320bbb23a ] check_allowed_ops() is used from both HAVE_DWARF_GETLOCATIONS_SUPPORT and HAVE_DWARF_CFI_SUPPORT sections, so move it into the right place so that it's available when either are defined. This shows up when doing a static cross compile for arm64: $ make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- LDFLAGS="-static" \ EXTRA_PERFLIBS="-lexpat" util/dwarf-aux.c:1723:6: error: implicit declaration of function 'check_allowed_ops' Fixes: 55442cc2f22d0727 ("perf dwarf-aux: Check allowed DWARF Ops") Reviewed-by: Ian Rogers Signed-off-by: James Clark Acked-by: Masami Hiramatsu Acked-by: Namhyung Kim Cc: Adrian Hunter Cc: Alexander Shishkin Cc: Ingo Molnar Cc: Jiri Olsa Cc: Leo Yan Cc: Mark Rutland Cc: Namhyung Kim Cc: Peter Zijlstra Link: https://lore.kernel.org/r/20240508141458.439017-1-james.clark@arm.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 96064187ef85675ae4fdb67d9c7d17e8026a869a Author: Namhyung Kim Date: Mon Mar 18 22:50:54 2024 -0700 perf dwarf-aux: Add die_collect_vars() [ Upstream commit 932dcc2c39aedf54ef291bc0b4129a54f5fe1e84 ] The die_collect_vars() is to find all variable information in the scope including function parameters. The struct die_var_type is to save the type of the variable with the location (reg and offset) as well as where it's defined in the code (addr). Signed-off-by: Namhyung Kim Acked-by: Masami Hiramatsu Cc: Adrian Hunter Cc: Ian Rogers Cc: Ingo Molnar Cc: Jiri Olsa Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Stephane Eranian Link: https://lore.kernel.org/r/20240319055115.4063940-3-namhyung@kernel.org Signed-off-by: Arnaldo Carvalho de Melo Stable-dep-of: c9d492378fae ("perf dwarf-aux: Fix build with HAVE_DWARF_CFI_SUPPORT") Signed-off-by: Sasha Levin commit 3b210d94a522b77c26295e39e0dfb5f9d3a735cf Author: Ian Rogers Date: Tue May 7 20:53:01 2024 -0700 perf thread: Fixes to thread__new() related to initializing comm [ Upstream commit 3536c2575e88a890cf696b4ccd3da36bc937853b ] Freeing the thread on failure won't work with reference count checking, use thread__delete(). Don't allocate the comm_str, use a stack allocation instead. Fixes: f6005cafebab72f8 ("perf thread: Add reference count checking") Signed-off-by: Ian Rogers Cc: Adrian Hunter Cc: Alexander Shishkin Cc: Ingo Molnar Cc: James Clark Cc: Jiri Olsa Cc: Kan Liang Cc: Leo Yan Cc: Mark Rutland Cc: Namhyung Kim Cc: Peter Zijlstra Link: https://lore.kernel.org/r/20240508035301.1554434-5-irogers@google.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit d0fddddc1bcd5e7a309fa462b810c61df31898b9 Author: Ian Rogers Date: Tue May 7 20:53:00 2024 -0700 perf report: Avoid SEGV in report__setup_sample_type() [ Upstream commit 45b4f402a6b782352c4bafcff682bfb01da9ca05 ] In some cases evsel->name is lazily initialized in evsel__name(). If not initialized passing NULL to strstr() leads to a SEGV. Fixes: ccb17caecfbd542f ("perf report: Set PERF_SAMPLE_DATA_SRC bit for Arm SPE event") Signed-off-by: Ian Rogers Cc: Adrian Hunter Cc: Alexander Shishkin Cc: Ingo Molnar Cc: James Clark Cc: Jiri Olsa Cc: Kan Liang Cc: Leo Yan Cc: Mark Rutland Cc: Namhyung Kim Cc: Peter Zijlstra Link: https://lore.kernel.org/r/20240508035301.1554434-4-irogers@google.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 0f9af3bc8deb8e9c6b093af33590cc8bc27c95a8 Author: Ian Rogers Date: Tue May 7 20:52:58 2024 -0700 perf ui browser: Avoid SEGV on title [ Upstream commit 90f01afb0dfafbc9b094bb61e61a4ac297d9d0d2 ] If the title is NULL then it can lead to a SEGV. Fixes: 769e6a1e15bdbbaf ("perf ui browser: Don't save pointer to stack memory") Signed-off-by: Ian Rogers Cc: Adrian Hunter Cc: Alexander Shishkin Cc: Ingo Molnar Cc: James Clark Cc: Jiri Olsa Cc: Kan Liang Cc: Leo Yan Cc: Mark Rutland Cc: Namhyung Kim Cc: Peter Zijlstra Link: https://lore.kernel.org/r/20240508035301.1554434-2-irogers@google.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 588161f49ba387b4c3119d93af3407375a2ee1a6 Author: Wu Bo Date: Sun Apr 28 21:51:42 2024 -0600 f2fs: fix block migration when section is not aligned to pow2 [ Upstream commit aa4074e8fec4d2e686daee627fcafb3503efe365 ] As for zoned-UFS, f2fs section size is forced to zone size. And zone size may not aligned to pow2. Fixes: 859fca6b706e ("f2fs: swap: support migrating swapfile in aligned write mode") Signed-off-by: Liao Yuanhong Signed-off-by: Wu Bo Reviewed-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit 5db8860bb2deb26f114cc6739d5bbe9d666a3b58 Author: Kuppuswamy Sathyanarayanan Date: Wed May 8 14:31:38 2024 -0500 PCI/EDR: Align EDR_PORT_LOCATE_DSM with PCI Firmware r3.3 [ Upstream commit e2e78a294a8a863898b781dbcf90e087eda3155d ] The "Downstream Port Containment related Enhancements" ECN of Jan 28, 2019 (document 12888 below), defined the EDR_PORT_LOCATE_DSM function with Revision ID 5 with a return value encoding (Bits 2:0 = Function, Bits 7:3 = Device, Bits 15:8 = Bus). When the ECN was integrated into PCI Firmware r3.3, sec 4.6.13, Bit 31 was added to indicate success or failure. Check Bit 31 for failure in acpi_dpc_port_get(). Link: https://lore.kernel.org/r/20240501022543.1626025-1-sathyanarayanan.kuppuswamy@linux.intel.com Link: https://members.pcisig.com/wg/PCI-SIG/document/12888 Fixes: ac1c8e35a326 ("PCI/DPC: Add Error Disconnect Recover (EDR) support") Signed-off-by: Kuppuswamy Sathyanarayanan [bhelgaas: split into two patches, update commit log] Signed-off-by: Bjorn Helgaas Tested-by: Satish Thatchanamurthy # one platform Signed-off-by: Sasha Levin commit 2fd6dc7a371191b9aea729d9b04fb0e5c9d0326d Author: Kuppuswamy Sathyanarayanan Date: Wed May 1 02:25:43 2024 +0000 PCI/EDR: Align EDR_PORT_DPC_ENABLE_DSM with PCI Firmware r3.3 [ Upstream commit f24ba846133d0edec785ac6430d4daf6e9c93a09 ] The "Downstream Port Containment related Enhancements" ECN of Jan 28, 2019 (document 12888 below), defined the EDR_PORT_DPC_ENABLE_DSM function with Revision ID 5 with Arg3 being an integer. But when the ECN was integrated into PCI Firmware r3.3, sec 4.6.12, it was defined as Revision ID 6 with Arg3 being a package containing an integer. The implementation in acpi_enable_dpc() supplies a package as Arg3 (arg4 in the code), but it previously specified Revision ID 5. Align this with PCI Firmware r3.3 by using Revision ID 6. If firmware implemented per the ECN, its Revision 5 function would receive a package as Arg3 when it expects an integer, so acpi_enable_dpc() would likely fail. If such firmware exists and lacks a Revision 6 function that expects a package, we may have to add support for Revision 5. Link: https://lore.kernel.org/r/20240501022543.1626025-1-sathyanarayanan.kuppuswamy@linux.intel.com Link: https://members.pcisig.com/wg/PCI-SIG/document/12888 Fixes: ac1c8e35a326 ("PCI/DPC: Add Error Disconnect Recover (EDR) support") Signed-off-by: Kuppuswamy Sathyanarayanan [bhelgaas: split into two patches, update commit log] Signed-off-by: Bjorn Helgaas Tested-by: Satish Thatchanamurthy # one platform Signed-off-by: Sasha Levin commit 217b057cdbeefb049fd00e39c088da573e0437a7 Author: Markus Elfring Date: Tue May 7 14:07:42 2024 -0700 spmi: pmic-arb: Replace three IS_ERR() calls by null pointer checks in spmi_pmic_arb_probe() [ Upstream commit c86f90e30a347ef0a28d0df3975c46389d0cc7fc ] The devm_ioremap() function does not return error pointers. It returns NULL on error. This issue was detected once more also by using the Coccinelle software. Update three checks (and corresponding error codes) for failed function calls accordingly. Fixes: ffdfbafdc4f4 ("spmi: Use devm_spmi_controller_alloc()") Fixes: 231601cd22bd ("spmi: pmic-arb: Add support for PMIC v7") Signed-off-by: Markus Elfring Link: https://lore.kernel.org/r/82a0768e-95b0-4091-bdd1-14c3e893726b@web.de Reviewed-by: Dmitry Baryshkov Reviewed-by: David Collins Reviewed-by: AngeloGioacchino Del Regno Signed-off-by: Stephen Boyd Link: https://lore.kernel.org/r/20240507210809.3479953-6-sboyd@kernel.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 79aaa740521220d9ada9485bdcf6315b78b9a1d3 Author: Randy Dunlap Date: Mon Feb 12 22:00:28 2024 -0800 extcon: max8997: select IRQ_DOMAIN instead of depending on it [ Upstream commit b1781d0a1458070d40134e4f3412ec9d70099bec ] IRQ_DOMAIN is a hidden (not user visible) symbol. Users cannot set it directly thru "make *config", so drivers should select it instead of depending on it if they need it. Relying on it being set for a dependency is risky. Consistently using "select" or "depends on" can also help reduce Kconfig circular dependency issues. Therefore, change EXTCON_MAX8997's use of "depends on" for IRQ_DOMAIN to "select". Link: https://lore.kernel.org/lkml/20240213060028.9744-1-rdunlap@infradead.org/ Fixes: dca1a71e4108 ("extcon: Add support irq domain for MAX8997 muic") Signed-off-by: Randy Dunlap Acked-by: Arnd Bergmann Signed-off-by: Chanwoo Choi Signed-off-by: Sasha Levin commit e4a7f29a7eead60fa3263018496dfb4c1fdf55d3 Author: Ian Rogers Date: Tue May 7 11:35:39 2024 -0700 perf annotate: Fix memory leak in annotated_source [ Upstream commit a3f7768bcf48281df14d98715f076c5656571527 ] Freeing hash map doesn't free the entries added to the hashmap, add the missing free(). Fixes: d3e7cad6f36d9e80 ("perf annotate: Add a hashmap for symbol histogram") Signed-off-by: Ian Rogers Cc: Adrian Hunter Cc: Alexander Shishkin Cc: Andi Kleen Cc: Athira Rajeev Cc: Ben Gainey Cc: Ingo Molnar Cc: James Clark Cc: Jiri Olsa Cc: Kajol Jain Cc: Kan Liang Cc: K Prateek Nayak Cc: Li Dong Cc: Mark Rutland Cc: Namhyung Kim Cc: Oliver Upton Cc: Paran Lee Cc: Peter Zijlstra Cc: Ravi Bangoria Cc: Sun Haiyong Cc: Tim Chen Cc: Yanteng Si Cc: Yicong Yang Link: https://lore.kernel.org/r/20240507183545.1236093-3-irogers@google.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 2f0d8e230841af6a404914a5c901877fc0647c43 Author: Ian Rogers Date: Tue May 7 11:35:38 2024 -0700 perf ui browser: Don't save pointer to stack memory [ Upstream commit 769e6a1e15bdbbaf2b0d2f37c24f2c53268bd21f ] ui_browser__show() is capturing the input title that is stack allocated memory in hist_browser__run(). Avoid a use after return by strdup-ing the string. Committer notes: Further explanation from Ian Rogers: My command line using tui is: $ sudo bash -c 'rm /tmp/asan.log*; export ASAN_OPTIONS="log_path=/tmp/asan.log"; /tmp/perf/perf mem record -a sleep 1; /tmp/perf/perf mem report' I then go to the perf annotate view and quit. This triggers the asan error (from the log file): ``` ==1254591==ERROR: AddressSanitizer: stack-use-after-return on address 0x7f2813331920 at pc 0x7f28180 65991 bp 0x7fff0a21c750 sp 0x7fff0a21bf10 READ of size 80 at 0x7f2813331920 thread T0 #0 0x7f2818065990 in __interceptor_strlen ../../../../src/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:461 #1 0x7f2817698251 in SLsmg_write_wrapped_string (/lib/x86_64-linux-gnu/libslang.so.2+0x98251) #2 0x7f28176984b9 in SLsmg_write_nstring (/lib/x86_64-linux-gnu/libslang.so.2+0x984b9) #3 0x55c94045b365 in ui_browser__write_nstring ui/browser.c:60 #4 0x55c94045c558 in __ui_browser__show_title ui/browser.c:266 #5 0x55c94045c776 in ui_browser__show ui/browser.c:288 #6 0x55c94045c06d in ui_browser__handle_resize ui/browser.c:206 #7 0x55c94047979b in do_annotate ui/browsers/hists.c:2458 #8 0x55c94047fb17 in evsel__hists_browse ui/browsers/hists.c:3412 #9 0x55c940480a0c in perf_evsel_menu__run ui/browsers/hists.c:3527 #10 0x55c940481108 in __evlist__tui_browse_hists ui/browsers/hists.c:3613 #11 0x55c9404813f7 in evlist__tui_browse_hists ui/browsers/hists.c:3661 #12 0x55c93ffa253f in report__browse_hists tools/perf/builtin-report.c:671 #13 0x55c93ffa58ca in __cmd_report tools/perf/builtin-report.c:1141 #14 0x55c93ffaf159 in cmd_report tools/perf/builtin-report.c:1805 #15 0x55c94000c05c in report_events tools/perf/builtin-mem.c:374 #16 0x55c94000d96d in cmd_mem tools/perf/builtin-mem.c:516 #17 0x55c9400e44ee in run_builtin tools/perf/perf.c:350 #18 0x55c9400e4a5a in handle_internal_command tools/perf/perf.c:403 #19 0x55c9400e4e22 in run_argv tools/perf/perf.c:447 #20 0x55c9400e53ad in main tools/perf/perf.c:561 #21 0x7f28170456c9 in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 #22 0x7f2817045784 in __libc_start_main_impl ../csu/libc-start.c:360 #23 0x55c93ff544c0 in _start (/tmp/perf/perf+0x19a4c0) (BuildId: 84899b0e8c7d3a3eaa67b2eb35e3d8b2f8cd4c93) Address 0x7f2813331920 is located in stack of thread T0 at offset 32 in frame #0 0x55c94046e85e in hist_browser__run ui/browsers/hists.c:746 This frame has 1 object(s): [32, 192) 'title' (line 747) <== Memory access at offset 32 is inside this variable HINT: this may be a false positive if your program uses some custom stack unwind mechanism, swapcontext or vfork ``` hist_browser__run isn't on the stack so the asan error looks legit. There's no clean init/exit on struct ui_browser so I may be trading a use-after-return for a memory leak, but that seems look a good trade anyway. Fixes: 05e8b0804ec4 ("perf ui browser: Stop using 'self'") Signed-off-by: Ian Rogers Cc: Adrian Hunter Cc: Alexander Shishkin Cc: Andi Kleen Cc: Athira Rajeev Cc: Ben Gainey Cc: Ingo Molnar Cc: James Clark Cc: Jiri Olsa Cc: Kajol Jain Cc: Kan Liang Cc: K Prateek Nayak Cc: Li Dong Cc: Mark Rutland Cc: Namhyung Kim Cc: Oliver Upton Cc: Paran Lee Cc: Peter Zijlstra Cc: Ravi Bangoria Cc: Sun Haiyong Cc: Tim Chen Cc: Yanteng Si Cc: Yicong Yang Link: https://lore.kernel.org/r/20240507183545.1236093-2-irogers@google.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit e70ad7979baaff56ba08e6e188c30e713ddd48c8 Author: He Zhe Date: Tue May 7 14:50:26 2024 +0800 perf bench internals inject-build-id: Fix trap divide when collecting just one DSO [ Upstream commit d9180e23fbfa3875424d3a6b28b71b072862a52a ] 'perf bench internals inject-build-id' suffers from the following error when only one DSO is collected. # perf bench internals inject-build-id -v Collected 1 DSOs traps: internals-injec[2305] trap divide error ip:557566ba6394 sp:7ffd4de97fe0 error:0 in perf[557566b2a000+23d000] Build-id injection benchmark Iteration #1 Floating point exception This patch removes the unnecessary minus one from the divisor which also corrects the randomization range. Signed-off-by: He Zhe Fixes: 0bf02a0d80427f26 ("perf bench: Add build-id injection benchmark") Cc: Adrian Hunter Cc: Alexander Shishkin Cc: Ian Rogers Cc: Jiri Olsa Cc: Mark Rutland Cc: Namhyung Kim Link: https://lore.kernel.org/r/20240507065026.2652929-1-zhe.he@windriver.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit fb010ba79c545da5b2da6d524014afc9951ca522 Author: Christophe JAILLET Date: Sat Jan 6 13:48:24 2024 +0100 i2c: synquacer: Fix an error handling path in synquacer_i2c_probe() [ Upstream commit 55750148e5595bb85605e8fbb40b2759c2c4c2d7 ] If an error occurs after the clk_prepare_enable() call, it should be undone by a corresponding clk_disable_unprepare() call, as already done in the remove() function. As devm_clk_get() is used, we can switch to devm_clk_get_enabled() to handle it automatically and fix the probe. Update the remove() function accordingly and remove the now useless clk_disable_unprepare() call. Fixes: 0d676a6c4390 ("i2c: add support for Socionext SynQuacer I2C controller") Signed-off-by: Christophe JAILLET Acked-by: Ard Biesheuvel Signed-off-by: Andi Shyti Signed-off-by: Sasha Levin commit 675a3ace6b9b961ed85b90a302f2bead00eb06ce Author: Sai Pavan Boddu Date: Fri May 3 15:12:08 2024 +0530 i2c: cadence: Avoid fifo clear after start [ Upstream commit c2e55b449de7298a751ed0256251019d302af453 ] The Driver unintentionally programs ctrl reg to clear the fifo, which happens after the start of transaction. Previously, this was not an issue as it involved read-modified-write. However, this issue breaks i2c reads on QEMU, as i2c-read is executed before guest starts programming control register. Fixes: ff0cf7bca630 ("i2c: cadence: Remove unnecessary register reads") Signed-off-by: Sai Pavan Boddu Acked-by: Michal Simek Signed-off-by: Andi Shyti Signed-off-by: Sasha Levin commit 5d5b24edad1107a2ffa99058f20f6aeeafeb5d39 Author: Huai-Yuan Liu Date: Fri Apr 12 16:38:40 2024 +0800 ppdev: Add an error check in register_device [ Upstream commit fbf740aeb86a4fe82ad158d26d711f2f3be79b3e ] In register_device, the return value of ida_simple_get is unchecked, in witch ida_simple_get will use an invalid index value. To address this issue, index should be checked after ida_simple_get. When the index value is abnormal, a warning message should be printed, the port should be dropped, and the value should be recorded. Fixes: 9a69645dde11 ("ppdev: fix registering same device name") Signed-off-by: Huai-Yuan Liu Link: https://lore.kernel.org/r/20240412083840.234085-1-qq810974084@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit d782a2db8f7ac49c33b9ca3e835500a28667d1be Author: Dan Carpenter Date: Mon Apr 29 16:01:05 2024 +0300 stm class: Fix a double free in stm_register_device() [ Upstream commit 3df463865ba42b8f88a590326f4c9ea17a1ce459 ] The put_device(&stm->dev) call will trigger stm_device_release() which frees "stm" so the vfree(stm) on the next line is a double free. Fixes: 389b6699a2aa ("stm class: Fix stm device initialization order") Signed-off-by: Dan Carpenter Reviewed-by: Amelie Delaunay Reviewed-by: Andy Shevchenko Signed-off-by: Alexander Shishkin Link: https://lore.kernel.org/r/20240429130119.1518073-2-alexander.shishkin@linux.intel.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit fe43ef87869fd356b3355101c66f7f95c7e176f3 Author: Chris Wulff Date: Thu Apr 25 15:20:20 2024 +0000 usb: gadget: u_audio: Clear uac pointer when freed. [ Upstream commit a2cf936ebef291ef7395172b9e2f624779fb6dc0 ] This prevents use of a stale pointer if functions are called after g_cleanup that shouldn't be. This doesn't fix any races, but converts a possibly silent kernel memory corruption into an obvious NULL pointer dereference report. Fixes: eb9fecb9e69b ("usb: gadget: f_uac2: split out audio core") Signed-off-by: Chris Wulff Link: https://lore.kernel.org/stable/CO1PR17MB54194226DA08BFC9EBD8C163E1172%40CO1PR17MB5419.namprd17.prod.outlook.com Link: https://lore.kernel.org/r/CO1PR17MB54194226DA08BFC9EBD8C163E1172@CO1PR17MB5419.namprd17.prod.outlook.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit bea73b58ab67fe581037ad9cdb93c2557590c068 Author: Chris Wulff Date: Thu Apr 25 15:18:01 2024 +0000 usb: gadget: u_audio: Fix race condition use of controls after free during gadget unbind. [ Upstream commit 1b739388aa3f8dfb63a9fca777e6dfa6912d0464 ] Hang on to the control IDs instead of pointers since those are correctly handled with locks. Fixes: 8fe9a03f4331 ("usb: gadget: u_audio: Rate ctl notifies about current srate (0=stopped)") Fixes: c565ad07ef35 ("usb: gadget: u_audio: Support multiple sampling rates") Fixes: 02de698ca812 ("usb: gadget: u_audio: add bi-directional volume and mute support") Signed-off-by: Chris Wulff Link: https://lore.kernel.org/stable/CO1PR17MB5419C2BF44D400E4E620C1ADE1172%40CO1PR17MB5419.namprd17.prod.outlook.com Link: https://lore.kernel.org/r/CO1PR17MB5419C2BF44D400E4E620C1ADE1172@CO1PR17MB5419.namprd17.prod.outlook.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 15edb906211bf53e7b5574f7326ab734d6bff4f9 Author: Fenghua Yu Date: Mon Jan 29 17:39:54 2024 -0800 dmaengine: idxd: Avoid unnecessary destruction of file_ida [ Upstream commit 76e43fa6a456787bad31b8d0daeabda27351a480 ] file_ida is allocated during cdev open and is freed accordingly during cdev release. This sequence is guaranteed by driver file operations. Therefore, there is no need to destroy an already empty file_ida when the WQ cdev is removed. Worse, ida_free() in cdev release may happen after destruction of file_ida per WQ cdev. This can lead to accessing an id in file_ida after it has been destroyed, resulting in a kernel panic. Remove ida_destroy(&file_ida) to address these issues. Fixes: e6fd6d7e5f0f ("dmaengine: idxd: add a device to represent the file opened") Signed-off-by: Lijun Pan Signed-off-by: Fenghua Yu Reviewed-by: Dave Jiang Link: https://lore.kernel.org/r/20240130013954.2024231-1-fenghua.yu@intel.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit ad852483eb3905b5ddc55bc72ddcb26de9da929b Author: Dmitry Baryshkov Date: Wed May 1 19:19:29 2024 +0300 dt-bindings: phy: qcom,usb-snps-femto-v2: use correct fallback for sc8180x [ Upstream commit 960b3f023d3bda0efd6e573a0647227d1115d266 ] The qcom,sc8180x-usb-hs-phy device uses qcom,usb-snps-hs-7nm-phy fallback. Correct the schema for this platform. Fixes: 9160fb7c39a1 ("dt-bindings: phy: qcom,usb-snps-femto-v2: use fallback compatibles") Signed-off-by: Dmitry Baryshkov Acked-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/20240501-qcom-phy-fixes-v1-3-f1fd15c33fb3@linaro.org Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit f19c2b0e9fdc758f9504ff6593ff5ac7fed1512b Author: Dmitry Baryshkov Date: Wed May 1 19:19:28 2024 +0300 dt-bindings: phy: qcom,sc8280xp-qmp-ufs-phy: fix msm899[68] power-domains [ Upstream commit 59e377a124dc9039d9554d823b1cb4942bcee9a0 ] The Qualcomm MSM8996 and MSM8998 platforms don't have separate power domain for the UFS PHY. Replace required:power-domains with the conditional schema. Fixes: dc5cb63592bd ("dt-bindings: phy: migrate QMP UFS PHY bindings to qcom,sc8280xp-qmp-ufs-phy.yaml") Signed-off-by: Dmitry Baryshkov Reviewed-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/20240501-qcom-phy-fixes-v1-2-f1fd15c33fb3@linaro.org Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit ad855902d2d4f278ce992d646fd87f4a3b4474b6 Author: Dmitry Baryshkov Date: Wed May 1 19:19:27 2024 +0300 dt-bindings: phy: qcom,sc8280xp-qmp-pcie-phy: fix x1e80100-gen3x2 schema [ Upstream commit 484b139a4cd7e629f8fcb43d71997f400c5b8537 ] The qcom,x1e80100-qmp-gen3x2-pcie-phy device doesn't have second reset, drop it from the clause enforcing second reset to be used. Fixes: e94b29f2bd73 ("dt-bindings: phy: qcom,sc8280xp-qmp-pcie-phy: Document the X1E80100 QMP PCIe PHYs") Signed-off-by: Dmitry Baryshkov Acked-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/20240501-qcom-phy-fixes-v1-1-f1fd15c33fb3@linaro.org Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 7f39ab718c3894947c965a4045f09e4ea8a82ee4 Author: Chen Ni Date: Fri Apr 26 15:58:08 2024 +0800 watchdog: sa1100: Fix PTR_ERR_OR_ZERO() vs NULL check in sa1100dog_probe() [ Upstream commit 413bf4e857fd79617524d5dcd35f463e9aa2dd41 ] devm_ioremap() doesn't return error pointers, it returns NULL on error. Update the check accordingly. Fixes: e86bd43bcfc5 ("watchdog: sa1100: use platform device registration") Signed-off-by: Chen Ni Reviewed-by: Guenter Roeck Link: https://lore.kernel.org/r/20240426075808.1582678-1-nichen@iscas.ac.cn Signed-off-by: Guenter Roeck Signed-off-by: Wim Van Sebroeck Signed-off-by: Sasha Levin commit e843ea8605b1e8dd62eabbd44d7e9dc2f693d5d0 Author: Matti Vaittinen Date: Mon Apr 8 13:02:31 2024 +0300 watchdog: bd9576: Drop "always-running" property [ Upstream commit e3b3afd34d84efcbe4543deb966b1990f43584b8 ] The always-running (from linux,wdt-gpio.yaml) is abused by the BD9576 watchdog driver. It's defined meaning is "the watchdog is always running and can not be stopped". The BD9576 watchdog driver has implemented it as "start watchdog when loading the module and prevent it from being stopped". Furthermore, the implementation does not set the WDOG_HW_RUNNING when enabling the watchdog due to the "always-running" at module loading. This will end up resulting a watchdog timeout if the device is not opened. The culprit was pointed out by Guenter, discussion can be found from https://lore.kernel.org/lkml/4fa3a64b-60fb-4e5e-8785-0f14da37eea2@roeck-us.net/ Drop the invalid "always-running" handling. Signed-off-by: Matti Vaittinen Reported-by: Guenter Roeck Fixes: b237bcac557a ("wdt: Support wdt on ROHM BD9576MUF and BD9573MUF") Reviewed-by: Guenter Roeck Link: https://lore.kernel.org/r/ZhPAt76yaJMersXf@fedora Signed-off-by: Guenter Roeck Signed-off-by: Wim Van Sebroeck Signed-off-by: Sasha Levin commit f19686d616500cd0d47b30cee82392b53f7f784a Author: Duoming Zhou Date: Sun Mar 24 22:04:44 2024 +0800 watchdog: cpu5wdt.c: Fix use-after-free bug caused by cpu5wdt_trigger [ Upstream commit 573601521277119f2e2ba5f28ae6e87fc594f4d4 ] When the cpu5wdt module is removing, the origin code uses del_timer() to de-activate the timer. If the timer handler is running, del_timer() could not stop it and will return directly. If the port region is released by release_region() and then the timer handler cpu5wdt_trigger() calls outb() to write into the region that is released, the use-after-free bug will happen. Change del_timer() to timer_shutdown_sync() in order that the timer handler could be finished before the port region is released. Fixes: e09d9c3e9f85 ("watchdog: cpu5wdt.c: add missing del_timer call") Signed-off-by: Duoming Zhou Reviewed-by: Guenter Roeck Link: https://lore.kernel.org/r/20240324140444.119584-1-duoming@zju.edu.cn Signed-off-by: Guenter Roeck Signed-off-by: Wim Van Sebroeck Signed-off-by: Sasha Levin commit 8dbcb3a8cfdf8ff5afce62dad50790278ff0d3b7 Author: Marius Cristea Date: Thu Apr 25 14:42:32 2024 +0300 iio: adc: PAC1934: fix accessing out of bounds array index [ Upstream commit 51fafb3cd7fcf4f4682693b4d2883e2a5bfffe33 ] Fix accessing out of bounds array index for average current and voltage measurements. The device itself has only 4 channels, but in sysfs there are "fake" channels for the average voltages and currents too. Fixes: 0fb528c8255b ("iio: adc: adding support for PAC193x") Reported-by: Conor Dooley Signed-off-by: Marius Cristea Closes: https://lore.kernel.org/linux-iio/20240405-embellish-bonnet-ab5f10560d93@wendy/ Tested-by: Conor Dooley Link: https://lore.kernel.org/r/20240425114232.81390-1-marius.cristea@microchip.com Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit 54dd425767c3858933923f7ed59c04fab5cb163e Author: Danila Tikhonov Date: Tue Apr 23 23:32:45 2024 +0300 pinctrl: qcom: pinctrl-sm7150: Fix sdc1 and ufs special pins regs [ Upstream commit 5ed79863fae5c06eb33f5cd6b6bdf22dd7089392 ] SDC1 and UFS_RESET special pins are located in the west memory bank. SDC1 have address 0x359a000: 0x3500000 (TLMM BASE) + 0x0 (WEST) + 0x9a000 (SDC1_OFFSET) = 0x359a000 UFS_RESET have address 0x359f000: 0x3500000 (TLMM BASE) + 0x0 (WEST) + 0x9f000 (UFS_OFFSET) = 0x359a000 Fixes: b915395c9e04 ("pinctrl: qcom: Add SM7150 pinctrl driver") Signed-off-by: Danila Tikhonov Message-ID: <20240423203245.188480-1-danila@jiaxyga.com> Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit c0197ee35ca96faf0211f76571de5049903ccfbe Author: Rafał Miłecki Date: Tue Apr 23 06:55:01 2024 +0200 dt-bindings: pinctrl: mediatek: mt7622: fix array properties [ Upstream commit 61fcbbf3ca038c048c942ce31bb3d3c846c87581 ] Some properties (function groups & pins) are meant to be arrays and should allow multiple entries out of enum sets. Use "items" for those. Mistake was noticed during validation of in-kernel DTS files. Fixes: b9ffc18c6388 ("dt-bindings: mediatek: convert pinctrl to yaml") Signed-off-by: Rafał Miłecki Acked-by: Rob Herring Message-ID: <20240423045502.7778-1-zajec5@gmail.com> Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit 1b0658fd5a0b2c13fd4634f323246637b9e734fa Author: Christophe JAILLET Date: Wed Apr 24 14:27:23 2024 +0200 VMCI: Fix an error handling path in vmci_guest_probe_device() [ Upstream commit 73df3d6f2e9533e93a5039a33c40dd7216b81801 ] After a successful pci_iomap_range() call, pci_iounmap() should be called in the error handling path, as already done in the remove function. Add the missing call. The corresponding call was added in the remove function in commit 5ee109828e73 ("VMCI: dma dg: allocate send and receive buffers for DMA datagrams") Fixes: e283a0e8b7ea ("VMCI: dma dg: add MMIO access to registers") Signed-off-by: Christophe JAILLET Acked-by: Vishnu Dasa Link: https://lore.kernel.org/r/a35bbc3876ae1da70e49dafde4435750e1477be3.1713961553.git.christophe.jaillet@wanadoo.fr Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 598e4a37a2f8da9144ba1fab04320c32169b6d0d Author: Duoming Zhou Date: Sun Mar 3 18:57:29 2024 +0800 PCI: of_property: Return error for int_map allocation failure [ Upstream commit e6f7d27df5d208b50cae817a91d128fb434bb12c ] Return -ENOMEM from of_pci_prop_intr_map() if kcalloc() fails to prevent a NULL pointer dereference in this case. Fixes: 407d1a51921e ("PCI: Create device tree node for bridge") Link: https://lore.kernel.org/r/20240303105729.78624-1-duoming@zju.edu.cn Signed-off-by: Duoming Zhou [bhelgaas: commit log] Signed-off-by: Bjorn Helgaas Signed-off-by: Sasha Levin commit 6da89468dfa90cdea635db5c54a3976a8f89b71e Author: Miklos Szeredi Date: Thu May 2 20:35:57 2024 +0200 ovl: remove upper umask handling from ovl_create_upper() [ Upstream commit 096802748ea1dea8b476938e0a8dc16f4bd2f1ad ] This is already done by vfs_prepare_mode() when creating the upper object by vfs_create(), vfs_mkdir() and vfs_mknod(). No regressions have been observed in xfstests run with posix acls turned off for the upper filesystem. Fixes: 1639a49ccdce ("fs: move S_ISGID stripping into the vfs_*() helpers") Signed-off-by: Miklos Szeredi Signed-off-by: Sasha Levin commit 0aa72290ec170da8a8c57fc138442503fbf7bb71 Author: Uwe Kleine-König Date: Wed Apr 17 17:38:47 2024 +0200 leds: pwm: Disable PWM when going to suspend [ Upstream commit 974afccd37947a6951a052ef8118c961e57eaf7b ] On stm32mp1xx based machines (and others) a PWM consumer has to disable the PWM because an enabled PWM refuses to suspend. So check the LED_SUSPENDED flag and depending on that set the .enabled property. Link: https://bugzilla.kernel.org/show_bug.cgi?id=218559 Fixes: 76fe464c8e64 ("leds: pwm: Don't disable the PWM when the LED should be off") Signed-off-by: Uwe Kleine-König Link: https://lore.kernel.org/r/20240417153846.271751-2-u.kleine-koenig@pengutronix.de Signed-off-by: Lee Jones Signed-off-by: Sasha Levin commit f39f4626bd13b330d9fcb2165e09be983198ce8e Author: Niklas Neronin Date: Mon Apr 29 17:02:30 2024 +0300 usb: xhci: check if 'requested segments' exceeds ERST capacity [ Upstream commit db4460b6ecf07574d580f01cd88054a62607068c ] Check if requested segments ('segs' or 'ERST_DEFAULT_SEGS') exceeds the maximum amount ERST supports. When 'segs' is '0', 'ERST_DEFAULT_SEGS' is used instead. But both values may not exceed ERST max. Macro 'ERST_MAX_SEGS' is renamed to 'ERST_DEFAULT_SEGS'. The new name better represents the macros, which is the number of Event Ring segments to allocate, when the amount is not specified. Additionally, rename and change xhci_create_secondary_interrupter()'s argument 'int num_segs' to 'unsigned int segs'. This makes it the same as its counter part in xhci_alloc_interrupter(). Fixes: c99b38c41234 ("xhci: add support to allocate several interrupters") Signed-off-by: Niklas Neronin Signed-off-by: Mathias Nyman Link: https://lore.kernel.org/r/20240429140245.3955523-4-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 2a4e107feb81a87ca90c96d01b7d04ed4798d860 Author: Ramona Gradinariu Date: Wed Apr 24 12:41:52 2024 +0300 docs: iio: adis16475: fix device files tables [ Upstream commit c19f273cae8ac785f83345f6eb2b2813d35ec148 ] Remove in_accel_calibbias_x and in_anglvel_calibbias_x device files description, as they do not exist and were added by mistake. Add correct naming for in_accel_y_calibbias and in_anglvel_y_calibbias device files and update their description. Fixes: 8243b2877eef ("docs: iio: add documentation for adis16475 driver") Signed-off-by: Ramona Gradinariu Link: https://lore.kernel.org/r/20240424094152.103667-2-ramona.gradinariu@analog.com Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit b48c993450c42328a435e253db6e470406b40b23 Author: Samuel Holland Date: Tue Mar 26 21:49:42 2024 -0700 riscv: Flush the instruction cache during SMP bringup [ Upstream commit 58661a30f1bcc748475ffd9be6d2fc9e4e6be679 ] Instruction cache flush IPIs are sent only to CPUs in cpu_online_mask, so they will not target a CPU until it calls set_cpu_online() earlier in smp_callin(). As a result, if instruction memory is modified between the CPU coming out of reset and that point, then its instruction cache may contain stale data. Therefore, the instruction cache must be flushed after the set_cpu_online() synchronization point. Fixes: 08f051eda33b ("RISC-V: Flush I$ when making a dirty page executable") Reviewed-by: Alexandre Ghiti Signed-off-by: Samuel Holland Link: https://lore.kernel.org/r/20240327045035.368512-2-samuel.holland@sifive.com Signed-off-by: Palmer Dabbelt Signed-off-by: Sasha Levin commit 9f8d046ff326dd363957f4431196484f9a484604 Author: Adrian Hunter Date: Tue Mar 26 10:32:23 2024 +0200 perf intel-pt: Fix unassigned instruction op (discovered by MemorySanitizer) [ Upstream commit e101a05f79fd4ee3e89d2f3fb716493c33a33708 ] MemorySanitizer discovered instances where the instruction op value was not assigned.: WARNING: MemorySanitizer: use-of-uninitialized-value #0 0x5581c00a76b3 in intel_pt_sample_flags tools/perf/util/intel-pt.c:1527:17 Uninitialized value was stored to memory at #0 0x5581c005ddf8 in intel_pt_walk_insn tools/perf/util/intel-pt-decoder/intel-pt-decoder.c:1256:25 The op value is used to set branch flags for branch instructions encountered when walking the code, so fix by setting op to INTEL_PT_OP_OTHER in other cases. Fixes: 4c761d805bb2d2ea ("perf intel-pt: Fix intel_pt_fup_event() assumptions about setting state type") Reported-by: Ian Rogers Signed-off-by: Adrian Hunter Tested-by: Ian Rogers Cc: Jiri Olsa Cc: Namhyung Kim Closes: https://lore.kernel.org/linux-perf-users/20240320162619.1272015-1-irogers@google.com/ Link: https://lore.kernel.org/r/20240326083223.10883-1-adrian.hunter@intel.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 35e3f9e0f04fab309dabb0de168f5aa14a433cb6 Author: Ilpo Järvinen Date: Tue Apr 23 16:08:19 2024 +0300 PCI: Wait for Link Training==0 before starting Link retrain [ Upstream commit 73cb3a35f94db723c0211ad099bce55b2155e3f0 ] Two changes were made in link retraining logic independent of each other. The commit e7e39756363a ("PCI/ASPM: Avoid link retraining race") added a check to pcie_retrain_link() to ensure no Link Training is currently active to address the Implementation Note in PCIe r6.1 sec 7.5.3.7. At that time pcie_wait_for_retrain() only checked for the Link Training (LT) bit being cleared. The commit 680e9c47a229 ("PCI: Add support for polling DLLLA to pcie_retrain_link()") generalized pcie_wait_for_retrain() into pcie_wait_for_link_status() which can wait either for LT or the Data Link Layer Link Active (DLLLA) bit with 'use_lt' argument and supporting waiting for either cleared or set using 'active' argument. In the merge commit 1abb47390350 ("Merge branch 'pci/enumeration'"), those two divergent branches converged. The merge changed LT bit checking added in the commit e7e39756363a ("PCI/ASPM: Avoid link retraining race") to now wait for completion of any ongoing Link Training using DLLLA bit being set if 'use_lt' is false. When 'use_lt' is false, the pseudo-code steps of what occurs in pcie_retrain_link(): 1. Wait for DLLLA==1 2. Trigger link to retrain 3. Wait for DLLLA==1 Step 3 waits for the link to come up from the retraining triggered by Step 2. As Step 1 is supposed to wait for any ongoing retraining to end, using DLLLA also for it does not make sense because link training being active is still indicated using LT bit, not with DLLLA. Correct the pcie_wait_for_link_status() parameters in Step 1 to only wait for LT==0 to ensure there is no ongoing Link Training. This only impacts the Target Speed quirk, which is the only case where waiting for DLLLA bit is used. It currently works in the problematic case by means of link training getting initiated by hardware repeatedly and respecting the new link parameters set by the caller, which then make training succeed and bring the link up, setting DLLLA and causing pcie_wait_for_link_status() to return success. We are not supposed to rely on luck and need to make sure that LT transitioned through the inactive state though before we initiate link training by hand via RL (Retrain Link) bit. Fixes: 1abb47390350 ("Merge branch 'pci/enumeration'") Link: https://lore.kernel.org/r/20240423130820.43824-1-ilpo.jarvinen@linux.intel.com Signed-off-by: Ilpo Järvinen Signed-off-by: Bjorn Helgaas Signed-off-by: Sasha Levin commit 122e977695e91c934db8c6a3de7e40fe52dffe0d Author: Paul Barker Date: Wed Apr 17 12:41:31 2024 +0100 pinctrl: renesas: rzg2l: Limit 2.5V power supply to Ethernet interfaces [ Upstream commit cd27553b0dee6fdc4a2535ab9fc3c8fbdd811d13 ] The RZ/G3S SoC supports configurable supply voltages for several of its I/O interfaces. All of these interfaces support both 1.8V and 3.3V supplies, but only the Ethernet and XSPI interfaces support a 2.5V supply. Voltage selection for the XSPI interface is not yet supported, so this leaves only the Ethernet interfaces currently supporting selection of a 2.5V supply. So we need to return an error if there is an attempt to select a 2.5V supply for any non-Ethernet interface. Fixes: 51996952b8b5 ("pinctrl: renesas: rzg2l: Add support to select power source for Ethernet pins") Signed-off-by: Paul Barker Reviewed-by: Geert Uytterhoeven Link: https://lore.kernel.org/r/20240417114132.6605-1-paul.barker.ct@bp.renesas.com Signed-off-by: Geert Uytterhoeven Signed-off-by: Sasha Levin commit da797b0c12a79d3bb50bb777541f5b5302a1aca3 Author: Michal Simek Date: Thu Apr 11 10:27:21 2024 +0200 microblaze: Remove early printk call from cpuinfo-static.c [ Upstream commit 58d647506c92ccd3cfa0c453c68ddd14f40bf06f ] Early printk has been removed already that's why also remove calling it. Similar change has been done in cpuinfo-pvr-full.c by commit cfbd8d1979af ("microblaze: Remove early printk setup"). Fixes: 96f0e6fcc9ad ("microblaze: remove redundant early_printk support") Signed-off-by: Michal Simek Link: https://lore.kernel.org/r/2f10db506be8188fa07b6ec331caca01af1b10f8.1712824039.git.michal.simek@amd.com Signed-off-by: Sasha Levin commit 8fe67d46e49e31d2c6756e971e933dd56e31750b Author: Michal Simek Date: Thu Apr 11 10:21:44 2024 +0200 microblaze: Remove gcc flag for non existing early_printk.c file [ Upstream commit edc66cf0c4164aa3daf6cc55e970bb94383a6a57 ] early_printk support for removed long time ago but compilation flag for ftrace still points to already removed file that's why remove that line too. Fixes: 96f0e6fcc9ad ("microblaze: remove redundant early_printk support") Signed-off-by: Michal Simek Link: https://lore.kernel.org/r/5493467419cd2510a32854e2807bcd263de981a0.1712823702.git.michal.simek@amd.com Signed-off-by: Sasha Levin commit 97a2aa5a6ce358603891f975464ce580ca5a4c67 Author: Matthew Wilcox (Oracle) Date: Wed Apr 17 16:04:09 2024 +0100 udf: Convert udf_expand_file_adinicb() to use a folio [ Upstream commit db6754090a4f99c67e05ae6b87343ba6e013531f ] Use the folio APIs throughout this function. Signed-off-by: Matthew Wilcox (Oracle) Fixes: 1eeceaec794e ("udf: Convert udf_expand_file_adinicb() to avoid kmap_atomic()") Signed-off-by: Jan Kara Message-Id: <20240417150416.752929-4-willy@infradead.org> Signed-off-by: Sasha Levin commit e16ad073a18a7da96e30d7ddc0a6676af5459309 Author: Geert Uytterhoeven Date: Tue Apr 16 17:47:22 2024 +0200 pinctrl: renesas: r8a779h0: Fix IRQ suffixes [ Upstream commit c3bec9547c1be0cce3060368dd92abf610c65f24 ] The suffixes of the IRQ identifiers, as used for pins related to the Interrupt Controller for External Devices (INTC-EX), are inconsistent. Correct them to match the Pin Multiplex attachment in Rev.0.51 of the R-Car V4M Series Hardware User's Manual. Fixes: 291f7856fc451cbe ("pinctrl: renesas: Initial R8A779H0 (R-Car V4M) PFC support") Signed-off-by: Geert Uytterhoeven Link: https://lore.kernel.org/r/7d3c7498d9e8eda5583b15f9163eb25bb797ed24.1713282028.git.geert+renesas@glider.be Signed-off-by: Sasha Levin commit 2279c09c36165ccded4d506d11a7714e13b56019 Author: Marco Pagani Date: Fri Apr 19 10:35:59 2024 +0200 fpga: region: add owner module and take its refcount [ Upstream commit b7c0e1ecee403a43abc89eb3e75672b01ff2ece9 ] The current implementation of the fpga region assumes that the low-level module registers a driver for the parent device and uses its owner pointer to take the module's refcount. This approach is problematic since it can lead to a null pointer dereference while attempting to get the region during programming if the parent device does not have a driver. To address this problem, add a module owner pointer to the fpga_region struct and use it to take the module's refcount. Modify the functions for registering a region to take an additional owner module parameter and rename them to avoid conflicts. Use the old function names for helper macros that automatically set the module that registers the region as the owner. This ensures compatibility with existing low-level control modules and reduces the chances of registering a region without setting the owner. Also, update the documentation to keep it consistent with the new interface for registering an fpga region. Fixes: 0fa20cdfcc1f ("fpga: fpga-region: device tree control for FPGA") Suggested-by: Greg Kroah-Hartman Suggested-by: Xu Yilun Reviewed-by: Russ Weight Signed-off-by: Marco Pagani Acked-by: Xu Yilun Link: https://lore.kernel.org/r/20240419083601.77403-1-marpagan@redhat.com Signed-off-by: Xu Yilun Signed-off-by: Sasha Levin commit 35fef97c33f3d3ca0455f9a8e2a3f2c1f8cc9140 Author: Ye Bin Date: Mon Apr 15 09:50:29 2024 +0800 vfio/pci: fix potential memory leak in vfio_intx_enable() [ Upstream commit 82b951e6fbd31d85ae7f4feb5f00ddd4c5d256e2 ] If vfio_irq_ctx_alloc() failed will lead to 'name' memory leak. Fixes: 18c198c96a81 ("vfio/pci: Create persistent INTx handler") Signed-off-by: Ye Bin Reviewed-by: Kevin Tian Acked-by: Reinette Chatre Link: https://lore.kernel.org/r/20240415015029.3699844-1-yebin10@huawei.com Signed-off-by: Alex Williamson Signed-off-by: Sasha Levin commit 8872307b799ed713a637b6c5e799c8ae045481d2 Author: Suzuki K Poulose Date: Fri Apr 12 15:27:02 2024 +0100 coresight: etm4x: Fix access to resource selector registers [ Upstream commit d6fc00d0f640d6010b51054aa8b0fd191177dbc9 ] Resource selector pair 0 is always implemented and reserved. We must not touch it, even during save/restore for CPU Idle. Rest of the driver is well behaved. Fix the offending ones. Reported-by: Yabin Cui Fixes: f188b5e76aae ("coresight: etm4x: Save/restore state across CPU low power states") Signed-off-by: Suzuki K Poulose Tested-by: Yabin Cui Reviewed-by: Mike Leach Link: https://lore.kernel.org/r/20240412142702.2882478-5-suzuki.poulose@arm.com Signed-off-by: Sasha Levin commit de7b30c324040ce8d4acadfcc63db4b23c910ba2 Author: Suzuki K Poulose Date: Fri Apr 12 15:27:01 2024 +0100 coresight: etm4x: Safe access for TRCQCLTR [ Upstream commit 46bf8d7cd8530eca607379033b9bc4ac5590a0cd ] ETM4x implements TRCQCLTR only when the Q elements are supported and the Q element filtering is supported (TRCIDR0.QFILT). Access to the register otherwise could be fatal. Fix this by tracking the availability, like the others. Fixes: f188b5e76aae ("coresight: etm4x: Save/restore state across CPU low power states") Reported-by: Yabin Cui Reviewed-by: Mike Leach Signed-off-by: Suzuki K Poulose Tested-by: Yabin Cui Link: https://lore.kernel.org/r/20240412142702.2882478-4-suzuki.poulose@arm.com Signed-off-by: Sasha Levin commit 5e8a83422a92483985cc803be724d81c893b3a2f Author: Suzuki K Poulose Date: Fri Apr 12 15:27:00 2024 +0100 coresight: etm4x: Do not save/restore Data trace control registers [ Upstream commit 5eb3a0c2c52368cb9902e9a6ea04888e093c487d ] ETM4x doesn't support Data trace on A class CPUs. As such do not access the Data trace control registers during CPU idle. This could cause problems for ETE. While at it, remove all references to the Data trace control registers. Fixes: f188b5e76aae ("coresight: etm4x: Save/restore state across CPU low power states") Reported-by: Yabin Cui Reviewed-by: Mike Leach Signed-off-by: Suzuki K Poulose Tested-by: Yabin Cui Link: https://lore.kernel.org/r/20240412142702.2882478-3-suzuki.poulose@arm.com Signed-off-by: Sasha Levin commit b8fd6d0208d87076962c27b412d167c0e7e28ea9 Author: Suzuki K Poulose Date: Fri Apr 12 15:26:59 2024 +0100 coresight: etm4x: Do not hardcode IOMEM access for register restore [ Upstream commit 1e7ba33fa591de1cf60afffcabb45600b3607025 ] When we restore the register state for ETM4x, while coming back from CPU idle, we hardcode IOMEM access. This is wrong and could blow up for an ETM with system instructions access (and for ETE). Fixes: f5bd523690d2 ("coresight: etm4x: Convert all register accesses") Reported-by: Yabin Cui Reviewed-by: Mike Leach Signed-off-by: Suzuki K Poulose Tested-by: Yabin Cui Link: https://lore.kernel.org/r/20240412142702.2882478-2-suzuki.poulose@arm.com Signed-off-by: Sasha Levin commit 7d9b259b4b9e7c6c31575953d4c1beb8cae392c9 Author: Nuno Sa Date: Fri Apr 19 17:36:45 2024 +0200 iio: adc: adi-axi-adc: only error out in major version mismatch [ Upstream commit cf1c833f89e7c8635a28c3db15c68ead150ea712 ] The IP core only has breaking changes when there major version changes. Hence, only match the major number. This is also in line with the other core ADI has upstream. The current check for erroring out 'expected_version > current_version"' is then wrong as we could just increase the core major with breaking changes and that would go unnoticed. Fixes: ef04070692a2 ("iio: adc: adi-axi-adc: add support for AXI ADC IP core") Signed-off-by: Nuno Sa Link: https://lore.kernel.org/r/20240419-ad9467-new-features-v1-2-3e7628ff6d5e@analog.com Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit c99094246a9fd7efde9781d51de663e80f4149d2 Author: Thomas Haemmerle Date: Mon Apr 15 12:50:27 2024 +0200 iio: pressure: dps310: support negative temperature values [ Upstream commit 9dd6b32e76ff714308964cd9ec91466a343dcb8b ] The current implementation interprets negative values returned from `dps310_calculate_temp` as error codes. This has a side effect that when negative temperature values are calculated, they are interpreted as error. Fix this by using the return value only for error handling and passing a pointer for the value. Fixes: ba6ec48e76bc ("iio: Add driver for Infineon DPS310") Signed-off-by: Thomas Haemmerle Link: https://lore.kernel.org/r/20240415105030.1161770-2-thomas.haemmerle@leica-geosystems.com Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit b6023b2cdc4664884babdaf4ceb8fc409dd11517 Author: James Clark Date: Tue Mar 26 11:37:49 2024 +0000 perf test shell arm_coresight: Increase buffer size for Coresight basic tests [ Upstream commit 10b6ee3b597b1b1b4dc390aaf9d589664af31df9 ] These tests record in a mode that includes kernel trace but look for samples of a userspace process. This makes them sensitive to any kernel compilation options that increase the amount of time spent in the kernel. If the trace buffer is completely filled before userspace is reached then the test will fail. Double the buffer size to fix this. The other tests in the same file aren't sensitive to this for various reasons, for example the iterate devices test filters by userspace trace only. But in order to keep coverage of all the modes, increase the buffer size rather than filtering by userspace for the basic tests. Fixes: d1efa4a0a696e487 ("perf cs-etm: Add separate decode paths for timeless and per-thread modes") Reviewed-by: Anshuman Khandual Signed-off-by: James Clark Cc: Adrian Hunter Cc: Alexander Shishkin Cc: Ian Rogers Cc: Ingo Molnar Cc: James Clark Cc: Jiri Olsa Cc: Mark Rutland Cc: Mike Leach Cc: Namhyung Kim Cc: Peter Zijlstra Cc: Suzuki Poulouse Link: https://lore.kernel.org/r/20240326113749.257250-1-james.clark@arm.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit edb18262c71377ac7fa5423763a0e720b9be8591 Author: Ian Rogers Date: Tue Apr 16 10:00:13 2024 -0700 perf docs: Document bpf event modifier [ Upstream commit eb4d27cf9aef3e6c9bcaf8fa1a1cadc2433d847b ] Document that 'b' is used as a modifier to make an event use a BPF counter. Fixes: 01bd8efcec444468 ("perf stat: Introduce ':b' modifier") Signed-off-by: Ian Rogers Cc: Adrian Hunter Cc: Alexander Shishkin Cc: Athira Rajeev Cc: Ingo Molnar Cc: Jiri Olsa Cc: Kan Liang Cc: Mark Rutland Cc: Namhyung Kim Cc: Peter Zijlstra Cc: Ravi Bangoria Cc: Song Liu Cc: Thomas Richter Link: https://lore.kernel.org/r/20240416170014.985191-1-irogers@google.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 602089a6a50acb6f4561ee9dc58795b8287bb478 Author: Namhyung Kim Date: Fri Apr 12 11:33:08 2024 -0700 perf dwarf-aux: Check pointer offset when checking variables [ Upstream commit 645af3fb62bf12911ce1fc79efa676dae9a8289b ] In match_var_offset(), it checks the offset range with the target type only for non-pointer types. But it also needs to check the pointer types with the target type. This is because there can be more than one pointer variable located in the same register. Let's look at the following example. It's looking up a variable for reg3 at tcp_get_info+0x62. It found "sk" variable but it wasn't the right one since it accesses beyond the target type (struct 'sock' in this case) size. ----------------------------------------------------------- find data type for 0x7bc(reg3) at tcp_get_info+0x62 CU for net/ipv4/tcp.c (die:0x7b5f516) frame base: cfa=0 fbreg=6 offset: 1980 is bigger than size: 760 check variable "sk" failed (die: 0x7b92b2c) variable location: reg3 type='struct sock' size=0x2f8 (die:0x7b63c3a) Actually there was another variable "tp" in the function and it's located at the same (reg3) because it's just type-casted like below. void tcp_get_info(struct sock *sk, struct tcp_info *info) { const struct tcp_sock *tp = tcp_sk(sk); ... The 'struct tcp_sock' contains the 'struct sock' at offset 0 so it can just use the same address as a pointer to tcp_sock. That means it should match variables correctly by checking the offset and size. Actually it cannot distinguish if the offset was smaller than the size of the original struct sock. But I think it's fine as they are the same at that part. So let's check the target type size and retry if it doesn't match. Now it succeeded to find the correct variable. ----------------------------------------------------------- find data type for 0x7bc(reg3) at tcp_get_info+0x62 CU for net/ipv4/tcp.c (die:0x7b5f516) frame base: cfa=0 fbreg=6 found "tp" in scope=1/1 (die: 0x7b92b16) type_offset=0x7bc variable location: reg3 type='struct tcp_sock' size=0xa68 (die:0x7b81380) Fixes: bc10db8eb8955fbc ("perf annotate-data: Support stack variables") Signed-off-by: Namhyung Kim Cc: Adrian Hunter Cc: Ian Rogers Cc: Ingo Molnar Cc: Jiri Olsa Cc: Kan Liang Cc: Masami Hiramatsu Cc: Namhyung Kim Cc: Peter Zijlstra Link: https://lore.kernel.org/r/20240412183310.2518474-3-namhyung@kernel.org Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit aa9eb99fb662958993a86d6918b51db8af15b585 Author: Anshuman Khandual Date: Thu Mar 14 11:28:33 2024 +0530 coresight: etm4x: Fix unbalanced pm_runtime_enable() [ Upstream commit caa41c47dab7e1054f587e592ab21296e3a6781c ] There is an unbalanced pm_runtime_enable() in etm4_probe_platform_dev() when etm4_probe() fails. This problem can be observed via the coresight etm4 module's (load -> unload -> load) sequence when etm4_probe() fails in etm4_probe_platform_dev(). [ 63.379943] coresight-etm4x 7040000.etm: Unbalanced pm_runtime_enable! [ 63.393630] coresight-etm4x 7140000.etm: Unbalanced pm_runtime_enable! [ 63.407455] coresight-etm4x 7240000.etm: Unbalanced pm_runtime_enable! [ 63.420983] coresight-etm4x 7340000.etm: Unbalanced pm_runtime_enable! [ 63.420999] coresight-etm4x 7440000.etm: Unbalanced pm_runtime_enable! [ 63.441209] coresight-etm4x 7540000.etm: Unbalanced pm_runtime_enable! [ 63.454689] coresight-etm4x 7640000.etm: Unbalanced pm_runtime_enable! [ 63.474982] coresight-etm4x 7740000.etm: Unbalanced pm_runtime_enable! This fixes the above problem - with an explicit pm_runtime_disable() call when etm4_probe() fails during etm4_probe_platform_dev(). Cc: Lorenzo Pieralisi Cc: Hanjun Guo Cc: Sudeep Holla Cc: "Rafael J. Wysocki" Cc: Len Brown Cc: Suzuki K Poulose Cc: Mike Leach Cc: James Clark Cc: Leo Yan Cc: linux-acpi@vger.kernel.org Cc: linux-arm-kernel@lists.infradead.org Cc: linux-kernel@vger.kernel.org Cc: coresight@lists.linaro.org Fixes: 5214b563588e ("coresight: etm4x: Add support for sysreg only devices") Reviewed-by: James Clark Signed-off-by: Anshuman Khandual Signed-off-by: Suzuki K Poulose Link: https://lore.kernel.org/r/20240314055843.2625883-2-anshuman.khandual@arm.com Signed-off-by: Sasha Levin commit 820b6f7b298995df24709251f512005ef50189d5 Author: Hannah Peuckmann Date: Mon Apr 15 14:50:33 2024 +0200 riscv: dts: starfive: visionfive 2: Remove non-existing I2S hardware [ Upstream commit e0503d47e93dead8c0475ea1eb624e03fada21d3 ] This partially reverts commit 92cfc35838b2 ("riscv: dts: starfive: Add the nodes and pins of I2Srx/I2Stx0/I2Stx1") This added device tree nodes for I2S hardware that is not actually on the VisionFive 2 board, but connected on the 40pin header. Many different extension boards could be added on those pins, so this should be handled by overlays instead. This also conflicts with the TDM node which also attempts to grab GPIO 44: starfive-jh7110-sys-pinctrl 13040000.pinctrl: pin GPIO44 already requested by 10090000.tdm; cannot claim for 120c0000.i2s Fixes: 92cfc35838b2 ("riscv: dts: starfive: Add the nodes and pins of I2Srx/I2Stx0/I2Stx1") Signed-off-by: Hannah Peuckmann Reviewed-by: Emil Renner Berthing Tested-by: Emil Renner Berthing Signed-off-by: Conor Dooley Signed-off-by: Sasha Levin commit f752586ba4c328866337bfa11df5ca7532024f88 Author: Hannah Peuckmann Date: Mon Apr 15 14:50:32 2024 +0200 riscv: dts: starfive: visionfive 2: Remove non-existing TDM hardware [ Upstream commit dcde4e97b122ac318aaa71e8bcd2857dc28a0d12 ] This partially reverts commit e7c304c0346d ("riscv: dts: starfive: jh7110: add the node and pins configuration for tdm") This added device tree nodes for TDM hardware that is not actually on the VisionFive 2 board, but connected on the 40pin header. Many different extension boards could be added on those pins, so this should be handled by overlays instead. This also conflicts with the I2S node which also attempts to grab GPIO 44: starfive-jh7110-sys-pinctrl 13040000.pinctrl: pin GPIO44 already requested by 10090000.tdm; cannot claim for 120c0000.i2s Fixes: e7c304c0346d ("riscv: dts: starfive: jh7110: add the node and pins configuration for tdm") Signed-off-by: Hannah Peuckmann Reviewed-by: Emil Renner Berthing Tested-by: Emil Renner Berthing Signed-off-by: Conor Dooley Signed-off-by: Sasha Levin commit 691a9886488bf62d2c94f1646700ce6e2f647243 Author: Jonathan Cameron Date: Sat Mar 30 18:53:00 2024 +0000 iio: adc: stm32: Fixing err code to not indicate success [ Upstream commit 3735ca0b072656c3aa2cedc617a5e639b583a472 ] This path would result in returning 0 / success on an error path. Cc: Olivier Moysan Fixes: 95bc818404b2 ("iio: adc: stm32-adc: add support of generic channels binding") Reviewed-by: Fabrice Gasnier Link: https://lore.kernel.org/r/20240330185305.1319844-4-jic23@kernel.org Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit fe0c337203db5cbcaf2bb336d9c22933448e203d Author: Daeho Jeong Date: Tue Apr 9 16:34:11 2024 -0700 f2fs: write missing last sum blk of file pinning section [ Upstream commit b084403cfc3295b59a1b6bcc94efaf870fc3c2c9 ] While do not allocating a new section in advance for file pinning area, I missed that we should write the sum block for the last segment of a file pinning section. Fixes: 9703d69d9d15 ("f2fs: support file pinning for zoned devices") Signed-off-by: Daeho Jeong Reviewed-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit ee36ecde58a2da28a0bc97d0f4c395601330375e Author: Chao Yu Date: Wed Apr 3 22:24:20 2024 +0800 f2fs: fix to check pinfile flag in f2fs_move_file_range() [ Upstream commit e07230da0500e0919a765037c5e81583b519be2c ] ioctl(F2FS_IOC_MOVE_RANGE) can truncate or punch hole on pinned file, fix to disallow it. Fixes: 5fed0be8583f ("f2fs: do not allow partial truncation on pinned file") Signed-off-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit 754bb36731ab80a889bdd3766846b7ba67d30535 Author: Chao Yu Date: Wed Apr 3 22:24:19 2024 +0800 f2fs: fix to relocate check condition in f2fs_fallocate() [ Upstream commit 278a6253a673611dbc8ab72a3b34b151a8e75822 ] compress and pinfile flag should be checked after inode lock held to avoid race condition, fix it. Fixes: 4c8ff7095bef ("f2fs: support data compression") Fixes: 5fed0be8583f ("f2fs: do not allow partial truncation on pinned file") Signed-off-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit ef3690c440981b891bd5ae15598ec3c7c0f9be49 Author: Chao Yu Date: Sun Apr 7 15:26:04 2024 +0800 f2fs: compress: fix to relocate check condition in f2fs_ioc_{,de}compress_file() [ Upstream commit bd9ae4ae9e585061acfd4a169f2321706f900246 ] Compress flag should be checked after inode lock held to avoid racing w/ f2fs_setflags_common() , fix it. Fixes: 5fdb322ff2c2 ("f2fs: add F2FS_IOC_DECOMPRESS_FILE and F2FS_IOC_COMPRESS_FILE") Reported-by: Zhiguo Niu Closes: https://lore.kernel.org/linux-f2fs-devel/CAHJ8P3LdZXLc2rqeYjvymgYHr2+YLuJ0sLG9DdsJZmwO7deuhw@mail.gmail.com Signed-off-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit eeac6ee8f60996828af3d8cfea36818804ef67e6 Author: Chao Yu Date: Sun Apr 7 15:26:03 2024 +0800 f2fs: compress: fix to relocate check condition in f2fs_{release,reserve}_compress_blocks() [ Upstream commit 7c5dffb3d90c5921b91981cc663e02757d90526e ] Compress flag should be checked after inode lock held to avoid racing w/ f2fs_setflags_common(), fix it. Fixes: 4c8ff7095bef ("f2fs: support data compression") Reported-by: Zhiguo Niu Closes: https://lore.kernel.org/linux-f2fs-devel/CAHJ8P3LdZXLc2rqeYjvymgYHr2+YLuJ0sLG9DdsJZmwO7deuhw@mail.gmail.com Signed-off-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit bb1f43ffaca05db0827db06d6b57c56f503357ff Author: Ian Rogers Date: Fri Apr 5 21:09:10 2024 -0700 perf bench uprobe: Remove lib64 from libc.so.6 binary path [ Upstream commit 459fee7b508231cd4622b3bd94aaa85e8e16b888 ] bpf_program__attach_uprobe_opts will search LD_LIBRARY_PATH and so specifying `/lib64` is unnecessary and causes failures for libc.so.6 paths like `/lib/x86_64-linux-gnu/libc.so.6`. Fixes: 7b47623b8cae8149 ("perf bench uprobe trace_printk: Add entry attaching an BPF program that does a trace_printk") Signed-off-by: Ian Rogers Acked-by: Jiri Olsa Cc: Adrian Hunter Cc: Alexander Shishkin Cc: Andrei Vagin Cc: Ingo Molnar Cc: Kan Liang Cc: Kees Kook Cc: Mark Rutland Cc: Namhyung Kim Cc: Peter Zijlstra Link: https://lore.kernel.org/r/20240406040911.1603801-1-irogers@google.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit be967cea8ee2b3e4dad5cd066e8718d5ded318ba Author: Geert Uytterhoeven Date: Thu Feb 1 16:52:01 2024 +0100 dt-bindings: PCI: rcar-pci-host: Add missing IOMMU properties [ Upstream commit 78d212851f0e56b7d7083c4d5014aa7fa8b77e20 ] make dtbs_check: arch/arm64/boot/dts/renesas/r8a77951-salvator-xs.dtb: pcie@fe000000: Unevaluated properties are not allowed ('iommu-map', 'iommu-map-mask' were unexpected) from schema $id: http://devicetree.org/schemas/pci/rcar-pci-host.yaml# Fix this by adding the missing IOMMU-related properties. [kwilczynski: added missing Fixes: tag] Fixes: 0d69ce3c2c63 ("dt-bindings: PCI: rcar-pci-host: Convert bindings to json-schema") Link: https://lore.kernel.org/linux-pci/babc878a93cb6461a5d39331f8ecfa654dfda921.1706802597.git.geert+renesas@glider.be Signed-off-by: Geert Uytterhoeven Signed-off-by: Krzysztof Wilczyński Acked-by: Conor Dooley Signed-off-by: Sasha Levin commit 330dfeaefd1943a9302035229083fa51ab570dcb Author: Adrian Hunter Date: Thu Apr 11 10:54:47 2024 +0300 perf record: Fix debug message placement for test consumption [ Upstream commit 792bc998baf9ae17297b1f93b1edc3ca34a0b7e2 ] evlist__config() might mess up the debug output consumed by test "Test per-thread recording" in "Miscellaneous Intel PT testing". Move it out from between the debug prints: "perf record opening and mmapping events" and "perf record done opening and mmapping events" Fixes: da4062021e0e6da5 ("perf tools: Add debug messages and comments for testing") Closes: https://lore.kernel.org/linux-perf-users/ZhVfc5jYLarnGzKa@x1/ Reported-by: Arnaldo Carvalho de Melo Signed-off-by: Adrian Hunter Tested-by: Arnaldo Carvalho de Melo Cc: Ian Rogers Cc: Jiri Olsa Cc: Namhyung Kim Link: https://lore.kernel.org/r/20240411075447.17306-1-adrian.hunter@intel.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 4211ba4096905dc2feec840d13b7b7f767a92107 Author: James Clark Date: Wed Apr 10 11:34:54 2024 +0100 perf map: Remove kernel map before updating start and end addresses [ Upstream commit df12e21d4e15e48a5e7d12e58f1a00742c4177d0 ] In a debug build there is validation that mmap lists are sorted when taking a lock. In machine__update_kernel_mmap() the start and end addresses are updated resulting in an unsorted list before the map is removed from the list. When the map is removed, the lock is taken which triggers the validation and the failure: $ perf test "object code reading" --- start --- perf: util/maps.c:88: check_invariants: Assertion `map__start(prev) <= map__start(map)' failed. Aborted Fix it by updating the addresses after removal, but before insertion. The bug depends on the ordering and type of debug info on the system and doesn't reproduce everywhere. Fixes: 659ad3492b913c90 ("perf maps: Switch from rbtree to lazily sorted array for addresses") Reviewed-by: Ian Rogers Signed-off-by: James Clark Acked-by: Namhyung Kim Cc: Adrian Hunter Cc: Alexander Shishkin Cc: Athira Rajeev Cc: Ian Rogers Cc: Ingo Molnar Cc: Jiri Olsa Cc: Kan Liang Cc: Leo Yan Cc: Mark Rutland Cc: Namhyung Kim Cc: Peter Zijlstra Cc: Spoorthy S Link: https://lore.kernel.org/r/20240410103458.813656-4-james.clark@arm.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit bef6f79c722ed9504b2d523e2c7f66dffd631e8e Author: James Clark Date: Wed Apr 10 11:34:53 2024 +0100 perf tests: Apply attributes to all events in object code reading test [ Upstream commit 2dade41a533f337447b945239b87ff31a8857890 ] PERF_PMU_CAP_EXTENDED_HW_TYPE results in multiple events being opened on heterogeneous systems. Currently this test only sets its required attributes on the first event. Not disabling enable_on_exec on the other events causes the test to fail because the forked objdump processes are sampled. No tracking event is opened so Perf only knows about its own mappings causing the objdump samples to give the following error: $ perf test -vvv "object code reading" Reading object code for memory address: 0xffff9aaa55ec thread__find_map failed ---- end(-1) ---- 24: Object code reading : FAILED! Fixes: 251aa040244a3b17 ("perf parse-events: Wildcard most "numeric" events") Reviewed-by: Ian Rogers Signed-off-by: James Clark Acked-by: Namhyung Kim Cc: Adrian Hunter Cc: Alexander Shishkin Cc: Athira Rajeev Cc: Ian Rogers Cc: Ingo Molnar Cc: Jiri Olsa Cc: Kan Liang Cc: Leo Yan Cc: Mark Rutland Cc: Peter Zijlstra Cc: Spoorthy S Link: https://lore.kernel.org/r/20240410103458.813656-3-james.clark@arm.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit e2d9443cacdc5ffeaeabd050cae9b5fe11959f00 Author: James Clark Date: Wed Apr 10 11:34:52 2024 +0100 perf tests: Make "test data symbol" more robust on Neoverse N1 [ Upstream commit 256ef072b3842273ce703db18b603b051aca95fe ] To prevent anyone from seeing a test failure appear as a regression and thinking that it was caused by their code change, insert some noise into the loop which makes it immune to sampling bias issues (errata 1694299). The "test data symbol" test can fail with any unrelated change that shifts the loop into an unfortunate position in the Perf binary which is almost impossible to debug as the root cause of the test failure. Ultimately it's caused by the referenced errata. Fixes: 60abedb8aa902b06 ("perf test: Introduce script for data symbol testing") Reviewed-by: Ian Rogers Signed-off-by: James Clark Acked-by: Namhyung Kim Cc: Adrian Hunter Cc: Alexander Shishkin Cc: Athira Rajeev Cc: Ingo Molnar Cc: Jiri Olsa Cc: Kan Liang Cc: Leo Yan Cc: Mark Rutland Cc: Peter Zijlstra Cc: Spoorthy S Link: https://lore.kernel.org/r/20240410103458.813656-2-james.clark@arm.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 1bd8ce9afa18f8a77e397f783a6db92f54355f21 Author: Xianwei Zhao Date: Fri Apr 12 16:42:30 2024 +0800 arm64: dts: meson: fix S4 power-controller node [ Upstream commit 72907de9051dc2aa7b55c2a020e2872184ac17cd ] The power-controller module works well by adding its parent node secure-monitor. Fixes: 085f7a298a14 ("arm64: dts: add support for S4 power domain controller") Signed-off-by: Xianwei Zhao Reviewed-by: Neil Armstrong Link: https://lore.kernel.org/r/20240412-fix-secpwr-s4-v2-1-3802fd936d77@amlogic.com Signed-off-by: Neil Armstrong Signed-off-by: Sasha Levin commit 67817e53e0d89b99e48ac6ab825afc1a46e99338 Author: Konrad Dybcio Date: Tue Mar 26 20:42:33 2024 +0100 interconnect: qcom: qcm2290: Fix mas_snoc_bimc QoS port assignment [ Upstream commit 230d05b1179f6ce6f8dc8a2b99eba92799ac22d7 ] The value was wrong, resulting in misprogramming of the hardware. Fix it. Fixes: 1a14b1ac3935 ("interconnect: qcom: Add QCM2290 driver support") Signed-off-by: Konrad Dybcio Link: https://lore.kernel.org/r/20240326-topic-rpm_icc_qos_cleanup-v1-2-357e736792be@linaro.org Signed-off-by: Georgi Djakov Signed-off-by: Sasha Levin commit 51dacb1b0467b616463a334cbcd048f5710ba2aa Author: Arnd Bergmann Date: Mon Apr 8 10:05:58 2024 +0200 module: don't ignore sysfs_create_link() failures [ Upstream commit 85d2b0aa170351380be39fe4ff7973df1427fe76 ] The sysfs_create_link() return code is marked as __must_check, but the module_add_driver() function tries hard to not care, by assigning the return code to a variable. When building with 'make W=1', gcc still warns because this variable is only assigned but not used: drivers/base/module.c: In function 'module_add_driver': drivers/base/module.c:36:6: warning: variable 'no_warn' set but not used [-Wunused-but-set-variable] Rework the code to properly unwind and return the error code to the caller. My reading of the original code was that it tries to not fail when the links already exist, so keep ignoring -EEXIST errors. Fixes: e17e0f51aeea ("Driver core: show drivers in /sys/module/") See-also: 4a7fb6363f2d ("add __must_check to device management code") Signed-off-by: Arnd Bergmann Reviewed-by: Luis Chamberlain Link: https://lore.kernel.org/r/20240408080616.3911573-1-arnd@kernel.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 312a665650024a59239b623e2debd7a9e5df83ef Author: Hugo Villeneuve Date: Tue Apr 9 11:42:49 2024 -0400 serial: sc16is7xx: add proper sched.h include for sched_set_fifo() [ Upstream commit 2a8e4ab0c93fad30769479f86849e22d63cd0e12 ] Replace incorrect include with the proper one for sched_set_fifo() declaration. Fixes: 28d2f209cd16 ("sched,serial: Convert to sched_set_fifo()") Signed-off-by: Hugo Villeneuve Link: https://lore.kernel.org/r/20240409154253.3043822-2-hugo@hugovil.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit a3d5def870cd8dd731d9cdd6998ccf6a923ae1b2 Author: Vidya Sagar Date: Mon Apr 8 15:00:53 2024 +0530 PCI: tegra194: Fix probe path for Endpoint mode [ Upstream commit 19326006a21da26532d982254677c892dae8f29b ] Tegra194 PCIe probe path is taking failure path in success case for Endpoint mode. Return success from the switch case instead of going into the failure path. Fixes: c57247f940e8 ("PCI: tegra: Add support for PCIe endpoint mode in Tegra194") Link: https://lore.kernel.org/linux-pci/20240408093053.3948634-1-vidyas@nvidia.com Signed-off-by: Vidya Sagar Signed-off-by: Krzysztof Wilczyński Reviewed-by: Jon Hunter Signed-off-by: Sasha Levin commit f66cae18228edd1d18174e937c13ec335a8bf8a0 Author: Manivannan Sadhasivam Date: Wed Mar 27 14:43:30 2024 +0530 PCI: dwc: ep: Fix DBI access failure for drivers requiring refclk from host [ Upstream commit 869bc52534065990cb57013b2bb354c0c1e66c5c ] The DWC glue drivers requiring an active reference clock from the PCIe host for initializing their PCIe EP core, set a flag called 'core_init_notifier' to let DWC driver know that these drivers need a special attention during initialization. In these drivers, access to the hw registers (like DBI) before receiving the active refclk from host will result in access failure and also could cause a whole system hang. But the current DWC EP driver doesn't honor the requirements of the drivers setting 'core_init_notifier' flag and tries to access the DBI registers during dw_pcie_ep_init(). This causes the system hang for glue drivers such as Tegra194 and Qcom EP as they depend on refclk from host and have set the above mentioned flag. To workaround this issue, users of the affected platforms have to maintain the dependency with the PCIe host by booting the PCIe EP after host boot. But this won't provide a good user experience, since PCIe EP is _one_ of the features of those platforms and it doesn't make sense to delay the whole platform booting due to PCIe requiring active refclk. So to fix this issue, let's move all the DBI access from dw_pcie_ep_init() in the DWC EP driver to the dw_pcie_ep_init_complete() API. This API will only be called by the drivers setting 'core_init_notifier' flag once refclk is received from host. For the rest of the drivers that gets the refclk locally, this API will be called within dw_pcie_ep_init(). Link: https://lore.kernel.org/linux-pci/20240327-pci-dbi-rework-v12-1-082625472414@linaro.org Fixes: e966f7390da9 ("PCI: dwc: Refactor core initialization code for EP mode") Co-developed-by: Vidya Sagar Signed-off-by: Vidya Sagar Signed-off-by: Manivannan Sadhasivam Signed-off-by: Krzysztof Wilczyński Reviewed-by: Frank Li Reviewed-by: Niklas Cassel Signed-off-by: Sasha Levin commit 814015e0ae4d61986a9f67c63c79072a77f2e63b Author: Arnd Bergmann Date: Wed Apr 3 10:06:35 2024 +0200 greybus: arche-ctrl: move device table to its right location [ Upstream commit 6a0b8c0da8d8d418cde6894a104cf74e6098ddfa ] The arche-ctrl has two platform drivers and three of_device_id tables, but one table is only used for the the module loader, while the other two seem to be associated with their drivers. This leads to a W=1 warning when the driver is built-in: drivers/staging/greybus/arche-platform.c:623:34: error: 'arche_combined_id' defined but not used [-Werror=unused-const-variable=] 623 | static const struct of_device_id arche_combined_id[] = { Drop the extra table and register both tables that are actually used as the ones for the module loader instead. Fixes: 7b62b61c752a ("greybus: arche-ctrl: Don't expose driver internals to arche-platform driver") Signed-off-by: Arnd Bergmann Link: https://lore.kernel.org/r/20240403080702.3509288-18-arnd@kernel.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit daae076ae946612b19e706d0b2ef3e091c1f4eea Author: Andy Shevchenko Date: Tue Apr 2 22:50:30 2024 +0300 serial: max3100: Fix bitwise types [ Upstream commit e60955dbecb97f080848a57524827e2db29c70fd ] Sparse is not happy about misuse of bitwise types: .../max3100.c:194:13: warning: incorrect type in assignment (different base types) .../max3100.c:194:13: expected unsigned short [addressable] [usertype] etx .../max3100.c:194:13: got restricted __be16 [usertype] .../max3100.c:202:15: warning: cast to restricted __be16 Fix this by choosing proper types for the respective variables. Fixes: 7831d56b0a35 ("tty: MAX3100") Signed-off-by: Andy Shevchenko Link: https://lore.kernel.org/r/20240402195306.269276-4-andriy.shevchenko@linux.intel.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit fa84ca78b048dfb00df0ef446f5c35e0a98ca6a0 Author: Andy Shevchenko Date: Tue Apr 2 22:50:29 2024 +0300 serial: max3100: Update uart_driver_registered on driver removal [ Upstream commit 712a1fcb38dc7cac6da63ee79a88708fbf9c45ec ] The removal of the last MAX3100 device triggers the removal of the driver. However, code doesn't update the respective global variable and after insmod — rmmod — insmod cycle the kernel oopses: max3100 spi-PRP0001:01: max3100_probe: adding port 0 BUG: kernel NULL pointer dereference, address: 0000000000000408 ... RIP: 0010:serial_core_register_port+0xa0/0x840 ... max3100_probe+0x1b6/0x280 [max3100] spi_probe+0x8d/0xb0 Update the actual state so next time UART driver will be registered again. Hugo also noticed, that the error path in the probe also affected by having the variable set, and not cleared. Instead of clearing it move the assignment after the successfull uart_register_driver() call. Fixes: 7831d56b0a35 ("tty: MAX3100") Signed-off-by: Andy Shevchenko Reviewed-by: Hugo Villeneuve Link: https://lore.kernel.org/r/20240402195306.269276-3-andriy.shevchenko@linux.intel.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 865b30c8661924ee9145f442bf32cea549faa869 Author: Andy Shevchenko Date: Tue Apr 2 22:50:28 2024 +0300 serial: max3100: Lock port->lock when calling uart_handle_cts_change() [ Upstream commit 77ab53371a2066fdf9b895246505f5ef5a4b5d47 ] uart_handle_cts_change() has to be called with port lock taken, Since we run it in a separate work, the lock may not be taken at the time of running. Make sure that it's taken by explicitly doing that. Without it we got a splat: WARNING: CPU: 0 PID: 10 at drivers/tty/serial/serial_core.c:3491 uart_handle_cts_change+0xa6/0xb0 ... Workqueue: max3100-0 max3100_work [max3100] RIP: 0010:uart_handle_cts_change+0xa6/0xb0 ... max3100_handlerx+0xc5/0x110 [max3100] max3100_work+0x12a/0x340 [max3100] Fixes: 7831d56b0a35 ("tty: MAX3100") Signed-off-by: Andy Shevchenko Link: https://lore.kernel.org/r/20240402195306.269276-2-andriy.shevchenko@linux.intel.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit e6917adb9a04c47b870ec98e8182df66c9c92cf0 Author: Namhyung Kim Date: Thu Apr 4 10:57:08 2024 -0700 perf annotate: Fix annotation_calc_lines() to pass correct address to get_srcline() [ Upstream commit aaf494cf483a1a835c44e942861429b30a00cab0 ] It should pass a proper address (i.e. suitable for objdump or addr2line) to get_srcline() in order to work correctly. It used to pass an address with map__rip_2objdump() as the second argument but later it's changed to use notes->start. It's ok in normal cases but it can be changed when annotate_opts.full_addr is set. So let's convert the address directly instead of using the notes->start. Also the last argument is an IP to print symbol offset if requested. So it should pass symbol-relative address. Fixes: 7d18a824b5e57ddd ("perf annotate: Toggle full address <-> offset display") Signed-off-by: Namhyung Kim Cc: Adrian Hunter Cc: Ian Rogers Cc: Ingo Molnar Cc: Jiri Olsa Cc: Kan Liang Cc: Namhyung Kim Cc: Peter Zijlstra Link: https://lore.kernel.org/r/20240404175716.1225482-2-namhyung@kernel.org Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit f353f61d79ea61b7988cd58570b18a84c691dd1d Author: Arnd Bergmann Date: Mon Apr 8 09:34:24 2024 +0200 firmware: dmi-id: add a release callback function [ Upstream commit cf770af5645a41a753c55a053fa1237105b0964a ] dmi_class uses kfree() as the .release function, but that now causes a warning with clang-16 as it violates control flow integrity (KCFI) rules: drivers/firmware/dmi-id.c:174:17: error: cast from 'void (*)(const void *)' to 'void (*)(struct device *)' converts to incompatible function type [-Werror,-Wcast-function-type-strict] 174 | .dev_release = (void(*)(struct device *)) kfree, Add an explicit function to call kfree() instead. Fixes: 4f5c791a850e ("DMI-based module autoloading") Link: https://lore.kernel.org/lkml/20240213100238.456912-1-arnd@kernel.org/ Signed-off-by: Arnd Bergmann Signed-off-by: Jean Delvare Signed-off-by: Sasha Levin commit 7106a40b093296e9e08052879deb48d8ed23107d Author: Chen Ni Date: Wed Apr 3 02:49:32 2024 +0000 dmaengine: idma64: Add check for dma_set_max_seg_size [ Upstream commit 2b1c1cf08a0addb6df42f16b37133dc7a351de29 ] As the possible failure of the dma_set_max_seg_size(), it should be better to check the return value of the dma_set_max_seg_size(). Fixes: e3fdb1894cfa ("dmaengine: idma64: set maximum allowed segment size for DMA") Signed-off-by: Chen Ni Acked-by: Andy Shevchenko Link: https://lore.kernel.org/r/20240403024932.3342606-1-nichen@iscas.ac.cn Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 4e99103f757cdf636c6ee860994a19a346a11785 Author: Pierre-Louis Bossart Date: Tue Mar 26 09:01:16 2024 +0000 soundwire: cadence: fix invalid PDI offset [ Upstream commit 8ee1b439b1540ae543149b15a2a61b9dff937d91 ] For some reason, we add an offset to the PDI, presumably to skip the PDI0 and PDI1 which are reserved for BPT. This code is however completely wrong and leads to an out-of-bounds access. We were just lucky so far since we used only a couple of PDIs and remained within the PDI array bounds. A Fixes: tag is not provided since there are no known platforms where the out-of-bounds would be accessed, and the initial code had problems as well. A follow-up patch completely removes this useless offset. Signed-off-by: Pierre-Louis Bossart Reviewed-by: Rander Wang Signed-off-by: Bard Liao Link: https://lore.kernel.org/r/20240326090122.1051806-2-yung-chuan.liao@linux.intel.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 5b3ed9348cbaed559fd4675dc3786e3c8f68b132 Author: Thomas Richter Date: Thu Apr 4 08:48:06 2024 +0200 perf stat: Do not fail on metrics on s390 z/VM systems [ Upstream commit c2f3d7dfc7373d53286f2a5c882d3397a5070adc ] On s390 z/VM virtual machines command 'perf list' also displays metrics: # perf list | grep -A 20 'Metric Groups:' Metric Groups: No_group: cpi [Cycles per Instruction] est_cpi [Estimated Instruction Complexity CPI infinite Level 1] finite_cpi [Cycles per Instructions from Finite cache/memory] l1mp [Level One Miss per 100 Instructions] l2p [Percentage sourced from Level 2 cache] l3p [Percentage sourced from Level 3 on same chip cache] l4lp [Percentage sourced from Level 4 Local cache on same book] l4rp [Percentage sourced from Level 4 Remote cache on different book] memp [Percentage sourced from memory] .... # The command # perf stat -M cpi -- true event syntax error: '{CPU_CYCLES/metric-id=CPU_CYCLES/.....' \___ Bad event or PMU Unable to find PMU or event on a PMU of 'CPU_CYCLES' event syntax error: '{CPU_CYCLES/metric-id=CPU_CYCLES/...' \___ Cannot find PMU `CPU_CYCLES'. Missing kernel support? # fails. 'perf stat' should not fail on metrics when the referenced CPU Counter Measurement PMU is not available. Output after: # perf stat -M est_cpi -- sleep 1 Performance counter stats for 'sleep 1': 1,000,887,494 ns duration_time # 0.00 est_cpi 1.000887494 seconds time elapsed 0.000143000 seconds user 0.000662000 seconds sys # Fixes: 7f76b31130680fb3 ("perf list: Add IBM z16 event description for s390") Suggested-by: Ian Rogers Reviewed-by: Ian Rogers Signed-off-by: Thomas Richter Cc: Heiko Carstens Cc: Namhyung Kim Cc: Sumanth Korikkar Cc: Sven Schnelle Cc: Vasily Gorbik Link: https://lore.kernel.org/r/20240404064806.1362876-2-tmricht@linux.ibm.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit b26b078fbf4e9e2b91350a7549692d56d7831678 Author: Thomas Richter Date: Thu Apr 4 08:48:05 2024 +0200 perf report: Fix PAI counter names for s390 virtual machines [ Upstream commit b74bc5a633a7d72f89141d481d835e73bda3c3ae ] s390 introduced the Processor Activity Instrumentation (PAI) counter facility on LPAR and virtual machines z/VM for models 3931 and 3932. These counters are stored as raw data in the perf.data file and are displayed with: # perf report -i /tmp//perfout-635468 -D | grep Counter Counter:007 Value:0x00000000000186a0 Counter:032 Value:0x0000000000000001 Counter:032 Value:0x0000000000000001 Counter:032 Value:0x0000000000000001 # However on z/VM virtual machines, the counter names are not retrieved from the PMU and are shown as ''. This is caused by the CPU string saved in the mapfile.csv for this machine: ^IBM.393[12].*3\.7.[[:xdigit:]]+$,3,cf_z16,core This string contains the CPU Measurement facility first and second version number and authorization level (3\.7.[[:xdigit:]]+). These numbers do not apply to the PAI counter facility. In fact they can be omitted. Shorten the CPU identification string for this machine to manufacturer and model. This is sufficient for all PMU devices. Output after: # perf report -i /tmp//perfout-635468 -D | grep Counter Counter:007 km_aes_128 Value:0x00000000000186a0 Counter:032 kma_gcm_aes_256 Value:0x0000000000000001 Counter:032 kma_gcm_aes_256 Value:0x0000000000000001 Counter:032 kma_gcm_aes_256 Value:0x0000000000000001 # Fixes: b539deafbadb2fc6 ("perf report: Add s390 raw data interpretation for PAI counters") Reviewed-by: Ian Rogers Signed-off-by: Thomas Richter Acked-by: Sumanth Korikkar Cc: Heiko Carstens Cc: Namhyung Kim Cc: Sven Schnelle Cc: Thomas Richter Cc: Vasily Gorbik Link: https://lore.kernel.org/r/20240404064806.1362876-1-tmricht@linux.ibm.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 7fa3ef810c87ca44a4d915bc800e22f96cc1a745 Author: Dmitry Baryshkov Date: Fri Mar 29 08:15:37 2024 +0200 usb: typec: ucsi: simplify partner's PD caps registration [ Upstream commit 41e1cd1401fcd1f1ae9e47574af2d9fc44a870b3 ] In a way similar to the previous commit, move typec_partner_set_usb_power_delivery() to be called after reading the PD caps. This also removes calls to usb_power_delivery_unregister_capabilities() from the error path. Keep all capabilities registered until they are cleared by ucsi_unregister_partner_pdos(). Fixes: b04e1747fbcc ("usb: typec: ucsi: Register USB Power Delivery Capabilities") Signed-off-by: Dmitry Baryshkov Reviewed-by: Heikki Krogerus Link: https://lore.kernel.org/r/20240329-qcom-ucsi-fixes-v2-5-0f5d37ed04db@linaro.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 843bb5191a74adf6075716ac747a146ee1b44733 Author: Dmitry Baryshkov Date: Fri Mar 29 08:15:36 2024 +0200 usb: typec: ucsi: always register a link to USB PD device [ Upstream commit c0f66d78f42353d38b9608c05f211cf0773d93ac ] UCSI driver will attempt to set a USB PD device only if it was able to read PDOs from the firmware. This results in suboptimal behaviour, since the PD device will be created anyway. Move calls to typec_port_set_usb_power_delivery() out of conditional code and call it after reading capabilities. Fixes: b04e1747fbcc ("usb: typec: ucsi: Register USB Power Delivery Capabilities") Signed-off-by: Dmitry Baryshkov Reviewed-by: Heikki Krogerus Link: https://lore.kernel.org/r/20240329-qcom-ucsi-fixes-v2-4-0f5d37ed04db@linaro.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 186bd766fea97ffe1f0c6bb280f9710c115cf4b3 Author: Dmitry Baryshkov Date: Fri Mar 29 08:15:33 2024 +0200 usb: typec: ucsi: allow non-partner GET_PDOS for Qualcomm devices [ Upstream commit 897d68d4ce7d50ca45a31e10c0e61597257b32d3 ] The name and description of the USB_NO_PARTNER_PDOS quirk specifies that only retrieving PDOS of the attached device is crashing. Retrieving PDOS of the UCSI device works. Fix the condition to limit the workaround only to is_partner cases. Fixes: 1d103d6af241 ("usb: typec: ucsi: fix UCSI on buggy Qualcomm devices") Reviewed-by: Heikki Krogerus Signed-off-by: Dmitry Baryshkov Link: https://lore.kernel.org/r/20240329-qcom-ucsi-fixes-v2-1-0f5d37ed04db@linaro.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 7896ced6ad186e47e4713cf98804e68cd57e43f1 Author: Yang Jihong Date: Mon Apr 1 14:27:23 2024 +0800 perf sched timehist: Fix -g/--call-graph option failure [ Upstream commit 6e4b398770d5023eb6383da9360a23bd537c155b ] When 'perf sched' enables the call-graph recording, sample_type of dummy event does not have PERF_SAMPLE_CALLCHAIN, timehist_check_attr() checks that the evsel does not have a callchain, and set show_callchain to 0. Currently 'perf sched timehist' only saves callchain when processing the 'sched:sched_switch event', timehist_check_attr() only needs to determine whether the event has PERF_SAMPLE_CALLCHAIN. Before: # perf sched record -g true [ perf record: Woken up 0 times to write data ] [ perf record: Captured and wrote 4.153 MB perf.data (7536 samples) ] # perf sched timehist Samples do not have callchains. time cpu task name wait time sch delay run time [tid/pid] (msec) (msec) (msec) --------------- ------ ------------------------------ --------- --------- --------- 147851.826019 [0000] perf[285035] 0.000 0.000 0.000 147851.826029 [0000] migration/0[15] 0.000 0.003 0.009 147851.826063 [0001] perf[285035] 0.000 0.000 0.000 147851.826069 [0001] migration/1[21] 0.000 0.003 0.006 After: # perf sched record -g true [ perf record: Woken up 1 times to write data ] [ perf record: Captured and wrote 2.572 MB perf.data (822 samples) ] # perf sched timehist time cpu task name waittime sch delay runtime [tid/pid] (msec) (msec) (msec) ----------- --- --------------- -------- -------- ----- 4193.035164 [0] perf[277062] 0.000 0.000 0.000 __traceiter_sched_switch <- __traceiter_sched_switch <- __sched_text_start <- preempt_schedule_common <- __cond_resched <- __wait_for_common <- wait_for_completion 4193.035174 [0] migration/0[15] 0.000 0.003 0.009 __traceiter_sched_switch <- __traceiter_sched_switch <- __sched_text_start <- smpboot_thread_fn <- kthread <- ret_from_fork 4193.035207 [1] perf[277062] 0.000 0.000 0.000 __traceiter_sched_switch <- __traceiter_sched_switch <- __sched_text_start <- preempt_schedule_common <- __cond_resched <- __wait_for_common <- wait_for_completion 4193.035214 [1] migration/1[21] 0.000 0.003 0.007 __traceiter_sched_switch <- __traceiter_sched_switch <- __sched_text_start <- smpboot_thread_fn <- kthread <- ret_from_fork Fixes: 9c95e4ef06572349 ("perf evlist: Add evlist__findnew_tracking_event() helper") Reviewed-by: Ian Rogers Signed-off-by: Yang Jihong Cc: Adrian Hunter Cc: Alexander Shishkin Cc: Ingo Molnar Cc: James Clark Cc: Jiri Olsa Cc: Kan Liang Cc: Mark Rutland Cc: Namhyung Kim Cc: Peter Zijlstra Cc: Yang Jihong Link: https://lore.kernel.org/r/20240401062724.1006010-2-yangjihong@bytedance.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 5522002a91fbb1ed9395ddccc7d306b8a4e431a2 Author: Namhyung Kim Date: Fri Mar 22 15:43:12 2024 -0700 perf annotate: Get rid of duplicate --group option item [ Upstream commit 374af9f1f06b5e991c810d2e4983d6f58df32136 ] The options array in cmd_annotate() has duplicate --group options. It only needs one and let's get rid of the other. $ perf annotate -h 2>&1 | grep group --group Show event group information together --group Show event group information together Fixes: 7ebaf4890f63eb90 ("perf annotate: Support '--group' option") Reviewed-by: Kan Liang Signed-off-by: Namhyung Kim Cc: Adrian Hunter Cc: Ian Rogers Cc: Ingo Molnar Cc: Jin Yao Cc: Jiri Olsa Cc: Peter Zijlstra Link: https://lore.kernel.org/r/20240322224313.423181-1-namhyung@kernel.org Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 1976507cd8704fc8f48157a44b49105294226b37 Author: Randy Dunlap Date: Fri Dec 22 21:05:11 2023 -0800 counter: linux/counter.h: fix Excess kernel-doc description warning [ Upstream commit 416bdb89605d960405178b9bf04df512d1ace1a3 ] Remove the @priv: line to prevent the kernel-doc warning: include/linux/counter.h:400: warning: Excess struct member 'priv' description in 'counter_device' Signed-off-by: Randy Dunlap Fixes: f2ee4759fb70 ("counter: remove old and now unused registration API") Link: https://lore.kernel.org/r/20231223050511.13849-1-rdunlap@infradead.org Signed-off-by: William Breathitt Gray Signed-off-by: Sasha Levin commit 6896b6b2e2d9ec4e1b0acb4c1698a75a4b34d125 Author: Marco Pagani Date: Fri Mar 22 18:18:37 2024 +0100 fpga: bridge: add owner module and take its refcount [ Upstream commit 1da11f822042eb6ef4b6064dc048f157a7852529 ] The current implementation of the fpga bridge assumes that the low-level module registers a driver for the parent device and uses its owner pointer to take the module's refcount. This approach is problematic since it can lead to a null pointer dereference while attempting to get the bridge if the parent device does not have a driver. To address this problem, add a module owner pointer to the fpga_bridge struct and use it to take the module's refcount. Modify the function for registering a bridge to take an additional owner module parameter and rename it to avoid conflicts. Use the old function name for a helper macro that automatically sets the module that registers the bridge as the owner. This ensures compatibility with existing low-level control modules and reduces the chances of registering a bridge without setting the owner. Also, update the documentation to keep it consistent with the new interface for registering an fpga bridge. Other changes: opportunistically move put_device() from __fpga_bridge_get() to fpga_bridge_get() and of_fpga_bridge_get() to improve code clarity since the bridge device is taken in these functions. Fixes: 21aeda950c5f ("fpga: add fpga bridge framework") Suggested-by: Greg Kroah-Hartman Suggested-by: Xu Yilun Reviewed-by: Russ Weight Signed-off-by: Marco Pagani Acked-by: Xu Yilun Link: https://lore.kernel.org/r/20240322171839.233864-1-marpagan@redhat.com Signed-off-by: Xu Yilun Signed-off-by: Sasha Levin commit 62ac496a01c9337a11362cea427038ba621ca9eb Author: Marco Pagani Date: Tue Mar 5 20:29:26 2024 +0100 fpga: manager: add owner module and take its refcount [ Upstream commit 4d4d2d4346857bf778fafaa97d6f76bb1663e3c9 ] The current implementation of the fpga manager assumes that the low-level module registers a driver for the parent device and uses its owner pointer to take the module's refcount. This approach is problematic since it can lead to a null pointer dereference while attempting to get the manager if the parent device does not have a driver. To address this problem, add a module owner pointer to the fpga_manager struct and use it to take the module's refcount. Modify the functions for registering the manager to take an additional owner module parameter and rename them to avoid conflicts. Use the old function names for helper macros that automatically set the module that registers the manager as the owner. This ensures compatibility with existing low-level control modules and reduces the chances of registering a manager without setting the owner. Also, update the documentation to keep it consistent with the new interface for registering an fpga manager. Other changes: opportunistically move put_device() from __fpga_mgr_get() to fpga_mgr_get() and of_fpga_mgr_get() to improve code clarity since the manager device is taken in these functions. Fixes: 654ba4cc0f3e ("fpga manager: ensure lifetime with of_fpga_mgr_get") Suggested-by: Greg Kroah-Hartman Suggested-by: Xu Yilun Signed-off-by: Marco Pagani Acked-by: Xu Yilun Link: https://lore.kernel.org/r/20240305192926.84886-1-marpagan@redhat.com Signed-off-by: Xu Yilun Signed-off-by: Sasha Levin commit 5fcf6f4dd62104ba0d0feba28e0ca0e30017e83d Author: Chao Yu Date: Tue Mar 26 19:28:45 2024 +0800 f2fs: fix to wait on page writeback in __clone_blkaddrs() [ Upstream commit d3876e34e7e789e2cbdd782360fef2a777391082 ] In below race condition, dst page may become writeback status in __clone_blkaddrs(), it needs to wait writeback before update, fix it. Thread A GC Thread - f2fs_move_file_range - filemap_write_and_wait_range(dst) - gc_data_segment - f2fs_down_write(dst) - move_data_page - set_page_writeback(dst_page) - f2fs_submit_page_write - f2fs_up_write(dst) - f2fs_down_write(dst) - __exchange_data_block - __clone_blkaddrs - f2fs_get_new_data_page - memcpy_page Fixes: 0a2aa8fbb969 ("f2fs: refactor __exchange_data_block for speed up") Signed-off-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit e8b485e39b4d17afa9a2821fc778d5a67abfc03a Author: Chao Yu Date: Wed Mar 27 15:42:23 2024 +0800 f2fs: multidev: fix to recognize valid zero block address [ Upstream commit 33e62cd7b4c281cd737c62e5d8c4f0e602a8c5c5 ] As reported by Yi Zhang in mailing list [1], kernel warning was catched during zbd/010 test as below: ./check zbd/010 zbd/010 (test gap zone support with F2FS) [failed] runtime ... 3.752s something found in dmesg: [ 4378.146781] run blktests zbd/010 at 2024-02-18 11:31:13 [ 4378.192349] null_blk: module loaded [ 4378.209860] null_blk: disk nullb0 created [ 4378.413285] scsi_debug:sdebug_driver_probe: scsi_debug: trim poll_queues to 0. poll_q/nr_hw = (0/1) [ 4378.422334] scsi host15: scsi_debug: version 0191 [20210520] dev_size_mb=1024, opts=0x0, submit_queues=1, statistics=0 [ 4378.434922] scsi 15:0:0:0: Direct-Access-ZBC Linux scsi_debug 0191 PQ: 0 ANSI: 7 [ 4378.443343] scsi 15:0:0:0: Power-on or device reset occurred [ 4378.449371] sd 15:0:0:0: Attached scsi generic sg5 type 20 [ 4378.449418] sd 15:0:0:0: [sdf] Host-managed zoned block device ... (See '/mnt/tests/gitlab.com/api/v4/projects/19168116/repository/archive.zip/storage/blktests/blk/blktests/results/nodev/zbd/010.dmesg' WARNING: CPU: 22 PID: 44011 at fs/iomap/iter.c:51 CPU: 22 PID: 44011 Comm: fio Not tainted 6.8.0-rc3+ #1 RIP: 0010:iomap_iter+0x32b/0x350 Call Trace: __iomap_dio_rw+0x1df/0x830 f2fs_file_read_iter+0x156/0x3d0 [f2fs] aio_read+0x138/0x210 io_submit_one+0x188/0x8c0 __x64_sys_io_submit+0x8c/0x1a0 do_syscall_64+0x86/0x170 entry_SYSCALL_64_after_hwframe+0x6e/0x76 Shinichiro Kawasaki helps to analyse this issue and proposes a potential fixing patch in [2]. Quoted from reply of Shinichiro Kawasaki: "I confirmed that the trigger commit is dbf8e63f48af as Yi reported. I took a look in the commit, but it looks fine to me. So I thought the cause is not in the commit diff. I found the WARN is printed when the f2fs is set up with multiple devices, and read requests are mapped to the very first block of the second device in the direct read path. In this case, f2fs_map_blocks() and f2fs_map_blocks_cached() modify map->m_pblk as the physical block address from each block device. It becomes zero when it is mapped to the first block of the device. However, f2fs_iomap_begin() assumes that map->m_pblk is the physical block address of the whole f2fs, across the all block devices. It compares map->m_pblk against NULL_ADDR == 0, then go into the unexpected branch and sets the invalid iomap->length. The WARN catches the invalid iomap->length. This WARN is printed even for non-zoned block devices, by following steps. - Create two (non-zoned) null_blk devices memory backed with 128MB size each: nullb0 and nullb1. # mkfs.f2fs /dev/nullb0 -c /dev/nullb1 # mount -t f2fs /dev/nullb0 "${mount_dir}" # dd if=/dev/zero of="${mount_dir}/test.dat" bs=1M count=192 # dd if="${mount_dir}/test.dat" of=/dev/null bs=1M count=192 iflag=direct ..." So, the root cause of this issue is: when multi-devices feature is on, f2fs_map_blocks() may return zero blkaddr in non-primary device, which is a verified valid block address, however, f2fs_iomap_begin() treats it as an invalid block address, and then it triggers the warning in iomap framework code. Finally, as discussed, we decide to use a more simple and direct way that checking (map.m_flags & F2FS_MAP_MAPPED) condition instead of (map.m_pblk != NULL_ADDR) to fix this issue. Thanks a lot for the effort of Yi Zhang and Shinichiro Kawasaki on this issue. [1] https://lore.kernel.org/linux-f2fs-devel/CAHj4cs-kfojYC9i0G73PRkYzcxCTex=-vugRFeP40g_URGvnfQ@mail.gmail.com/ [2] https://lore.kernel.org/linux-f2fs-devel/gngdj77k4picagsfdtiaa7gpgnup6fsgwzsltx6milmhegmjff@iax2n4wvrqye/ Reported-by: Yi Zhang Closes: https://lore.kernel.org/linux-f2fs-devel/CAHj4cs-kfojYC9i0G73PRkYzcxCTex=-vugRFeP40g_URGvnfQ@mail.gmail.com/ Tested-by: Shin'ichiro Kawasaki Tested-by: Yi Zhang Fixes: 1517c1a7a445 ("f2fs: implement iomap operations") Fixes: 8d3c1fa3fa5e ("f2fs: don't rely on F2FS_MAP_* in f2fs_iomap_begin") Signed-off-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit 48375b34ad75c335324bf9ee674a7cdd50cf54ed Author: Tengfei Fan Date: Tue Mar 12 10:58:07 2024 +0800 dt-bindings: pinctrl: qcom: update functions to match with driver [ Upstream commit 842ecb5fcf8de17dfde11d4ec5f41930f0076887 ] Some functions were consolidated in the SM4450 pinctrl driver, but they had not been updated in the binding file before the previous SM4450 pinctrl patch series was merged. Update functions in this binding file to match with SM4450 pinctrl driver. Some functions need to be consolidated and some functions need to be removed. The following functions are removed: - atest_char0, atest_char1, atest_char2, atest_char3 - atest_usb00, atest_usb01, atest_usb02, atest_usb03 - audio_ref - cci_async - cci_timer0, cci_timer1, cci_timer2, cci_timer3, cci_timer4 - cmu_rng0, cmu_rng1, cmu_rng2, cmu_rng3 - coex_uart1 - cri_trng0, cri_trng1 - dbg_out - ddr_pxi0, ddr_pxi1 - dp0_hot - gcc_gp1, gcc_gp2, gcc_gp3 - ibi_i3c - jitter_bist - mdp_vsync0, mdp_vsync1, mdp_vsync2, mdp_vsync3 - mi2s0_data0, mi2s0_data1, mi2s0_sck, mi2s0_ws, mi2s2_data0, mi2s2_data1, mi2s2_sck, mi2s2_ws, mi2s_mclk0, mi2s_mclk1 - nav_gpio0, nav_gpio1, nav_gpio2 - phase_flag0, phase_flag1, phase_flag10, phase_flag11, phase_flag12, phase_flag13, phase_flag14, phase_flag15, phase_flag16, phase_flag17, phase_flag18, phase_flag19, phase_flag2, phase_flag20, phase_flag21, phase_flag22, phase_flag23, phase_flag24, phase_flag25, phase_flag26, phase_flag27, phase_flag28, phase_flag29, phase_flag3, phase_flag30, phase_flag31, phase_flag4, phase_flag5, phase_flag6, phase_flag7, phase_flag8, phase_flag9 - pll_bist, pll_clk - prng_rosc0, prng_rosc1, prng_rosc2, prng_rosc3 - qdss_gpio0, qdss_gpio1, qdss_gpio10, qdss_gpio11, qdss_gpio12, qdss_gpio13, qdss_gpio14, qdss_gpio15, qdss_gpio2, qdss_gpio3, qdss_gpio4, qdss_gpio5, qdss_gpio6, qdss_gpio7, qdss_gpio8, qdss_gpio9 - qlink0_wmss - qup0_se5, qup0_se6, qup0_se7, qup1_se5, qup1_se6 - sd_write - tb_trig - tgu_ch0, tgu_ch1, tgu_ch2, tgu_ch3 - tmess_prng0, tmess_prng1, tmess_prng2, tmess_prng3 - tsense_pwm1, tsense_pwm2 - uim0_clk, uim0_data, uim0_present, uim0_reset, uim1_clk, uim1_data, uim1_present, uim1_reset - usb0_hs, usb0_phy - vsense_trigger The following functions are added: - atest_char - atest_usb0 - audio_ref_clk - cci - cci_async_in0 - cmu_rng - coex_uart1_rx, coex_uart1_tx - dbg_out_clk - ddr_pxi0_test, ddr_pxi1_test - gcc_gp1_clk, gcc_gp2_clk, gcc_gp3_clk - ibi_i3c_qup0, ibi_i3c_qup1 - jitter_bist_ref - mdp_vsync - nav - phase_flag - pll_bist_sync, pll_clk_aux - prng_rosc - qlink0_wmss_reset - sd_write_protect - tb_trig_sdc1, tb_trig_sdc2 - tgu_ch0_trigout, tgu_ch1_trigout, tgu_ch2_trigout, tgu_ch3_trigout - tmess_prng - tsense_pwm1_out, tsense_pwm2_out - uim0, uim1 - usb0_hs_ac, usb0_phy_ps - vsense_trigger_mirnat - wlan1_adc_dtest0, wlan1_adc_dtest1 Fixes: 7bf8b78f86db ("dt-bindings: pinctrl: qcom: Add SM4450 pinctrl") Signed-off-by: Tengfei Fan Acked-by: Krzysztof Kozlowski Message-ID: <20240312025807.26075-3-quic_tengfan@quicinc.com> Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit 895cdd9aa9546523df839f9cc1488a0ecc1e0731 Author: Rui Miguel Silva Date: Mon Mar 25 22:09:55 2024 +0000 greybus: lights: check return of get_channel_from_mode [ Upstream commit a1ba19a1ae7cd1e324685ded4ab563e78fe68648 ] If channel for the given node is not found we return null from get_channel_from_mode. Make sure we validate the return pointer before using it in two of the missing places. This was originally reported in [0]: Found by Linux Verification Center (linuxtesting.org) with SVACE. [0] https://lore.kernel.org/all/20240301190425.120605-1-m.lobanov@rosalinux.ru Fixes: 2870b52bae4c ("greybus: lights: add lights implementation") Reported-by: Mikhail Lobanov Suggested-by: Mikhail Lobanov Suggested-by: Alex Elder Signed-off-by: Rui Miguel Silva Link: https://lore.kernel.org/r/20240325221549.2185265-1-rmfrfs@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit affdf720b62bdf32d1401842ac5a4fc7554bc076 Author: Andy Shevchenko Date: Mon Mar 4 16:04:32 2024 +0200 iio: core: Leave private pointer NULL when no private data supplied [ Upstream commit f0245ab389330cbc1d187e358a5b890d9f5383db ] In iio_device_alloc() when size of the private data is 0, the private pointer is calculated to point behind the valid data. Leave it NULL when no private data supplied. Fixes: 6d4ebd565d15 ("iio: core: wrap IIO device into an iio_dev_opaque object") Signed-off-by: Andy Shevchenko Reviewed-by: David Lechner Link: https://lore.kernel.org/r/20240304140650.977784-2-andriy.shevchenko@linux.intel.com Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit 62bf20dea38c478cadac060c8178b549ed7c482a Author: Arnaldo Carvalho de Melo Date: Thu Mar 21 11:13:30 2024 -0300 perf probe: Add missing libgen.h header needed for using basename() [ Upstream commit 581037151910126a7934e369e4b6ac70eda9a703 ] This prototype is obtained indirectly, by luck, from some other header in probe-event.c in most systems, but recently exploded on alpine:edge: 8 13.39 alpine:edge : FAIL gcc version 13.2.1 20240309 (Alpine 13.2.1_git20240309) util/probe-event.c: In function 'convert_exec_to_group': util/probe-event.c:225:16: error: implicit declaration of function 'basename' [-Werror=implicit-function-declaration] 225 | ptr1 = basename(exec_copy); | ^~~~~~~~ util/probe-event.c:225:14: error: assignment to 'char *' from 'int' makes pointer from integer without a cast [-Werror=int-conversion] 225 | ptr1 = basename(exec_copy); | ^ cc1: all warnings being treated as errors make[3]: *** [/git/perf-6.8.0/tools/build/Makefile.build:158: util] Error 2 Fix it by adding the libgen.h header where basename() is prototyped. Fixes: fb7345bbf7fad9bf ("perf probe: Support basic dwarf-based operations on uprobe events") Cc: Masami Hiramatsu Cc: Adrian Hunter Cc: Ian Rogers Cc: Jiri Olsa Cc: Namhyung Kim Link: https://lore.kernel.org/lkml/ Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 51325935ddd82a21ee5980feafc67e76283590f8 Author: Ian Rogers Date: Thu Feb 29 23:46:38 2024 -0800 perf test: Use a single fd for the child process out/err [ Upstream commit e120f7091a25460a19967380725558c36bca7c6c ] Switch from dumping err then out, to a single file descriptor for both of them. This allows the err and output to be correctly interleaved in verbose output. Fixes: b482f5f8e0168f1e ("perf tests: Add option to run tests in parallel") Signed-off-by: Ian Rogers Cc: Adrian Hunter Cc: Alexander Shishkin Cc: Athira Rajeev Cc: Christian Brauner Cc: Disha Goel Cc: Ian Rogers Cc: Ingo Molnar Cc: James Clark Cc: Jiri Olsa Cc: Kajol Jain Cc: Kan Liang Cc: K Prateek Nayak Cc: Mark Rutland Cc: Namhyung Kim Cc: Peter Zijlstra Cc: Song Liu Cc: Tim Chen Cc: Yicong Yang Link: https://lore.kernel.org/r/20240301074639.2260708-3-irogers@google.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit a1b6bc10666e47d45a8c35c1f6b8e19c4cf9f205 Author: Ian Rogers Date: Thu Feb 29 23:46:36 2024 -0800 perf record: Delete session after stopping sideband thread [ Upstream commit 88ce0106a1f603bf360cb397e8fe293f8298fabb ] The session has a header in it which contains a perf env with bpf_progs. The bpf_progs are accessed by the sideband thread and so the sideband thread must be stopped before the session is deleted, to avoid a use after free. This error was detected by AddressSanitizer in the following: ==2054673==ERROR: AddressSanitizer: heap-use-after-free on address 0x61d000161e00 at pc 0x55769289de54 bp 0x7f9df36d4ab0 sp 0x7f9df36d4aa8 READ of size 8 at 0x61d000161e00 thread T1 #0 0x55769289de53 in __perf_env__insert_bpf_prog_info util/env.c:42 #1 0x55769289dbb1 in perf_env__insert_bpf_prog_info util/env.c:29 #2 0x557692bbae29 in perf_env__add_bpf_info util/bpf-event.c:483 #3 0x557692bbb01a in bpf_event__sb_cb util/bpf-event.c:512 #4 0x5576928b75f4 in perf_evlist__poll_thread util/sideband_evlist.c:68 #5 0x7f9df96a63eb in start_thread nptl/pthread_create.c:444 #6 0x7f9df9726a4b in clone3 ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81 0x61d000161e00 is located 384 bytes inside of 2136-byte region [0x61d000161c80,0x61d0001624d8) freed by thread T0 here: #0 0x7f9dfa6d7288 in __interceptor_free libsanitizer/asan/asan_malloc_linux.cpp:52 #1 0x557692978d50 in perf_session__delete util/session.c:319 #2 0x557692673959 in __cmd_record tools/perf/builtin-record.c:2884 #3 0x55769267a9f0 in cmd_record tools/perf/builtin-record.c:4259 #4 0x55769286710c in run_builtin tools/perf/perf.c:349 #5 0x557692867678 in handle_internal_command tools/perf/perf.c:402 #6 0x557692867a40 in run_argv tools/perf/perf.c:446 #7 0x557692867fae in main tools/perf/perf.c:562 #8 0x7f9df96456c9 in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 Fixes: 657ee5531903339b ("perf evlist: Introduce side band thread") Signed-off-by: Ian Rogers Cc: Adrian Hunter Cc: Alexander Shishkin Cc: Athira Rajeev Cc: Christian Brauner Cc: Disha Goel Cc: Ingo Molnar Cc: James Clark Cc: Jiri Olsa Cc: Kajol Jain Cc: Kan Liang Cc: K Prateek Nayak Cc: Mark Rutland Cc: Namhyung Kim Cc: Peter Zijlstra Cc: Song Liu Cc: Tim Chen Cc: Yicong Yang Link: https://lore.kernel.org/r/20240301074639.2260708-1-irogers@google.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 818e41995bf3654e27c7f470a77cb4f6e90d338e Author: Ethan Adams Date: Thu Mar 14 15:20:12 2024 -0700 perf build: Fix out of tree build related to installation of sysreg-defs [ Upstream commit efae55bb78cf8722c7df01cd974197dfd13ece39 ] It seems that a previous modification to sysreg-defs, which corrected emitting the header to the specified output directory, exposed missing subdir, prefix variables. This breaks out of tree builds of perf as the file is now built into the output directory, but still tries to descend into output directory as a subdir. Fixes: a29ee6aea7030786 ("perf build: Ensure sysreg-defs Makefile respects output dir") Reviewed-by: Oliver Upton Reviewed-by: Tycho Andersen Signed-off-by: Ethan Adams Tested-by: Tycho Andersen Cc: Adrian Hunter Cc: Alexander Shishkin Cc: Ian Rogers Cc: Ingo Molnar Cc: Jiri Olsa Cc: Mark Rutland Cc: Namhyung Kim Cc: Peter Zijlstra Link: https://lore.kernel.org/r/20240314222012.47193-1-j.ethan.adams@gmail.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin