drivers/usb/hub.c: delay hub_hc_release_resources() until address0_mutex is held #5
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This reverts commit 608e7c0.
This reverts commit 284efa5.
Signed-off-by: Antheas Kapenekakis <[email protected]>
…lly" This reverts commit 891f889. Revert because of compatibility issues of MS Surface devices and GRUB with NX. In short, these devices get stuck on boot with NX advertised. So to not advertise it, add the respective option back in. Signed-off-by: Maximilian Luz <[email protected]> Patchset: secureboot
On some Surface 3, the DMI table gets corrupted for unknown reasons
and breaks existing DMI matching used for device-specific quirks.
This commit adds the (broken) DMI data into dmi_system_id tables used
for quirks so that each driver can enable quirks even on the affected
systems.
On affected systems, DMI data will look like this:
$ grep . /sys/devices/virtual/dmi/id/{bios_vendor,board_name,board_vendor,\
chassis_vendor,product_name,sys_vendor}
/sys/devices/virtual/dmi/id/bios_vendor:American Megatrends Inc.
/sys/devices/virtual/dmi/id/board_name:OEMB
/sys/devices/virtual/dmi/id/board_vendor:OEMB
/sys/devices/virtual/dmi/id/chassis_vendor:OEMB
/sys/devices/virtual/dmi/id/product_name:OEMB
/sys/devices/virtual/dmi/id/sys_vendor:OEMB
Expected:
$ grep . /sys/devices/virtual/dmi/id/{bios_vendor,board_name,board_vendor,\
chassis_vendor,product_name,sys_vendor}
/sys/devices/virtual/dmi/id/bios_vendor:American Megatrends Inc.
/sys/devices/virtual/dmi/id/board_name:Surface 3
/sys/devices/virtual/dmi/id/board_vendor:Microsoft Corporation
/sys/devices/virtual/dmi/id/chassis_vendor:Microsoft Corporation
/sys/devices/virtual/dmi/id/product_name:Surface 3
/sys/devices/virtual/dmi/id/sys_vendor:Microsoft Corporation
Signed-off-by: Tsuchiya Yuto <[email protected]>
Patchset: surface3-oemb
The most recent firmware of the 88W8897 card reports a hardcoded LTR value to the system during initialization, probably as an (unsuccessful) attempt of the developers to fix firmware crashes. This LTR value prevents most of the Microsoft Surface devices from entering deep powersaving states (either platform C-State 10 or S0ix state), because the exit latency of that state would be higher than what the card can tolerate. Turns out the card works just the same (including the firmware crashes) no matter if that hardcoded LTR value is reported or not, so it's kind of useless and only prevents us from saving power. To get rid of those hardcoded LTR reports, it's possible to reset the PCI bridge device after initializing the cards firmware. I'm not exactly sure why that works, maybe the power management subsystem of the PCH resets its stored LTR values when doing a function level reset of the bridge device. Doing the reset once after starting the wifi firmware works very well, probably because the firmware only reports that LTR value a single time during firmware startup. Patchset: mwifiex
Currently, mwifiex fw will crash after suspend on recent kernel series. On Windows, it seems that the root port of wifi will never enter D3 state (stay on D0 state). And on Linux, disabling the D3 state for the bridge fixes fw crashing after suspend. This commit disables the D3 state of root port on driver initialization and fixes fw crashing after suspend. Signed-off-by: Tsuchiya Yuto <[email protected]> Patchset: mwifiex
The Marvell 88W8897 combined wifi and bluetooth card (pcie+usb version) is used in a lot of Microsoft Surface devices, and all those devices suffer from very low 2.4GHz wifi connection speeds while bluetooth is enabled. The reason for that is that the default passive scanning interval for Bluetooth Low Energy devices is quite high in Linux (interval of 60 msec and scan window of 30 msec, see hci_core.c), and the Marvell chip is known for its bad bt+wifi coexisting performance. So decrease that passive scan interval and make the scan window shorter on this particular device to allow for spending more time transmitting wifi signals: The new scan interval is 250 msec (0x190 * 0.625 msec) and the new scan window is 6.25 msec (0xa * 0,625 msec). This change has a very large impact on the 2.4GHz wifi speeds and gets it up to performance comparable with the Windows driver, which seems to apply a similar quirk. The interval and window length were tested and found to work very well with a lot of Bluetooth Low Energy devices, including the Surface Pen, a Bluetooth Speaker and two modern Bluetooth headphones. All devices were discovered immediately after turning them on. Even lower values were also tested, but they introduced longer delays until devices get discovered. Patchset: mwifiex
Some Surface devices, specifically the Surface Go and AMD version of the Surface Laptop 3 (wich both come with QCA6174 WiFi chips), work better with a different board file, as it seems that the firmeware included upstream is buggy. As it is generally not a good idea to randomly overwrite files, let alone doing so via packages, we add module parameters to override those file names in the driver. This allows us to package/deploy the override via a modprobe.d config. Signed-off-by: Maximilian Luz <[email protected]> Patchset: ath10k
Signed-off-by: Dorian Stoll <[email protected]> Patchset: ipts
Adds a quirk so that IOMMU uses passthrough mode for the IPTS device. Otherwise, when IOMMU is enabled, IPTS produces DMAR errors like: DMAR: [DMA Read NO_PASID] Request device [00:16.4] fault addr 0x104ea3000 [fault reason 0x06] PTE Read access is not set This is very similar to the bug described at: https://bugs.launchpad.net/bugs/1958004 Fixed with the following patch which this patch basically copies: https://launchpadlibrarian.net/586396847/43255ca.diff Signed-off-by: Dorian Stoll <[email protected]> Patchset: ipts
Based on linux-surface/intel-precise-touch@8abe268 Signed-off-by: Dorian Stoll <[email protected]> Patchset: ipts
Signed-off-by: Dorian Stoll <[email protected]> Patchset: ithc
Based on quo/ithc-linux@34539af4726d. Signed-off-by: Maximilian Stoll <[email protected]> Patchset: ithc
Microsoft Surface Pro 4 and Book 1 devices access the MSHW0030 I2C
device via a generic serial bus operation region and RawBytes read
access. On the Surface Book 1, this access is required to turn on (and
off) the discrete GPU.
Multiple things are to note here:
a) The RawBytes access is device/driver dependent. The ACPI
specification states:
> Raw accesses assume that the writer has knowledge of the bus that
> the access is made over and the device that is being accessed. The
> protocol may only ensure that the buffer is transmitted to the
> appropriate driver, but the driver must be able to interpret the
> buffer to communicate to a register.
Thus this implementation may likely not work on other devices
accessing I2C via the RawBytes accessor type.
b) The MSHW0030 I2C device is an HID-over-I2C device which seems to
serve multiple functions:
1. It is the main access point for the legacy-type Surface Aggregator
Module (also referred to as SAM-over-HID, as opposed to the newer
SAM-over-SSH/UART). It has currently not been determined on how
support for the legacy SAM should be implemented. Likely via a
custom HID driver.
2. It seems to serve as the HID device for the Integrated Sensor Hub.
This might complicate matters with regards to implementing a
SAM-over-HID driver required by legacy SAM.
In light of this, the simplest approach has been chosen for now.
However, it may make more sense regarding breakage and compatibility to
either provide functionality for replacing or enhancing the default
operation region handler via some additional API functions, or even to
completely blacklist MSHW0030 from the I2C core and provide a custom
driver for it.
Replacing/enhancing the default operation region handler would, however,
either require some sort of secondary driver and access point for it,
from which the new API functions would be called and the new handler
(part) would be installed, or hard-coding them via some sort of
quirk-like interface into the I2C core.
Signed-off-by: Maximilian Luz <[email protected]>
Patchset: surface-sam-over-hid
Add driver exposing the discrete GPU power-switch of the Microsoft Surface Book 1 to user-space. On the Surface Book 1, the dGPU power is controlled via the Surface System Aggregator Module (SAM). The specific SAM-over-HID command for this is exposed via ACPI. This module provides a simple driver exposing the ACPI call via a sysfs parameter to user-space, so that users can easily power-on/-off the dGPU. Patchset: surface-sam-over-hid
The power button on the AMD variant of the Surface Laptop uses the same MSHW0040 device ID as the 5th and later generation of Surface devices, however they report 0 for their OEM platform revision. As the _DSM does not exist on the devices requiring special casing, check for the existance of the _DSM to determine if soc_button_array should be loaded. Fixes: c394159 ("Input: soc_button_array - add support for newer surface devices") Co-developed-by: Maximilian Luz <[email protected]> Signed-off-by: Sachi King <[email protected]> Patchset: surface-button
The AMD variant of the Surface Laptop report 0 for their OEM platform revision. The Surface devices that require the surfacepro3_button driver do not have the _DSM that gets the OEM platform revision. If the method does not exist, load surfacepro3_button. Fixes: 64dd243 ("platform/x86: surfacepro3_button: Fix device check") Co-developed-by: Maximilian Luz <[email protected]> Signed-off-by: Sachi King <[email protected]> Patchset: surface-button
The touchpad on the Type-Cover of the Surface Go 3 is sometimes not being initialized properly. Apply USB_QUIRK_DELAY_INIT to fix this issue. More specifically, the device in question is a fairly standard modern touchpad with pointer and touchpad input modes. During setup, the device needs to be switched from pointer- to touchpad-mode (which is done in hid-multitouch) to fully utilize it as intended. Unfortunately, however, this seems to occasionally fail silently, leaving the device in pointer-mode. Applying USB_QUIRK_DELAY_INIT seems to fix this. Link: linux-surface/linux-surface#1059 Signed-off-by: Maximilian Luz <[email protected]> Patchset: surface-typecover
The Type Cover for Microsoft Surface devices supports a special usb control request to disable or enable the built-in keyboard backlight. On Windows, this request happens when putting the device into suspend or resuming it, without it the backlight of the Type Cover will remain enabled for some time even though the computer is suspended, which looks weird to the user. So add support for this special usb control request to hid-multitouch, which is the driver that's handling the Type Cover. The reason we have to use a pm_notifier for this instead of the usual suspend/resume methods is that those won't get called in case the usb device is already autosuspended. Also, if the device is autosuspended, we have to briefly autoresume it in order to send the request. Doing that should be fine, the usb-core driver does something similar during suspend inside choose_wakeup(). To make sure we don't send that request to every device but only to devices which support it, add a new quirk MT_CLS_WIN_8_MS_SURFACE_TYPE_COVER to hid-multitouch. For now this quirk is only enabled for the usb id of the Surface Pro 2017 Type Cover, which is where I confirmed that it's working. Patchset: surface-typecover
The Surface Pro Type Cover has several non standard HID usages in it's hid report descriptor. I noticed that, upon folding the typecover back, a vendor specific range of 4 32 bit integer hid usages is transmitted. Only the first byte of the message seems to convey reliable information about the keyboard state. 0x22 => Normal (keys enabled) 0x33 => Folded back (keys disabled) 0x53 => Rotated left/right side up (keys disabled) 0x13 => Cover closed (keys disabled) 0x43 => Folded back and Tablet upside down (keys disabled) This list may not be exhaustive. The tablet mode switch will be disabled for a value of 0x22 and enabled on any other value. Patchset: surface-typecover
Work around buggy EFI firmware: On some Microsoft Surface devices (Surface Pro 9 and Surface Laptop 5) the EFI ResetSystem call with EFI_RESET_SHUTDOWN doesn't function properly. Instead of shutting the system down, it returns and the system stays on. It turns out that this only happens after PCI shutdown callbacks ran for specific devices. Excluding those devices from the shutdown process makes the ResetSystem call work as expected. TODO: Maybe we can find a better way or the root cause of this? Not-Signed-off-by: Maximilian Luz <[email protected]> Patchset: surface-shutdown
Add the lid GPE used by the Surface Pro 9. Signed-off-by: Maximilian Luz <[email protected]> Patchset: surface-gpe
… device The clk and regulator frameworks expect clk/regulator consumer-devices to have info about the consumed clks/regulators described in the device's fw_node. To work around cases where this info is not present in the firmware tables, which is often the case on x86/ACPI devices, both frameworks allow the provider-driver to attach info about consumers to the clks/regulators when registering these. This causes problems with the probe ordering wrt drivers for consumers of these clks/regulators. Since the lookups are only registered when the provider-driver binds, trying to get these clks/regulators before then results in a -ENOENT error for clks and a dummy regulator for regulators. One case where we hit this issue is camera sensors such as e.g. the OV8865 sensor found on the Microsoft Surface Go. The sensor uses clks, regulators and GPIOs provided by a TPS68470 PMIC which is described in an INT3472 ACPI device. There is special platform code handling this and setting platform_data with the necessary consumer info on the MFD cells instantiated for the PMIC under: drivers/platform/x86/intel/int3472. For this to work properly the ov8865 driver must not bind to the I2C-client for the OV8865 sensor until after the TPS68470 PMIC gpio, regulator and clk MFD cells have all been fully setup. The OV8865 on the Microsoft Surface Go is just one example, all X86 devices using the Intel IPU3 camera block found on recent Intel SoCs have similar issues where there is an INT3472 HID ACPI-device, which describes the clks and regulators, and the driver for this INT3472 device must be fully initialized before the sensor driver (any sensor driver) binds for things to work properly. On these devices the ACPI nodes describing the sensors all have a _DEP dependency on the matching INT3472 ACPI device (there is one per sensor). This allows solving the probe-ordering problem by delaying the enumeration (instantiation of the I2C-client in the ov8865 example) of ACPI-devices which have a _DEP dependency on an INT3472 device. The new acpi_dev_ready_for_enumeration() helper used for this is also exported because for devices, which have the enumeration_by_parent flag set, the parent-driver will do its own scan of child ACPI devices and it will try to enumerate those during its probe(). Code doing this such as e.g. the i2c-core-acpi.c code must call this new helper to ensure that it too delays the enumeration until all the _DEP dependencies are met on devices which have the new honor_deps flag set. Signed-off-by: Hans de Goede <[email protected]> Patchset: cameras
Intel IPU(Image Processing Unit) has its own (IO)MMU hardware, The IPU driver allocates its own page table that is not mapped via the DMA, and thus the Intel IOMMU driver blocks access giving this error: DMAR: DRHD: handling fault status reg 3 DMAR: [DMA Read] Request device [00:05.0] PASID ffffffff fault addr 7640600 [fault reason 06] PTE Read access is not set As IPU is not an external facing device which is not risky, so use IOMMU passthrough mode for Intel IPUs. Change-Id: I6dcccdadac308cf42e20a18e1b593381391e3e6b Depends-On: Iacd67578e8c6a9b9ac73285f52b4081b72fb68a6 Tracked-On: #JIITL8-411 Signed-off-by: Bingbu Cao <[email protected]> Signed-off-by: zouxiaoh <[email protected]> Signed-off-by: Xu Chongyang <[email protected]> Patchset: cameras
The TPS68470 PMIC has an I2C passthrough mode through which I2C traffic can be forwarded to a device connected to the PMIC as though it were connected directly to the system bus. Enable this mode when the chip is initialised. Signed-off-by: Daniel Scally <[email protected]> Patchset: cameras
ACPI _HID INT347E represents the OmniVision 7251 camera sensor. The driver for this sensor expects a single pin named "enable", but on some Microsoft Surface platforms the sensor is assigned a single GPIO who's type flag is INT3472_GPIO_TYPE_RESET. Remap the GPIO pin's function from "reset" to "enable". This is done outside of the existing remap table since it is a more widespread discrepancy than that method is designed for. Additionally swap the polarity of the pin to match the driver's expectation. Signed-off-by: Daniel Scally <[email protected]> Patchset: cameras
Update the control ID for the gain control in the ov7251 driver to V4L2_CID_ANALOGUE_GAIN. Signed-off-by: Daniel Scally <[email protected]> Patchset: cameras
Modify msi_wmi_platform_query() to reuse the input buffer for returning the result of a WMI method call. Using a separate output buffer to return the result is unnecessary because the WMI interface requires both buffers to have the same length anyway. Signed-off-by: Armin Wolf <[email protected]>
Adds fan curve support for the MSI platform. These devices contain support for two fans, where they are named CPU and GPU but in the case of the Claw series just map to left and right fan. Co-developed-by: Antheas Kapenekakis <[email protected]> Signed-off-by: Armin Wolf <[email protected]> Signed-off-by: Antheas Kapenekakis <[email protected]>
MSI uses the WMI interface as a passthrough for writes to the EC and uses a board name match and a quirk table from userspace on Windows. Therefore, there is no auto-detection functionality and we have to fallback to a quirk table. Introduce it here, prior to starting to add features to it. Signed-off-by: Antheas Kapenekakis <[email protected]>
MSI's version of platform profile in Windows is called shift mode. Introduce it here, and add a profile handler to it. It has 5 modes: sport, comfort, green, eco, and user. Confusingly, for the Claw, MSI only uses sport, green, and eco, where they correspond to performance, balanced, and low-power. Therefore, comfort is mapped to balanced-performance, and user to custom. Signed-off-by: Antheas Kapenekakis <[email protected]>
…ibutes Adds PL1, and PL2 support through the firmware attributes interface. The min and max values are quirked, and the attributes are only defined if they are set to a non-zero value. These values are meant to be set in conjunction with shift mode, where shift mode automatically sets an upper bound on PL1/PL2 (e.g., low-power would be used with 8W). Signed-off-by: Antheas Kapenekakis <[email protected]>
The battery of MSI laptops supports charge threshold. Add support for it. Signed-off-by: Antheas Kapenekakis <[email protected]>
Currently, the platform driver always exposes 4 fans, since the underlying WMI interface reads 4 values from the EC. However, most devices only have two fans. Therefore, at least in the case of the Claw series, quirk the driver to only show two hwmon fans. Signed-off-by: Antheas Kapenekakis <[email protected]>
… unload MSI software is a bit weird in that even when the manual fan curve is disabled, the fan speed is still somewhat affected by the curve. So we have to restore the fan curves on unload and PWM disable, as it is done in Windows. Suggested-by: Armin Wolf <[email protected]> Signed-off-by: Antheas Kapenekakis <[email protected]>
Signed-off-by: Antheas Kapenekakis <[email protected]>
Using a crit message breaks seamless boot by making the kernel wipe the framebuffer. This leads to an unfavorable user experience. Therefore, lower to err. Signed-off-by: Antheas Kapenekakis <[email protected]>
May break USB devices after a while if powersave mode is enabled. This reverts commit 59bfeaf.
This reverts commit 3a9626c. This breaks S4 because we end up setting the s3/s0ix flags even when we are entering s4 since prepare is used by both flows. The causes both the S3/s0ix and s4 flags to be set which breaks several checks in the driver which assume they are mutually exclusive. Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/3634 Cc: Mario Limonciello <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
Set the s3/s0ix and s4 flags in the pm notifier so that we can skip the resource evictions properly in pm prepare based on whether we are suspending or hibernating. Drop the eviction as processes are not frozen at this time, we we can end up getting stuck trying to evict VRAM while applications continue to submit work which causes the buffers to get pulled back into VRAM. v2: Move suspend flags out of pm notifier (Mario) Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/4178 Fixes: 2965e63 ("drm/amd: Add Suspend/Hibernate notification callback support") Cc: Mario Limonciello <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
Suspend and hibernate notifications are available specifically when the sequence starts and finishes. However there are no notifications during the process when tasks have been frozen. Introduce two new events `PM_SUSPEND_POST_FREEZE` and `PM_HIBERNATE_POST_FREEZE` that drivers can subscribe to and take different actions specifically knowing userspace is frozen. Suggested-by: Alex Deucher <[email protected]> Signed-off-by: Mario Limonciello <[email protected]>
commit 2965e63 ("drm/amd: Add Suspend/Hibernate notification callback support") introduced a VRAM eviction earlier in the PM sequences when swap was still available for evicting to. This helped to fix a number of memory pressure related bugs but also exposed a new one. If a userspace process is actively using the GPU when suspend starts then a deadlock could occur. For this reason, it was reverted. Re-introduce it and instead of going off the prepare notifier, use the PM notifiers that occur after processes have been frozen to do evictions. Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/4178 Fixes: 2965e63 ("drm/amd: Add Suspend/Hibernate notification callback support") Signed-off-by: Mario Limonciello <[email protected]>
…tex is held The call to hub_hc_release_resources() was incorrectly made before acquiring hcd->address0_mutex. Since the reset_device callback can put the device into the default state, this sequence risks violating the intended serialization. Moving the call ensures proper synchronization.
|
(This PR is solely with the purpose of verifying this patch;) @antheas is there a way I can build the Bazzite Kernel locally and get GRUB loading it? I'm unfamiliar if replacing a kernel on a ostree-based system is even safe; Apologies, I'm a newcomer when it comes on building the Kernel. (I could just build the source Kernel with my patch; But I'm unfamiliar if a given flavor of the Kernel is used on my system, based on bazzite-kernel) |
|
I don't know how to replace the kernel either. I have a dev ssd. There is a draft sync script that I never managed to finish. What is this fixing? |
Apparently a bug was introduced on torvalds@2b66ef84d0d2 that is similar to the bug report I initially opened a while ago; The bug freezes the xhci controller. Comments 42, 43 on https://bugzilla.kernel.org/show_bug.cgi?id=220069 explain it a bit more. |
|
The easiest way for you to test this is install an arch Linux distro such as endeavoros, then patch and build the stock 6.14 kernel and see if that fixes it. If it does I will include the fix and it will go into testing You can build the kernel with |
antheas
force-pushed
the
bazzite-6.14
branch
3 times, most recently
from
eed3fb0 to
d4364ec
Compare
|
Hopefully you found a solution |
antheas
pushed a commit
that referenced
this pull request
Jun 23, 2025
[ Upstream commit ee684de ] As shown in [1], it is possible to corrupt a BPF ELF file such that arbitrary BPF instructions are loaded by libbpf. This can be done by setting a symbol (BPF program) section offset to a large (unsigned) number such that <section start + symbol offset> overflows and points before the section data in the memory. Consider the situation below where: - prog_start = sec_start + symbol_offset <-- size_t overflow here - prog_end = prog_start + prog_size prog_start sec_start prog_end sec_end | | | | v v v v .....................|################################|............ The report in [1] also provides a corrupted BPF ELF which can be used as a reproducer: $ readelf -S crash Section Headers: [Nr] Name Type Address Offset Size EntSize Flags Link Info Align ... [ 2] uretprobe.mu[...] PROGBITS 0000000000000000 00000040 0000000000000068 0000000000000000 AX 0 0 8 $ readelf -s crash Symbol table '.symtab' contains 8 entries: Num: Value Size Type Bind Vis Ndx Name ... 6: ffffffffffffffb8 104 FUNC GLOBAL DEFAULT 2 handle_tp Here, the handle_tp prog has section offset ffffffffffffffb8, i.e. will point before the actual memory where section 2 is allocated. This is also reported by AddressSanitizer: ================================================================= ==1232==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x7c7302fe0000 at pc 0x7fc3046e4b77 bp 0x7ffe64677cd0 sp 0x7ffe64677490 READ of size 104 at 0x7c7302fe0000 thread T0 #0 0x7fc3046e4b76 in memcpy (/lib64/libasan.so.8+0xe4b76) #1 0x00000040df3e in bpf_object__init_prog /src/libbpf/src/libbpf.c:856 #2 0x00000040df3e in bpf_object__add_programs /src/libbpf/src/libbpf.c:928 #3 0x00000040df3e in bpf_object__elf_collect /src/libbpf/src/libbpf.c:3930 #4 0x00000040df3e in bpf_object_open /src/libbpf/src/libbpf.c:8067 #5 0x00000040f176 in bpf_object__open_file /src/libbpf/src/libbpf.c:8090 torvalds#6 0x000000400c16 in main /poc/poc.c:8 torvalds#7 0x7fc3043d25b4 in __libc_start_call_main (/lib64/libc.so.6+0x35b4) torvalds#8 0x7fc3043d2667 in __libc_start_main@@GLIBC_2.34 (/lib64/libc.so.6+0x3667) torvalds#9 0x000000400b34 in _start (/poc/poc+0x400b34) 0x7c7302fe0000 is located 64 bytes before 104-byte region [0x7c7302fe0040,0x7c7302fe00a8) allocated by thread T0 here: #0 0x7fc3046e716b in malloc (/lib64/libasan.so.8+0xe716b) #1 0x7fc3045ee600 in __libelf_set_rawdata_wrlock (/lib64/libelf.so.1+0xb600) #2 0x7fc3045ef018 in __elf_getdata_rdlock (/lib64/libelf.so.1+0xc018) #3 0x00000040642f in elf_sec_data /src/libbpf/src/libbpf.c:3740 The problem here is that currently, libbpf only checks that the program end is within the section bounds. There used to be a check `while (sec_off < sec_sz)` in bpf_object__add_programs, however, it was removed by commit 6245947 ("libbpf: Allow gaps in BPF program sections to support overriden weak functions"). Add a check for detecting the overflow of `sec_off + prog_sz` to bpf_object__init_prog to fix this issue. [1] https://github.com/lmarch2/poc/blob/main/libbpf/libbpf.md Fixes: 6245947 ("libbpf: Allow gaps in BPF program sections to support overriden weak functions") Reported-by: lmarch2 <[email protected]> Signed-off-by: Viktor Malik <[email protected]> Signed-off-by: Andrii Nakryiko <[email protected]> Reviewed-by: Shung-Hsi Yu <[email protected]> Link: https://github.com/lmarch2/poc/blob/main/libbpf/libbpf.md Link: https://lore.kernel.org/bpf/[email protected] Signed-off-by: Sasha Levin <[email protected]>
antheas
pushed a commit
that referenced
this pull request
Jun 23, 2025
commit c98cc97 upstream. Running a modified trace-cmd record --nosplice where it does a mmap of the ring buffer when '--nosplice' is set, caused the following lockdep splat: ====================================================== WARNING: possible circular locking dependency detected 6.15.0-rc7-test-00002-gfb7d03d8a82f torvalds#551 Not tainted ------------------------------------------------------ trace-cmd/1113 is trying to acquire lock: ffff888100062888 (&buffer->mutex){+.+.}-{4:4}, at: ring_buffer_map+0x11c/0xe70 but task is already holding lock: ffff888100a5f9f8 (&cpu_buffer->mapping_lock){+.+.}-{4:4}, at: ring_buffer_map+0xcf/0xe70 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #5 (&cpu_buffer->mapping_lock){+.+.}-{4:4}: __mutex_lock+0x192/0x18c0 ring_buffer_map+0xcf/0xe70 tracing_buffers_mmap+0x1c4/0x3b0 __mmap_region+0xd8d/0x1f70 do_mmap+0x9d7/0x1010 vm_mmap_pgoff+0x20b/0x390 ksys_mmap_pgoff+0x2e9/0x440 do_syscall_64+0x79/0x1c0 entry_SYSCALL_64_after_hwframe+0x76/0x7e -> #4 (&mm->mmap_lock){++++}-{4:4}: __might_fault+0xa5/0x110 _copy_to_user+0x22/0x80 _perf_ioctl+0x61b/0x1b70 perf_ioctl+0x62/0x90 __x64_sys_ioctl+0x134/0x190 do_syscall_64+0x79/0x1c0 entry_SYSCALL_64_after_hwframe+0x76/0x7e -> #3 (&cpuctx_mutex){+.+.}-{4:4}: __mutex_lock+0x192/0x18c0 perf_event_init_cpu+0x325/0x7c0 perf_event_init+0x52a/0x5b0 start_kernel+0x263/0x3e0 x86_64_start_reservations+0x24/0x30 x86_64_start_kernel+0x95/0xa0 common_startup_64+0x13e/0x141 -> #2 (pmus_lock){+.+.}-{4:4}: __mutex_lock+0x192/0x18c0 perf_event_init_cpu+0xb7/0x7c0 cpuhp_invoke_callback+0x2c0/0x1030 __cpuhp_invoke_callback_range+0xbf/0x1f0 _cpu_up+0x2e7/0x690 cpu_up+0x117/0x170 cpuhp_bringup_mask+0xd5/0x120 bringup_nonboot_cpus+0x13d/0x170 smp_init+0x2b/0xf0 kernel_init_freeable+0x441/0x6d0 kernel_init+0x1e/0x160 ret_from_fork+0x34/0x70 ret_from_fork_asm+0x1a/0x30 -> #1 (cpu_hotplug_lock){++++}-{0:0}: cpus_read_lock+0x2a/0xd0 ring_buffer_resize+0x610/0x14e0 __tracing_resize_ring_buffer.part.0+0x42/0x120 tracing_set_tracer+0x7bd/0xa80 tracing_set_trace_write+0x132/0x1e0 vfs_write+0x21c/0xe80 ksys_write+0xf9/0x1c0 do_syscall_64+0x79/0x1c0 entry_SYSCALL_64_after_hwframe+0x76/0x7e -> #0 (&buffer->mutex){+.+.}-{4:4}: __lock_acquire+0x1405/0x2210 lock_acquire+0x174/0x310 __mutex_lock+0x192/0x18c0 ring_buffer_map+0x11c/0xe70 tracing_buffers_mmap+0x1c4/0x3b0 __mmap_region+0xd8d/0x1f70 do_mmap+0x9d7/0x1010 vm_mmap_pgoff+0x20b/0x390 ksys_mmap_pgoff+0x2e9/0x440 do_syscall_64+0x79/0x1c0 entry_SYSCALL_64_after_hwframe+0x76/0x7e other info that might help us debug this: Chain exists of: &buffer->mutex --> &mm->mmap_lock --> &cpu_buffer->mapping_lock Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&cpu_buffer->mapping_lock); lock(&mm->mmap_lock); lock(&cpu_buffer->mapping_lock); lock(&buffer->mutex); *** DEADLOCK *** 2 locks held by trace-cmd/1113: #0: ffff888106b847e0 (&mm->mmap_lock){++++}-{4:4}, at: vm_mmap_pgoff+0x192/0x390 #1: ffff888100a5f9f8 (&cpu_buffer->mapping_lock){+.+.}-{4:4}, at: ring_buffer_map+0xcf/0xe70 stack backtrace: CPU: 5 UID: 0 PID: 1113 Comm: trace-cmd Not tainted 6.15.0-rc7-test-00002-gfb7d03d8a82f torvalds#551 PREEMPT Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 Call Trace: <TASK> dump_stack_lvl+0x6e/0xa0 print_circular_bug.cold+0x178/0x1be check_noncircular+0x146/0x160 __lock_acquire+0x1405/0x2210 lock_acquire+0x174/0x310 ? ring_buffer_map+0x11c/0xe70 ? ring_buffer_map+0x11c/0xe70 ? __mutex_lock+0x169/0x18c0 __mutex_lock+0x192/0x18c0 ? ring_buffer_map+0x11c/0xe70 ? ring_buffer_map+0x11c/0xe70 ? function_trace_call+0x296/0x370 ? __pfx___mutex_lock+0x10/0x10 ? __pfx_function_trace_call+0x10/0x10 ? __pfx___mutex_lock+0x10/0x10 ? _raw_spin_unlock+0x2d/0x50 ? ring_buffer_map+0x11c/0xe70 ? ring_buffer_map+0x11c/0xe70 ? __mutex_lock+0x5/0x18c0 ring_buffer_map+0x11c/0xe70 ? do_raw_spin_lock+0x12d/0x270 ? find_held_lock+0x2b/0x80 ? _raw_spin_unlock+0x2d/0x50 ? rcu_is_watching+0x15/0xb0 ? _raw_spin_unlock+0x2d/0x50 ? trace_preempt_on+0xd0/0x110 tracing_buffers_mmap+0x1c4/0x3b0 __mmap_region+0xd8d/0x1f70 ? ring_buffer_lock_reserve+0x99/0xff0 ? __pfx___mmap_region+0x10/0x10 ? ring_buffer_lock_reserve+0x99/0xff0 ? __pfx_ring_buffer_lock_reserve+0x10/0x10 ? __pfx_ring_buffer_lock_reserve+0x10/0x10 ? bpf_lsm_mmap_addr+0x4/0x10 ? security_mmap_addr+0x46/0xd0 ? lock_is_held_type+0xd9/0x130 do_mmap+0x9d7/0x1010 ? 0xffffffffc0370095 ? __pfx_do_mmap+0x10/0x10 vm_mmap_pgoff+0x20b/0x390 ? __pfx_vm_mmap_pgoff+0x10/0x10 ? 0xffffffffc0370095 ksys_mmap_pgoff+0x2e9/0x440 do_syscall_64+0x79/0x1c0 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7fb0963a7de2 Code: 00 00 00 0f 1f 44 00 00 41 f7 c1 ff 0f 00 00 75 27 55 89 cd 53 48 89 fb 48 85 ff 74 3b 41 89 ea 48 89 df b8 09 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 76 5b 5d c3 0f 1f 00 48 8b 05 e1 9f 0d 00 64 RSP: 002b:00007ffdcc8fb878 EFLAGS: 00000246 ORIG_RAX: 0000000000000009 RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007fb0963a7de2 RDX: 0000000000000001 RSI: 0000000000001000 RDI: 0000000000000000 RBP: 0000000000000001 R08: 0000000000000006 R09: 0000000000000000 R10: 0000000000000001 R11: 0000000000000246 R12: 0000000000000000 R13: 00007ffdcc8fbe68 R14: 00007fb096628000 R15: 00005633e01a5c90 </TASK> The issue is that cpus_read_lock() is taken within buffer->mutex. The memory mapped pages are taken with the mmap_lock held. The buffer->mutex is taken within the cpu_buffer->mapping_lock. There's quite a chain with all these locks, where the deadlock can be fixed by moving the cpus_read_lock() outside the taking of the buffer->mutex. Cc: [email protected] Cc: Masami Hiramatsu <[email protected]> Cc: Mathieu Desnoyers <[email protected]> Cc: Vincent Donnefort <[email protected]> Link: https://lore.kernel.org/[email protected] Fixes: 117c392 ("ring-buffer: Introducing ring-buffer mapping functions") Signed-off-by: Steven Rostedt (Google) <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
|
Unfortunately not, stuck on a stalemate. For the meantime I switched back to Windows as unfortunately I didn't get time to do the instructions (manual kernel build etc) But I appreciate the support anyways! |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The call to hub_hc_release_resources() was incorrectly made before acquiring hcd->address0_mutex. Since the reset_device callback can put the device into the default state, this sequence risks violating the intended serialization. Moving the call ensures proper synchronization.
See: https://bugzilla.kernel.org/show_bug.cgi?id=220069
Especially, Comment torvalds#43, torvalds#48, torvalds#51