summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2026-01-13null_blk: fix kmemleak by releasing references to fault configfs itemsNilay Shroff
When CONFIG_BLK_DEV_NULL_BLK_FAULT_INJECTION is enabled, the null-blk driver sets up fault injection support by creating the timeout_inject, requeue_inject, and init_hctx_fault_inject configfs items as children of the top-level nullbX configfs group. However, when the nullbX device is removed, the references taken to these fault-config configfs items are not released. As a result, kmemleak reports a memory leak, for example: unreferenced object 0xc00000021ff25c40 (size 32): comm "mkdir", pid 10665, jiffies 4322121578 hex dump (first 32 bytes): 69 6e 69 74 5f 68 63 74 78 5f 66 61 75 6c 74 5f init_hctx_fault_ 69 6e 6a 65 63 74 00 88 00 00 00 00 00 00 00 00 inject.......... backtrace (crc 1a018c86): __kmalloc_node_track_caller_noprof+0x494/0xbd8 kvasprintf+0x74/0xf4 config_item_set_name+0xf0/0x104 config_group_init_type_name+0x48/0xfc fault_config_init+0x48/0xf0 0xc0080000180559e4 configfs_mkdir+0x304/0x814 vfs_mkdir+0x49c/0x604 do_mkdirat+0x314/0x3d0 sys_mkdir+0xa0/0xd8 system_call_exception+0x1b0/0x4f0 system_call_vectored_common+0x15c/0x2ec Fix this by explicitly releasing the references to the fault-config configfs items when dropping the reference to the top-level nullbX configfs group. Cc: stable@vger.kernel.org Reviewed-by: Chaitanya Kulkarni <kch@nvidia.com> Fixes: bb4c19e030f4 ("block: null_blk: make fault-injection dynamically configurable per device") Signed-off-by: Nilay Shroff <nilay@linux.ibm.com> Signed-off-by: Jens Axboe <axboe@kernel.dk>
2026-01-13block, nvme: remove unused dma_iova_state function parameterNitesh Shetty
DMA IOVA state is not used inside blk_rq_dma_map_iter_next, get rid of the argument. Signed-off-by: Nitesh Shetty <nj.shetty@samsung.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Jens Axboe <axboe@kernel.dk>
2026-01-13gpio: pca9570: use lock guardsAndy Shevchenko
Shrink the code by a couple lines and improve lock management by using lock guards from cleanup.h. Reviewed-by: Linus Walleij <linusw@kernel.org> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20260113111156.188051-4-andriy.shevchenko@linux.intel.com Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
2026-01-13gpio: pca9570: Don't use "proxy" headersAndy Shevchenko
Update header inclusions to follow IWYU (Include What You Use) principle. Note that kernel.h is discouraged to be included as it's written at the top of that file. Reviewed-by: Linus Walleij <linusw@kernel.org> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20260113111156.188051-3-andriy.shevchenko@linux.intel.com Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
2026-01-13gpio: pca9570: Use devm_mutex_init() for mutex initializationAndy Shevchenko
Use devm_mutex_init() since it brings some benefits when CONFIG_DEBUG_MUTEXES is enabled. Reviewed-by: Linus Walleij <linusw@kernel.org> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20260113111156.188051-2-andriy.shevchenko@linux.intel.com Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
2026-01-13ALSA: usb-audio: Prevent excessive number of framesEdward Adam Davis
In this case, the user constructed the parameters with maxpacksize 40 for rate 22050 / pps 1000, and packsize[0] 22 packsize[1] 23. The buffer size for each data URB is maxpacksize * packets, which in this example is 40 * 6 = 240; When the user performs a write operation to send audio data into the ALSA PCM playback stream, the calculated number of frames is packsize[0] * packets = 264, which exceeds the allocated URB buffer size, triggering the out-of-bounds (OOB) issue reported by syzbot [1]. Added a check for the number of single data URB frames when calculating the number of frames to prevent [1]. [1] BUG: KASAN: slab-out-of-bounds in copy_to_urb+0x261/0x460 sound/usb/pcm.c:1487 Write of size 264 at addr ffff88804337e800 by task syz.0.17/5506 Call Trace: copy_to_urb+0x261/0x460 sound/usb/pcm.c:1487 prepare_playback_urb+0x953/0x13d0 sound/usb/pcm.c:1611 prepare_outbound_urb+0x377/0xc50 sound/usb/endpoint.c:333 Reported-by: syzbot+6db0415d6d5c635f72cb@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=6db0415d6d5c635f72cb Tested-by: syzbot+6db0415d6d5c635f72cb@syzkaller.appspotmail.com Signed-off-by: Edward Adam Davis <eadavis@qq.com> Link: https://patch.msgid.link/tencent_9AECE6CD2C7A826D902D696C289724E8120A@qq.com Signed-off-by: Takashi Iwai <tiwai@suse.de>
2026-01-13PCI: starfive: Use regulator APIs to control the 3v3 power supply of PCIe slotsHal Feng
The driver has been using the "enable-gpios" property to control the 3v3 power supply of PCIe slots. But it is not documented in the dt-bindings and also using GPIO APIs is not a standard way to control PCIe slot power, so use the documented "vpcie3v3-supply" property and regulator APIs to control the slot supply. This change will break the DTs which used "enable-gpio" or "enable-gpios" property under the controller node. Since these properties were not defined in the bindings, it is safe to switch to "vpcie3v3-supply". Any out-of-tree DTS impacted by this change should migrate to "vpcie3v3-supply" instead. Signed-off-by: Hal Feng <hal.feng@starfivetech.com> [mani: reworded description] Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Acked-by: Kevin Xie <kevin.xie@starfivetech.com> Link: https://patch.msgid.link/20251218102149.28062-1-hal.feng@starfivetech.com
2026-01-13Axiado AX3000 SoC SPI DB controller driverMark Brown
Merge series from Vladimir Moravcevic <vmoravcevic@axiado.com>: This series introduces new SPI controller driver for Axiado AX3000 SoC and its evaluation board. The SPI controller provides: - Full-duplex and half-duplex transfer support - Configurable clock polarity and phase - Interrupt-driven Functionality has been verified using the `jedec,spi-nor` interface to access onboard flash memory. This ensures compatibility with common NOR flash devices used in boot and storage subsystem. Further improvements, including performance tuning and extended hardware feature support, will be submitted in follow-up patches.
2026-01-13arm64: dts: rockchip: Add Radxa CM3J on RPi CM4 IO BoardFUKAUMI Naoki
The Raspberry Pi Compute Module 4 IO Board is an application board for the Compute Module 4. [1] This patch adds support for the Radxa CM3J mounted on the RPi CM4 IO Board. Specification: - 12V 5521 DC jack - 2x full-size HDMI 2.0 connectors (only HDMI0 is supported with CM3J) - Gigabit Ethernet RJ45 with PoE support - 2x USB 2.0 connectors, with header for two more connectors - Micro USB connector - microSD card socket - PCIe Gen 2 x1 socket - 12V 4-pin PWM fan connector - External power connector (+5V, +12V) - 2x MIPI DSI connectors - 2x MIPI CSI-2 connectors - 40-pin GPIO header - RTC with battery socket - Red (power) and green (heartbeat) LEDs [1] https://datasheets.raspberrypi.com/cm4io/cm4io-datasheet.pdf Signed-off-by: FUKAUMI Naoki <naoki@radxa.com> Link: https://patch.msgid.link/20260108113341.14037-3-naoki@radxa.com Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2026-01-13arm64: dts: rockchip: Add Radxa CM3JFUKAUMI Naoki
The Radxa CM3J is a feature rich industrial compute module based on the Rockchip RK3568J SoC. [1] Specification: - Quad-core Cortex-A55 CPU - Mali-G52 2EE GPU - 1TOPS NPU - Up to 8GB LPDDR4x RAM - Up to 32GB eMMC (optional) - 16MB SPI flash (optional) - Wi-Fi 5 / BT 5.0 with external antenna connector - Gigabit Ethernet PHY - RK809 PMIC - Green (power) LED [1] https://dl.radxa.com/cm3j/docs/hw/radxa_cm3j_schematic_v1.2_20250115.pdf Signed-off-by: FUKAUMI Naoki <naoki@radxa.com> Link: https://patch.msgid.link/20260108113341.14037-2-naoki@radxa.com Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2026-01-13dt-bindings: arm: rockchip: Add Radxa CM3J on RPi CM4 IO BoardFUKAUMI Naoki
The Radxa CM3J is a feature rich industrial compute module developed by Radxa, based on the Rockchip RK3568 SoC. [1] Add devicetree binding documentation for the Radxa CM3J on RPi CM4 IO Board. [1] https://dl.radxa.com/cm3j/docs/hw/radxa_cm3j_product_brief_Revision_1.0.pdf Signed-off-by: FUKAUMI Naoki <naoki@radxa.com> Acked-by: Rob Herring (Arm) <robh@kernel.org> Link: https://patch.msgid.link/20260108113341.14037-1-naoki@radxa.com Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2026-01-13drm/gud: fix NULL fb and crtc dereferences on USB disconnectShenghao Yang
On disconnect drm_atomic_helper_disable_all() is called which sets both the fb and crtc for a plane to NULL before invoking a commit. This causes a kernel oops on every display disconnect. Add guards for those dereferences. Cc: <stable@vger.kernel.org> # 6.18.x Fixes: 73cfd166e045 ("drm/gud: Replace simple display pipe with DRM atomic helpers") Signed-off-by: Shenghao Yang <me@shenghaoyang.info> Reviewed-by: Ruben Wauters <rubenru09@aol.com> Signed-off-by: Ruben Wauters <rubenru09@aol.com> Link: https://patch.msgid.link/20251231055039.44266-1-me@shenghaoyang.info
2026-01-13x86/pvlocks: Move paravirt spinlock functions into own headerJuergen Gross
Instead of having the pv spinlock function definitions in paravirt.h, move them into the new header paravirt-spinlock.h. Signed-off-by: Juergen Gross <jgross@suse.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Link: https://patch.msgid.link/20260105110520.21356-22-jgross@suse.com
2026-01-13arm64: dts: rockchip: Make eeprom read-only for Radxa ROCK 3C/5A/5CFUKAUMI Naoki
The BL24C16 EEPROM implemented on the Radxa ROCK 3C, 5A, and 5C [1] [2] [3] is designed to have data written during factory programming (regardless of whether data is actually written or not), and we at Radxa permit users to read the data but not write to it. [4] Therefore, we will add a read-only property to the eeprom node. [1] https://dl.radxa.com/rock3/docs/hw/3c/v1400/radxa_rock_3c_v1400_schematic.pdf p.13 [2] https://dl.radxa.com/rock5/5a/docs/hw/radxa_rock5a_V1.1_sch.pdf p.19 [3] https://dl.radxa.com/rock5/5c/docs/hw/v1100/radxa_rock_5c_schematic_v1100.pdf p.18 [4] https://github.com/radxa/u-boot/blob/next-dev-v2024.10/drivers/misc/radxa-i2c-eeprom.c Signed-off-by: FUKAUMI Naoki <naoki@radxa.com> Link: https://patch.msgid.link/20260108034252.2713-1-naoki@radxa.com Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2026-01-13arm64: dts: rockchip: Add TS133 variant of the QNAP NAS seriesHeiko Stuebner
The TS133 is a one-bay NAS mostly similar to the other devices in the series. The main difference is that it is build around the RK3566 SoC instead of the RK3568 variant. The RK3566/RK3568 are mostly similar with only slight variants in both speed and some specific peripherals - the RK3568 has more. The specific for the NAS series stay the same though. Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://patch.msgid.link/20260104191448.2693309-6-heiko@sntech.de
2026-01-13dt-bindings: arm: rockchip: add TS133 to RK356x-based QNAP NAS devicesHeiko Stuebner
QNAP builds a number of variants of the RK356x-based NAS design. Add the 1-bay TS133 variant. This one is a tiny bit special as it is based around the RK3566 variant of the mostly similar RK3566/RK3568 SoCs. Acked-by: Rob Herring (Arm) <robh@kernel.org> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://patch.msgid.link/20260104191448.2693309-5-heiko@sntech.de
2026-01-13arm64: dts: rockchip: Move copy-key to TSx33 board filesHeiko Stuebner
The copy-key is not present on all device variants, so move it to the individual boards that have this key. Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://patch.msgid.link/20260104191448.2693309-4-heiko@sntech.de
2026-01-13arm64: dts: rockchip: Fix the common combophy + SATA on QNAP TSx33 devicesHeiko Stuebner
The common used SATA controller on all TSx33 devices is actually SATA2. So move the SATA controller + combophy enablement to their correct position between shared dtsi and board devicetrees. Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://patch.msgid.link/20260104191448.2693309-3-heiko@sntech.de
2026-01-13arm64: dts: rockchip: Move SoC include to individual QNAP TSx33 boardsHeiko Stuebner
The TS133 while mostly similar, is based around the RK3566 variant, so needs a different SoC include. By moving the SoC include to the board devicetrees, we can still keep the shared common setup, while supporting the different base SoCs. Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://patch.msgid.link/20260104191448.2693309-2-heiko@sntech.de
2026-01-13ALSA: hda/cirrus_scodec_test: Fix test suite nameRichard Fitzgerald
Change the test suite name string to "snd-hda-cirrus-scodec-test". It was incorrectly named "snd-hda-scodec-cs35l56-test", a leftover from when the code under test was actually in the cs35l56 driver. Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com> Fixes: 2144833e7b414 ("ALSA: hda: cirrus_scodec: Add KUnit test") Link: https://patch.msgid.link/20260113134056.619051-1-rf@opensource.cirrus.com Signed-off-by: Takashi Iwai <tiwai@suse.de>
2026-01-13x86/paravirt: Specify pv_ops array in paravirt macrosJuergen Gross
In order to prepare having multiple pv_ops arrays, specify the array in the paravirt macros. Signed-off-by: Juergen Gross <jgross@suse.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Link: https://patch.msgid.link/20260105110520.21356-21-jgross@suse.com
2026-01-13MIPS: vdso: Provide getres_time64() for 32-bit ABIsThomas Weißschuh
For consistency with __vdso_clock_gettime64() there should also be a 64-bit variant of clock_getres(). This will allow the extension of CONFIG_COMPAT_32BIT_TIME to the vDSO and finally the removal of 32-bit time types from the kernel and UAPI. Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de> Signed-off-by: Thomas Gleixner <tglx@kernel.org> Link: https://patch.msgid.link/20251223-vdso-compat-time32-v1-9-97ea7a06a543@linutronix.de
2026-01-13arm64: vdso32: Provide clock_getres_time64()Thomas Weißschuh
For consistency with __vdso_clock_gettime64() there should also be a 64-bit variant of clock_getres(). This will allow the extension of CONFIG_COMPAT_32BIT_TIME to the vDSO and finally the removal of 32-bit time types from the kernel and UAPI. Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de> Signed-off-by: Thomas Gleixner <tglx@kernel.org> Acked-by: Will Deacon <will@kernel.org> Link: https://patch.msgid.link/20251223-vdso-compat-time32-v1-8-97ea7a06a543@linutronix.de
2026-01-13ARM: VDSO: Provide clock_getres_time64()Thomas Weißschuh
For consistency with __vdso_clock_gettime64() there should also be a 64-bit variant of clock_getres(). This will allow the extension of CONFIG_COMPAT_32BIT_TIME to the vDSO and finally the removal of 32-bit time types from the kernel and UAPI. Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de> Signed-off-by: Thomas Gleixner <tglx@kernel.org> Link: https://patch.msgid.link/20251223-vdso-compat-time32-v1-7-97ea7a06a543@linutronix.de
2026-01-13ARM: VDSO: Patch out __vdso_clock_getres() if unavailableThomas Weißschuh
The vDSO code hides symbols which are non-functional. __vdso_clock_getres() was not added to this list when it got introduced. Fixes: 052e76a31b4a ("ARM: 8931/1: Add clock_getres entry point") Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de> Signed-off-by: Thomas Gleixner <tglx@kernel.org> Link: https://patch.msgid.link/20251223-vdso-compat-time32-v1-6-97ea7a06a543@linutronix.de
2026-01-13x86/vdso: Provide clock_getres_time64() for x86-32Thomas Weißschuh
For consistency with __vdso_clock_gettime64() there should also be a 64-bit variant of clock_getres(). This will allow the extension of CONFIG_COMPAT_32BIT_TIME to the vDSO and finally the removal of 32-bit time types from the kernel and UAPI. Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de> Signed-off-by: Thomas Gleixner <tglx@kernel.org> Link: https://patch.msgid.link/20251223-vdso-compat-time32-v1-5-97ea7a06a543@linutronix.de
2026-01-13selftests: vDSO: vdso_test_abi: Add test for clock_getres_time64()Thomas Weißschuh
Some architectures will start to implement this function. Make sure it works correctly. Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de> Signed-off-by: Thomas Gleixner <tglx@kernel.org> Link: https://patch.msgid.link/20251223-vdso-compat-time32-v1-4-97ea7a06a543@linutronix.de
2026-01-13selftests: vDSO: vdso_test_abi: Use UAPI system call numbersThomas Weißschuh
SYS_clock_getres might have been redirected by libc to some other system call than the actual clock_getres. For testing it is required to use exactly this system call. Use the system call number exported by the UAPI headers which is always correct. Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de> Signed-off-by: Thomas Gleixner <tglx@kernel.org> Link: https://patch.msgid.link/20251223-vdso-compat-time32-v1-3-97ea7a06a543@linutronix.de
2026-01-13selftests: vDSO: vdso_config: Add configurations for clock_getres_time64()Thomas Weißschuh
Some architectures will start to implement this function. Make sure that tests can be written for it. Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de> Signed-off-by: Thomas Gleixner <tglx@kernel.org> Link: https://patch.msgid.link/20251223-vdso-compat-time32-v1-2-97ea7a06a543@linutronix.de
2026-01-13vdso: Add prototype for __vdso_clock_getres_time64()Thomas Weißschuh
For consistency with __vdso_clock_gettime64() there should also be a 64-bit variant of clock_getres(). This will allow the extension of CONFIG_COMPAT_32BIT_TIME to the vDSO and finally the removal of 32-bit time types from the kernel and UAPI. The generic vDSO library already provides nearly all necessary building blocks for architectures to provide this function. Only a prototype is missing. Add the prototype to the generic header so architectures can start providing this function. Suggested-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de> Signed-off-by: Thomas Gleixner <tglx@kernel.org> Link: https://patch.msgid.link/20251223-vdso-compat-time32-v1-1-97ea7a06a543@linutronix.de
2026-01-13dt-bindings: PCI: loongson: Document msi-parent propertyYao Zi
Loongson PCI controllers found in LS2K1000/2000 SoCs (loongson,ls2k-pci), 7A1000/2000 bridge chips (loongson,ls7a-pci), and RS780E bridge chips (loongson,rs780e-pci) all have their paired MSI controllers. Though only the one in LS2K2000 SoC is described in devicetree, we should document the property for all variants. For the same reason, it isn't marked as required for now. Fixes: 83e757ecfd5d ("dt-bindings: Document Loongson PCI Host Controller") Signed-off-by: Yao Zi <me@ziyao.cc> Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Acked-by: Rob Herring (Arm) <robh@kernel.org> Link: https://patch.msgid.link/20251209140006.54821-3-me@ziyao.cc
2026-01-13RDMA/irdma: Remove fixed 1 ms delay during AH wait loopJacob Moroni
The AH CQP command wait loop executes in an atomic context and was using a fixed 1 ms delay. Since many AH create commands can complete much faster than 1 ms, use poll_timeout_us_atomic with a 1 us delay. Also, use the timeout value indicated during the capability exchange rather than a hard-coded value. Signed-off-by: Jacob Moroni <jmoroni@google.com> Link: https://patch.msgid.link/20260105180550.2907858-1-jmoroni@google.com Signed-off-by: Leon Romanovsky <leon@kernel.org>
2026-01-13ALSA: hda/cirrus_scodec_test: Fix incorrect setup of gpiochipRichard Fitzgerald
Set gpiochip parent to the struct device of the dummy GPIO driver so that the software node will be associated with the GPIO chip. The recent commit e5d527be7e698 ("gpio: swnode: don't use the swnode's name as the key for GPIO lookup") broke cirrus_scodec_test, because the software node no longer gets associated with the GPIO driver by name. Instead, setting struct gpio_chip.parent to the owning struct device will find the node using a normal fwnode lookup. Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com> Fixes: 2144833e7b414 ("ALSA: hda: cirrus_scodec: Add KUnit test") Link: https://patch.msgid.link/20260113130954.574670-1-rf@opensource.cirrus.com Signed-off-by: Takashi Iwai <tiwai@suse.de>
2026-01-13USB: serial: ftdi_sio: add support for PICAXE AXE027 cableEthan Nelson-Moore
The vendor provides instructions to write "0403 bd90" to /sys/bus/usb-serial/drivers/ftdi_sio/new_id; see: https://picaxe.com/docs/picaxe_linux_instructions.pdf Cc: stable@vger.kernel.org Signed-off-by: Ethan Nelson-Moore <enelsonmoore@gmail.com> Signed-off-by: Johan Hovold <johan@kernel.org>
2026-01-13RDMA/irdma: Remove redundant dma_wmb() before writel()Jacob Moroni
A dma_wmb() is not necessary before a writel() because writel() already has an even stronger store barrier. A dma_wmb() is only required to order writes to consistent/DMA memory whereas the barrier in writel() is specified to order writes to DMA memory as well as MMIO. Signed-off-by: Jacob Moroni <jmoroni@google.com> Link: https://patch.msgid.link/20260103172517.2088895-1-jmoroni@google.com Signed-off-by: Leon Romanovsky <leon@kernel.org>
2026-01-13RDMA/rtrs-srv: Fix error print in process_info_req()Grzegorz Prajsner
rtrs_srv_change_state() returns bool (true on success) therefore there is no reason to print error when it fails as it always will be 0. Signed-off-by: Grzegorz Prajsner <grzegorz.prajsner@ionos.com> Signed-off-by: Md Haris Iqbal <haris.iqbal@ionos.com> Link: https://patch.msgid.link/20260107161517.56357-11-haris.iqbal@ionos.com Signed-off-by: Leon Romanovsky <leon@kernel.org>
2026-01-13RDMA/rtrs-clt: For conn rejection use actual err numberMd Haris Iqbal
When the connection establishment request is rejected from the server side, then the actual error number sent back should be used. Signed-off-by: Md Haris Iqbal <haris.iqbal@ionos.com> Link: https://patch.msgid.link/20260107161517.56357-10-haris.iqbal@ionos.com Reviewed-by: Grzegorz Prajsner <grzegorz.prajsner@ionos.com> Reviewed-by: Jack Wang <jinpu.wang@ionos.com> Signed-off-by: Leon Romanovsky <leon@kernel.org>
2026-01-13RDMA/rtrs: Extend log message when a port failsKim Zhu
Add HCA name and port of this HCA. This would help with analysing and debugging the logs. The logs would looks something like this, rtrs_server L2516: Handling event: port error (10). HCA name: mlx4_0, port num: 2 rtrs_client L3326: Handling event: port error (10). HCA name: mlx4_0, port num: 1 Signed-off-by: Kim Zhu <zhu.yanjun@ionos.com> Signed-off-by: Md Haris Iqbal <haris.iqbal@ionos.com> Signed-off-by: Grzegorz Prajsner <grzegorz.prajsner@ionos.com> Link: https://patch.msgid.link/20260107161517.56357-9-haris.iqbal@ionos.com Signed-off-by: Leon Romanovsky <leon@kernel.org>
2026-01-13RDMA/rtrs-srv: Rate-limit I/O path error loggingKim Zhu
Excessive error logging is making it difficult to identify the root cause of issues. Implement rate limiting to improve log clarity. Signed-off-by: Kim Zhu <zhu.yanjun@ionos.com> Signed-off-by: Jack Wang <jinpu.wang@ionos.com> Signed-off-by: Grzegorz Prajsner <grzegorz.prajsner@ionos.com> Link: https://patch.msgid.link/20260107161517.56357-8-haris.iqbal@ionos.com Signed-off-by: Leon Romanovsky <leon@kernel.org>
2026-01-13RDMA/rtrs-srv: Add check and closure for possible zombie pathsMd Haris Iqbal
During several network incidents, a number of RTRS paths for a session went through disconnect and reconnect phase. However, some of those did not auto-reconnect successfully. Instead they failed with the following logs, On client, kernel: rtrs_client L1991: <sess-name>: Connect rejected: status 28 (consumer defined), rtrs errno -104 kernel: rtrs_client L2698: <sess-name>: init_conns() failed: err=-104 path=gid:<gid1>@gid:<gid2> [mlx4_0:1] On server, (log a) kernel: ibtrs_server L1868: <>: Connection already exists: 0 When the misbehaving path was removed, and add_path was called to re-add the path, the log on client side changed to, (log b) kernel: rtrs_client L1991: <sess-name>: Connect rejected: status 28 (consumer defined), rtrs errno -17 There was no log on the server side for this, which is expected since there is no logging in that path, if (unlikely(__is_path_w_addr_exists(srv, &cm_id->route.addr))) { err = -EEXIST; goto err; Because of the following check on server side, if (unlikely(sess->state != IBTRS_SRV_CONNECTING)) { ibtrs_err(s, "Session in wrong state: %s\n", .. we know that the path in (log a) was in CONNECTING state. The above state of the path persists for as long as we leave the session be. This means that the path is in some zombie state, probably waiting for the info_req packet to arrive, which never does. The changes in this commits does 2 things. 1) Add logs at places where we see the errors happening. The logs would shed more light at the state and lifetime of such zombie paths. 2) Close such zombie sessions, only if they are in CONNECTING state, and after an inactivity period of 30 seconds. i) The state check prevents closure of paths which are CONNECTED. Also, from the above logs and code, we already know that the path could only be on CONNECTING state, so we play safe and narrow our impact surface area by closing only CONNECTING paths. ii) The inactivity period is to allow requests for other cid to finish processing, or for any stray packets to arrive/fail. Signed-off-by: Md Haris Iqbal <haris.iqbal@ionos.com> Signed-off-by: Jack Wang <jinpu.wang@ionos.com> Signed-off-by: Grzegorz Prajsner <grzegorz.prajsner@ionos.com> Link: https://patch.msgid.link/20260107161517.56357-7-haris.iqbal@ionos.com Signed-off-by: Leon Romanovsky <leon@kernel.org>
2026-01-13RDMA/rtrs-clt: Remove unused members in rtrs_clt_io_reqJack Wang
Remove unused members from rtrs_clt_io_req. Signed-off-by: Jack Wang <jinpu.wang@ionos.com> Signed-off-by: Grzegorz Prajsner <grzegorz.prajsner@ionos.com> Link: https://patch.msgid.link/20260107161517.56357-6-haris.iqbal@ionos.com Signed-off-by: Leon Romanovsky <leon@kernel.org>
2026-01-13RDMA/rtrs: Improve error logging for RDMA cm eventsKim Zhu
The member variable status in the struct rdma_cm_event is used for both linux errors and the errors definded in rdma stack. Signed-off-by: Kim Zhu <zhu.yanjun@ionos.com> Reviewed-by: Md Haris Iqbal <haris.iqbal@ionos.com> Signed-off-by: Grzegorz Prajsner <grzegorz.prajsner@ionos.com> Link: https://patch.msgid.link/20260107161517.56357-5-haris.iqbal@ionos.com Signed-off-by: Leon Romanovsky <leon@kernel.org>
2026-01-13RDMA/rtrs: Add optional support for IB_MR_TYPE_SG_GAPSMd Haris Iqbal
Support IB_MR_TYPE_SG_GAPS, which has less limitations than standard IB_MR_TYPE_MEM_REG, a few ULP support this. Signed-off-by: Md Haris Iqbal <haris.iqbal@ionos.com> Signed-off-by: Kim Zhu <zhu.yanjun@ionos.com> Signed-off-by: Jack Wang <jinpu.wang@ionos.com> Signed-off-by: Grzegorz Prajsner <grzegorz.prajsner@ionos.com> Link: https://patch.msgid.link/20260107161517.56357-4-haris.iqbal@ionos.com Signed-off-by: Leon Romanovsky <leon@kernel.org>
2026-01-13RDMA/rtrs: Add error description to the logsKim Zhu
Print error description instead of the error number. Signed-off-by: Kim Zhu <zhu.yanjun@ionos.com> Signed-off-by: Jack Wang <jinpu.wang@ionos.com> Signed-off-by: Grzegorz Prajsner <grzegorz.prajsner@ionos.com> Link: https://patch.msgid.link/20260107161517.56357-3-haris.iqbal@ionos.com Signed-off-by: Leon Romanovsky <leon@kernel.org>
2026-01-13RDMA/rtrs-srv: fix SG mappingRoman Penyaev
This fixes the following error on the server side: RTRS server session allocation failed: -EINVAL caused by the caller of the `ib_dma_map_sg()`, which does not expect less mapped entries, than requested, which is in the order of things and can be easily reproduced on the machine with enabled IOMMU. The fix is to treat any positive number of mapped sg entries as a successful mapping and cache DMA addresses by traversing modified SG table. Fixes: 9cb837480424 ("RDMA/rtrs: server: main functionality") Signed-off-by: Roman Penyaev <r.peniaev@gmail.com> Signed-off-by: Jack Wang <jinpu.wang@ionos.com> Signed-off-by: Grzegorz Prajsner <grzegorz.prajsner@ionos.com> Link: https://patch.msgid.link/20260107161517.56357-2-haris.iqbal@ionos.com Signed-off-by: Leon Romanovsky <leon@kernel.org>
2026-01-13ata: libata: Print features also for ATAPI devicesNiklas Cassel
Commit d633b8a702ab ("libata: print feature list on device scan") added a print of the features supported by the device for ATA_DEV_ATA and ATA_DEV_ZAC devices, but not for ATA_DEV_ATAPI devices. Fix this by printing the features also for ATAPI devices. Before changes: ata1.00: ATAPI: Slimtype DVD A DU8AESH, 6C2M, max UDMA/133 After changes: ata1.00: ATAPI: Slimtype DVD A DU8AESH, 6C2M, max UDMA/133 ata1.00: Features: Dev-Attention HIPM DIPM Fixes: d633b8a702ab ("libata: print feature list on device scan") Signed-off-by: Niklas Cassel <cassel@kernel.org> Tested-by: Wolf <wolf@yoxt.cc> Signed-off-by: Damien Le Moal <dlemoal@kernel.org>
2026-01-13ata: libata: Add DIPM and HIPM to ata_dev_print_features() early returnNiklas Cassel
ata_dev_print_features() is supposed to return early and not print anything if there are no features supported. However, commit b1f5af54f1f5 ("ata: libata-core: Advertize device support for DIPM and HIPM features") added additional features to ata_dev_print_features() without updating the early return conditional. Add the missing features to the early return conditional. Fixes: b1f5af54f1f5 ("ata: libata-core: Advertize device support for DIPM and HIPM features") Signed-off-by: Niklas Cassel <cassel@kernel.org> Tested-by: Wolf <wolf@yoxt.cc> Signed-off-by: Damien Le Moal <dlemoal@kernel.org>
2026-01-13ata: libata: Add cpr_log to ata_dev_print_features() early returnNiklas Cassel
ata_dev_print_features() is supposed to return early and not print anything if there are no features supported. However, commit fe22e1c2f705 ("libata: support concurrent positioning ranges log") added another feature to ata_dev_print_features() without updating the early return conditional. Add the missing feature to the early return conditional. Fixes: fe22e1c2f705 ("libata: support concurrent positioning ranges log") Signed-off-by: Niklas Cassel <cassel@kernel.org> Tested-by: Wolf <wolf@yoxt.cc> Signed-off-by: Damien Le Moal <dlemoal@kernel.org>
2026-01-13ata: libata-sata: Improve link_power_management_supported sysfs attributeNiklas Cassel
The link_power_management_supported sysfs attribute is currently set as true even for ata ports that lack a .set_lpm() callback, e.g. dummy ports. This is a bit silly, because while writing to the link_power_management_policy sysfs attribute will make ata_scsi_lpm_store() update ap->target_lpm_policy (thus sysfs will reflect the new value) and call ata_port_schedule_eh() for the port, it is essentially a no-op. This is because for a port without a .set_lpm() callback, once EH gets to run, the ata_eh_link_set_lpm() will simply return, since the port does not provide a .set_lpm() callback. Thus, make sure that the link_power_management_supported sysfs attribute is set to false for ports that lack a .set_lpm() callback. This way the link_power_management_policy sysfs attribute will no longer be writable, so we will no longer be misleading users to think that their sysfs write actually does something. Fixes: 0060beec0bfa ("ata: libata-sata: Add link_power_management_supported sysfs attribute") Signed-off-by: Niklas Cassel <cassel@kernel.org> Tested-by: Wolf <wolf@yoxt.cc> Signed-off-by: Damien Le Moal <dlemoal@kernel.org>
2026-01-13ata: libata: Call ata_dev_config_lpm() for ATAPI devicesNiklas Cassel
Commit d360121832d8 ("ata: libata-core: Introduce ata_dev_config_lpm()") introduced ata_dev_config_lpm(). However, it only called this function for ATA_DEV_ATA and ATA_DEV_ZAC devices, not for ATA_DEV_ATAPI devices. Additionally, commit d99a9142e782 ("ata: libata-core: Move device LPM quirk settings to ata_dev_config_lpm()") moved the LPM quirk application from ata_dev_configure() to ata_dev_config_lpm(), causing LPM quirks for ATAPI devices to no longer be applied. Call ata_dev_config_lpm() also for ATAPI devices, such that LPM quirks are applied for ATAPI devices with an entry in __ata_dev_quirks once again. Fixes: d360121832d8 ("ata: libata-core: Introduce ata_dev_config_lpm()") Fixes: d99a9142e782 ("ata: libata-core: Move device LPM quirk settings to ata_dev_config_lpm()") Signed-off-by: Niklas Cassel <cassel@kernel.org> Tested-by: Wolf <wolf@yoxt.cc> Signed-off-by: Damien Le Moal <dlemoal@kernel.org>
generated by cgit v1.2.3 (git 2.25.1) at 2026-02-14 18:59:19 +0000