summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2025-03-19sched/debug: Make CONFIG_SCHED_DEBUG functionality unconditionalIngo Molnar
All the big Linux distros enable CONFIG_SCHED_DEBUG, because the various features it provides help not just with kernel development, but with system administration and user-space software development as well. Reflect this reality and enable this functionality unconditionally. Signed-off-by: Ingo Molnar <mingo@kernel.org> Tested-by: Shrikanth Hegde <sshegde@linux.ibm.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Juri Lelli <juri.lelli@redhat.com> Cc: Vincent Guittot <vincent.guittot@linaro.org> Cc: Dietmar Eggemann <dietmar.eggemann@arm.com> Cc: Steven Rostedt <rostedt@goodmis.org> Cc: Ben Segall <bsegall@google.com> Cc: Mel Gorman <mgorman@suse.de> Cc: Valentin Schneider <vschneid@redhat.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Link: https://lore.kernel.org/r/20250317104257.3496611-4-mingo@kernel.org
2025-03-19sched/debug: Make 'const_debug' tunables unconditional __read_mostlyIngo Molnar
With CONFIG_SCHED_DEBUG becoming unconditional, remove the extra 'const_debug' indirection towards __read_mostly. Signed-off-by: Ingo Molnar <mingo@kernel.org> Tested-by: Shrikanth Hegde <sshegde@linux.ibm.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Juri Lelli <juri.lelli@redhat.com> Cc: Vincent Guittot <vincent.guittot@linaro.org> Cc: Dietmar Eggemann <dietmar.eggemann@arm.com> Cc: Steven Rostedt <rostedt@goodmis.org> Cc: Ben Segall <bsegall@google.com> Cc: Mel Gorman <mgorman@suse.de> Cc: Valentin Schneider <vschneid@redhat.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Link: https://lore.kernel.org/r/20250317104257.3496611-3-mingo@kernel.org
2025-03-19sched/debug: Change SCHED_WARN_ON() to WARN_ON_ONCE()Ingo Molnar
The scheduler has this special SCHED_WARN() facility that depends on CONFIG_SCHED_DEBUG. Since CONFIG_SCHED_DEBUG is getting removed, convert SCHED_WARN() to WARN_ON_ONCE(). Note that the warning output isn't 100% equivalent: #define SCHED_WARN_ON(x) WARN_ONCE(x, #x) Because SCHED_WARN_ON() would output the 'x' condition as well, while WARN_ONCE() will only show a backtrace. Hopefully these are rare enough to not really matter. If it does, we should probably introduce a new WARN_ON() variant that outputs the condition in stringified form, or improve WARN_ON() itself. Signed-off-by: Ingo Molnar <mingo@kernel.org> Tested-by: Shrikanth Hegde <sshegde@linux.ibm.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Juri Lelli <juri.lelli@redhat.com> Cc: Vincent Guittot <vincent.guittot@linaro.org> Cc: Dietmar Eggemann <dietmar.eggemann@arm.com> Cc: Steven Rostedt <rostedt@goodmis.org> Cc: Ben Segall <bsegall@google.com> Cc: Mel Gorman <mgorman@suse.de> Cc: Valentin Schneider <vschneid@redhat.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Link: https://lore.kernel.org/r/20250317104257.3496611-2-mingo@kernel.org
2025-03-19Merge tag 'hisi-arm64-dt-for-6.15' of ↵Arnd Bergmann
https://github.com/hisilicon/linux-hisi into soc/dt ARM64: DT: HiSilicon ARM64 DT updates for v6.15 - Add property to the ETM nodes for fixing CPU idle states * tag 'hisi-arm64-dt-for-6.15' of https://github.com/hisilicon/linux-hisi: arm64: dts: hi3660: Add property for fixing CPUIdle Link: https://lore.kernel.org/r/67D968A9.7080504@hisilicon.com Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2025-03-19Merge tag 'riscv-dt-for-v6.15' of ↵Arnd Bergmann
https://git.kernel.org/pub/scm/linux/kernel/git/conor/linux into soc/dt RISC-V Devicetrees for v6.15 Starfive: All changes for jh7110-based boards including the removal of a dac that does not exist and the addition of usb3 support on the star64 board and pcie on the framework mainboard. Microchip: Update pcie reg properties to fix a mistake originally describing them. Here rather than in fixes, since the driver maintains support for the old format. Signed-off-by: Conor Dooley <conor.dooley@microchip.com> * tag 'riscv-dt-for-v6.15' of https://git.kernel.org/pub/scm/linux/kernel/git/conor/linux: riscv: dts: starfive: jh7110-pine64-star64: enable USB 3.0 port riscv: dts: starfive: jh7110: pciephy0 USB 3.0 configuration registers riscv: dts: starfive: fml13v01: enable pcie1 riscv: dts: starfive: remove non-existent dac from jh7110 riscv: dts: starfive: Unify regulator naming scheme riscv: dts: microchip: update pcie reg properties to new format Link: https://lore.kernel.org/r/20250318-favorite-presuming-bf2fcf55bf6a@spud Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2025-03-19Merge tag 'omap-for-v6.15/dt-signed' of ↵Arnd Bergmann
https://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap into soc/dt ARM: dts: misc. OMAP updates for v6.15 * tag 'omap-for-v6.15/dt-signed' of https://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap: ARM: dts: omap4-panda-a4: Add missing model and compatible properties dt-bindings: omap: Add TI Pandaboard A4 variant ARM: dts: ti/omap: omap4-serial: fix interrupts syntax ARM: dts: ti: omap: Align GPIO hog name with bindings Link: https://lore.kernel.org/r/7hiko7qzud.fsf@baylibre.com Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2025-03-19x86/mm: Only do broadcast flush from reclaim if pages were unmappedRik van Riel
Track whether pages were unmapped from any MM (even ones with a currently empty mm_cpumask) by the reclaim code, to figure out whether or not broadcast TLB flush should be done when reclaim finishes. The reason any MM must be tracked, and not only ones contributing to the tlbbatch cpumask, is that broadcast ASIDs are expected to be kept up to date even on CPUs where the MM is not currently active. This change allows reclaim to avoid doing TLB flushes when only clean page cache pages and/or slab memory were reclaimed, which is fairly common. ( This is a simpler alternative to the code that was in my INVLPGB series before, and it seems to capture most of the benefit due to how common it is to reclaim only page cache. ) Signed-off-by: Rik van Riel <riel@surriel.com> Signed-off-by: Ingo Molnar <mingo@kernel.org> Cc: Dave Hansen <dave.hansen@linux.intel.com> Cc: Andy Lutomirski <luto@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Link: https://lore.kernel.org/r/20250319132520.6b10ad90@fangorn
2025-03-19block/blk-iocost: ensure 'ret' is set on errorJens Axboe
In case blkg_conf_open_bdev_frozen() fails, ioc_qos_write() jumps to the error path without assigning a value to 'ret'. Ensure that it inherits the error from the passed back error value. Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202503200454.QWpwKeJu-lkp@intel.com/ Fixes: 9730763f4756 ("block: correct locking order for protecting blk-wbt parameters") Signed-off-by: Jens Axboe <axboe@kernel.dk>
2025-03-19Merge tag 'riscv-sophgo-dt-for-v6.15' of https://github.com/sophgo/linux ↵Arnd Bergmann
into soc/dt RISC-V Devicetrees for v6.15 Sophgo: Add pwm controller support for SG2042. Add pwm-fan & cooling maps for Milk-V Pioneer. Updated MAINTAINERS info for SOPHGO DEVICETREES and DRIVERS. Signed-off-by: Chen Wang <unicorn_wang@outlook.com> * tag 'riscv-sophgo-dt-for-v6.15' of https://github.com/sophgo/linux: riscv: sophgo: dts: add cooling maps for Milk-V Pioneer riscv: sophgo: dts: add pwm-fan for Milk-V Pioneer MAINTAINERS: update info for SOPHGO DEVICETREES and DRIVERS riscv: sophgo: dts: add pwm controller for SG2042 SoC Link: https://lore.kernel.org/r/PN0PR01MB10393CEC71B623E0A779E7393FEDF2@PN0PR01MB10393.INDPRD01.PROD.OUTLOOK.COM Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2025-03-19Merge tag 'mvebu-dt64-6.15-1' of ↵Arnd Bergmann
https://git.kernel.org/pub/scm/linux/kernel/git/gclement/mvebu into soc/dt mvebu dt64 for 6.15 (part 1) device tree clean-up fomr DT maintainers * tag 'mvebu-dt64-6.15-1' of https://git.kernel.org/pub/scm/linux/kernel/git/gclement/mvebu: arm64: dts: marvell: Use preferred node names for "simple-bus" arm64: dts: marvell: Drop unused CP11X_TYPE define arm64: dts: marvell: Move arch timer and pmu nodes to top-level ARM: dts: marvell: armada: Align GPIO hog name with bindings ARM: dts: marvell: kirkwood-openrd: Align GPIO hog name with bindings arm64: dts: marvell: armada-8040: Align GPIO hog name with bindings arm64: dts: marvell: Add missing board compatible for IEI-Puzzle-M801 arm64: dts: marvell: Fix missing/incorrect "marvell,armada3710" compatible arm64: dts: marvell: Drop incomplete root compatible/model properties dt-bindings: marvell: armada-7k-8k: Add missing 7040 and 8040 board compatibles dt-bindings: marvell: armada-7k-8k: Move Armada 8KPlus to schema dt-bindings: marvell: armada-37xx: Add glinet,gl-mv1000 compatible Link: https://lore.kernel.org/r/87wmco99xv.fsf@BLaptop.bootlin.com Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2025-03-19Merge tag 'v6.15-rockchip-dts64-2' of ↵Arnd Bergmann
https://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip into soc/dt New peripheral the sdhci controller on rk3528. Enablement of hdmi and hdmi audio on a number of additional boards. Better handling for scmi shared memory on rk3568 and a fix for the used SCMI clock ids on rk3576. As well as some fixes that were a bit late for trying to stuff them into 6.14 at this late stage of the cycle. * tag 'v6.15-rockchip-dts64-2' of https://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip: arm64: dts: rockchip: remove ethm0_clk0_25m_out from Sige5 gmac0 arm64: dts: rockchip: Fix PWM pinctrl names arm64: dts: rockchip: fix RK3576 SCMI clock IDs dt-bindings: clock: rk3576: add SCMI clocks arm64: dts: rockchip: Fix pcie reset gpio on Orange Pi 5 Max arm64: dts: rockchip: Enable HDMI audio output for ArmSoM Sige7 arm64: dts: rockchip: Enable onboard eMMC on Radxa E20C arm64: dts: rockchip: Add SDHCI controller for RK3528 arm64: dts: rockchip: Remove bluetooth node from rock-3a arm64: dts: rockchip: Move rk356x scmi SHMEM to reserved memory arm64: dts: rockchip: Add AP6275P wireless support to ArmSoM Sige7 arm64: dts: rockchip: Enable HDMI audio outputs for Orange Pi 5 Plus arm64: dts: rockchip: Enable HDMI1 on Orange Pi 5 Plus arm64: dts: rockchip: Enable HDMI audio outputs for Orange Pi 5 Max arm64: dts: rockchip: Enable HDMI0 audio output for Orange Pi 5/5B Link: https://lore.kernel.org/r/23866869.6Emhk5qWAg@phil Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2025-03-19Merge tag 'zynq-dt-for-6.15' of https://github.com/Xilinx/linux-xlnx into soc/dtArnd Bergmann
arm64: Zynq DT changes for 6.15 - Align platforms with dt-schema - Describe QSPI * tag 'zynq-dt-for-6.15' of https://github.com/Xilinx/linux-xlnx: ARM: zynq: Do not define address/size-cells for nand-controller ARM: zynq: Remove ethernet0 alias from Microzed ARM: zynq: Add sdhci to alias node ARM: zynq: Enable QSPIs on platforms ARM: zynq: Fix fpga region DT nodes name ARM: zynq: Rename i2c?-gpio to i2c?-gpio-grp ARM: zynq: Define rtc alias on zc702/zc706 ARM: zynq: Point via nvmem0 alias to eeprom on zc702/zc706 ARM: zynq: Define u-boot bootscrip addr via DT ARM: zynq: Wire smcc with nand/nor memories on zc770 platform ARM: zynq: Mark boot-phase-specific device nodes ARM: zynq: DT: List OCM memory for all platforms ARM: zynq: Remove deprecated device_type property ARM: zynq: Replace 'io-standard' with 'power-source' property Link: https://lore.kernel.org/r/CAHTX3d+DZo3thrakBf=QCq91QFeChoizuhVa6oBBj9E+sdEXAQ@mail.gmail.com Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2025-03-19Merge tag 'zynqmp-dt-for-6.14' of https://github.com/Xilinx/linux-xlnx into ↵Arnd Bergmann
soc/dt arm64: ZynqMP DT changes for 6.15 - Align clock nodes with DT binding - Add the first VN-X Versal NET board - Move constants out of DT bindings * tag 'zynqmp-dt-for-6.14' of https://github.com/Xilinx/linux-xlnx: dt-bindings: xilinx: Deprecate header with firmware constants arm64: zynqmp: Use DT header for firmware constants arm64: versal-net: Add description for b2197-00 revA board dt-bindings: soc: Add new VN-X board description based on Versal NET arm64: zynqmp: add clock-output-names property in clock nodes Link: https://lore.kernel.org/r/CAHTX3d+u1VmxP4vm0peQS-ST7o0BuCpKUPRVCSLMfAAb=eV3Xg@mail.gmail.com Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2025-03-19Merge tag 'sunxi-dt-for-6.15' of ↵Arnd Bergmann
https://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux into soc/dt Allwinner device tree changes for 6.15 - New board support: NetCube Systems Kumquat - Enable USB and LED on Anbernic RG35XX - Fix reboot GPIO detection logic on Anbernic RG35XX - Disable (non-existent) battery thermistor on Anbernic RG35XX - Add CPU OPP table for A100 * tag 'sunxi-dt-for-6.15' of https://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux: arm64: dts: allwinner: a100: Add CPU Operating Performance Points table arm64: dts: allwinner: rg35xx: Add no-thermistor property for battery arm64: dts: allwinner: h700: Add USB Host for RG35XX-H arm64: dts: allwinner: h700: Add LED1 for Anbernic RG35XX arm64: dts: allwinner: h700: Set cpusldo to always-on for RG35XX ARM: dts: sunxi: add support for NetCube Systems Kumquat ARM: dts: sunxi: add uart1_pe pinctrl for sun8i-v3s dt-bindings: arm: sunxi: Add NetCube Systems Kumquat board dt-bindings: vendor-prefixes: Add NetCube Systems Austria name Link: https://lore.kernel.org/r/Z9LTOHJDY2p0lNG0@wens.tw Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2025-03-19Merge tag 'at91-dt-6.15' of ↵Arnd Bergmann
https://git.kernel.org/pub/scm/linux/kernel/git/at91/linux into soc/dt Microchip AT91 device tree updates for v6.15 This update includes: - more controllers enabled for SAMA7D65 SoC (DMA, reset controller, shutdown controller, RTC, watchdog) - power monitor device enabled for SAMA7D65 Curiosity board - device tree cleanups * tag 'at91-dt-6.15' of https://git.kernel.org/pub/scm/linux/kernel/git/at91/linux: ARM: dts: microchip: sama7g5: add ADC hw trigger edge type ARM: dts: microchip: sama7d65: Add watchdog for sama7d65 ARM: dts: microchip: sama7d65: Enable shutdown controller ARM: dts: microchip: sama7d65: Add SFRBU support to sama7d65 ARM: dts: microchip: sama7d65: Add RTC support for sama7d65 ARM: dts: microchip: sama7d65: Add Shutdown controller support ARM: dts: microchip: sama7d65: Add Reset Controller to sama7d65 SoC ARM: dts: microchip: fix faulty ohci/ehci node names ARM: dts: microchip: usb_a9263: fix wrong vendor ARM: dts: microchip: sama7d65: Enable DMAs ARM: dts: microchip: sama7d65: Add DMAs to sama7d65 SoC ARM: dts: microchip: sama7d65: Add chipID for sama7d65 ARM: dts: microchip: sama7d65_curiosity: Add power monitor support ARM: dts: microchip: sama7d65: Add flexcom 10 node ARM: dts: at91: usb_a9g20_lpw: use proper mmc node name ARM: dts: at91: calao_usb: fix button nodes ARM: dts: at91: use correct vendor name for Calao boards ARM: dts: at91: calao_usb: remove heartbeat for User LEDs ARM: dts: at91: calao_usb: fix wrong polarity for LED Link: https://lore.kernel.org/r/20250312173755.975074-1-claudiu.beznea@tuxon.dev Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2025-03-19Merge tag 'stm32-dt-for-v6.15-1' of ↵Arnd Bergmann
https://git.kernel.org/pub/scm/linux/kernel/git/atorgue/stm32 into soc/dt STM32 DT for v6.15, round 1 Highlights: ---------- - MPU: - STM32MP13: - Add thermal support. - Add Priva E-Measuringbox board support based on sTM32MP133C SoC. It embeds Ethernet RMII with TI phy, SDCard, eMMC and some sensors. - Add support for DHCOR SoM and DHSBC rev.200 board: TPM interrupts and gpio reset + LDO2/LDO5 support. - STMP32MP15: - Add new Octavo support: LXA FairyTux 2 based on OSD32MP153C SiP. It contains eMMC for storage, a gigabit Ethernet, a CAN bus and a RS485 transceiver. - Add Plymovent AQM board based on STM32MP151 SoC. It embeds: ETH RMII, WLAN, BT, Sensors (CO2, PM, pressure), Audio (I2S), Storage (SDCard, eMMC). - STM32MP25: - Add STM32MP257F Discovery board: It embeds a STM32MP257FAL SoC, with 4GB of LPDDR4, 2*USB typeA, 1*USB3 typeC, 1*ETH, wifi/BT combo, DSI HDMI, LVDS connector ... - Introduce STM32MP23 SoC and add STM32MP235F Discovery board: It embeds a STM32MP235FAK SoC, with 4GB of LPDDR4, 2*USB typeA, 1*USB3 typeC, 1*ETH, wifi/BT combo, DSI HDMI, LVDS connector ... - Introduce STM32MP21 SoC and STM32MP215F discovery board: It embeds a STM32MP235FAN SoC, with 2GB of LPDDR4, 1*USB2 peripheral bus powered typeC, 1*ETH, wifi/BT combo, LCD 18bit connector, CSI camera connector, ... * tag 'stm32-dt-for-v6.15-1' of https://git.kernel.org/pub/scm/linux/kernel/git/atorgue/stm32: (26 commits) arm64: dts: st: add stm32mp215f-dk board support dt-bindings: stm32: document stm32mp215f-dk board arm64: dts: st: introduce stm32mp21 SoCs family arm64: dts: st: add stm32mp235f-dk board support dt-bindings: stm32: document stm32mp235f-dk board arm64: dts: st: introduce stm32mp23 SoCs family dt-bindings: stm32: add STM32MP21 and STM32MP23 compatibles for syscon arm64: Kconfig: expand STM32 Armv8 SoC with STM32MP21/STM32MP23 SoCs family arm64: dts: st: add stm32mp257f-dk board support dt-bindings: stm32: document stm32mp257f-dk board ARM: dts: stm32: Add Plymovent AQM devicetree ARM: dts: stm32: Add pinmux groups for Plymovent AQM board dt-bindings: arm: stm32: Add Plymovent AQM board dt-bindings: sound: convert ICS-43432 binding to YAML ARM: dts: stm32: Add support for STM32MP13xx DHCOR SoM and DHSBC rev.200 board ARM: dts: stm32: use IRQ_TYPE_EDGE_FALLING on stm32mp157c-dk2 ARM: dts: stm32: add usr3 LED node to stm32f769-disco ARM: dts: stm32: rename LEDs nodes for stm32f769-disco ARM: dts: stm32: add push button to stm32f746 Discovery board ARM: dts: stm32: add led to stm32f746 Discovery board ... Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2025-03-19perf/x86/intel, x86/cpu: Replace Pentium 4 model checks with VFM onesSohil Mehta
Introduce a name for an old Pentium 4 model and replace the x86_model checks with VFM ones. This gets rid of one of the last remaining Intel-specific x86_model checks. Signed-off-by: Sohil Mehta <sohil.mehta@intel.com> Signed-off-by: Ingo Molnar <mingo@kernel.org> Reviewed-by: Kan Liang <kan.liang@linux.intel.com> Cc: Peter Zijlstra <peterz@infradead.org> Link: https://lore.kernel.org/r/20250318223828.2945651-3-sohil.mehta@intel.com
2025-03-19perf/x86/intel, x86/cpu: Simplify Intel PMU initializationSohil Mehta
Architectural Perfmon was introduced on the Family 6 "Core" processors starting with Yonah. Processors before Yonah need their own customized PMU initialization. p6_pmu_init() is expected to provide that initialization for early Family 6 processors. But, currently, it could get called for any Family 6 processor if the architectural perfmon feature is disabled on that processor. To simplify, restrict the P6 PMU initialization to early Family 6 processors that do not have architectural perfmon support and truly need the special handling. As a result, the "unsupported" console print becomes practically unreachable because all the released P6 processors are covered by the switch cases. Move the console print to a common location where it can cover all modern processors (including Family >15) that may not have architectural perfmon support enumerated. Also, use this opportunity to get rid of the unnecessary switch cases in P6 initialization. Only the Pentium Pro processor needs a quirk, and the rest of the processors do not need any special handling. The gaps in the case numbers are only due to no processor with those model numbers being released. Use decimal numbers to represent Intel Family numbers. Also, convert one of the last few Intel x86_model comparisons to a VFM-based one. Signed-off-by: Sohil Mehta <sohil.mehta@intel.com> Signed-off-by: Ingo Molnar <mingo@kernel.org> Reviewed-by: Kan Liang <kan.liang@linux.intel.com> Cc: Peter Zijlstra <peterz@infradead.org> Link: https://lore.kernel.org/r/20250318223828.2945651-2-sohil.mehta@intel.com
2025-03-19rseq/selftests: Fix namespace collision with rseq UAPI headerMichael Jeanson
When the rseq UAPI header is included, 'union rseq' clashes with 'struct rseq'. It's not the case in the rseq selftests but it does break the KVM selftests that also include this file. Rename 'union rseq' to 'union rseq_tls' to fix this. Fixes: e6644c967d3c ("rseq/selftests: Ensure the rseq ABI TLS is actually 1024 bytes") Reported-by: Mark Brown <broonie@kernel.org> Signed-off-by: Michael Jeanson <mjeanson@efficios.com> Signed-off-by: Ingo Molnar <mingo@kernel.org> Reviewed-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com> Link: https://lore.kernel.org/r/20250319202144.1141542-1-mjeanson@efficios.com
2025-03-19MAINTAINERS: Add a secondary maintainer for bluefield_edacDavid Thompson
Add David as a secondary maintainer. [ bp: Rewrite commit message. ] Signed-off-by: David Thompson <davthompson@nvidia.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Link: https://lore.kernel.org/r/20250319181630.2673-1-davthompson@nvidia.com
2025-03-19x86/crc: drop the avx10_256 functions and rename avx10_512 to avx512Eric Biggers
Intel made a late change to the AVX10 specification that removes support for a 256-bit maximum vector length and enumeration of the maximum vector length. AVX10 will imply a maximum vector length of 512 bits. I.e. there won't be any such thing as AVX10/256 or AVX10/512; there will just be AVX10, and it will essentially just consolidate AVX512 features. As a result of this new development, my strategy of providing both *_avx10_256 and *_avx10_512 functions didn't turn out to be that useful. The only remaining motivation for the 256-bit AVX512 / AVX10 functions is to avoid downclocking on older Intel CPUs. But I already wrote *_avx2 code too (primarily to support CPUs without AVX512), which performs almost as well as *_avx10_256. So we should just use that. Therefore, remove the *_avx10_256 CRC functions, and rename the *_avx10_512 CRC functions to *_avx512. Make Ice Lake and Tiger Lake use the *_avx2 functions instead of *_avx10_256 which they previously used. Link: https://lore.kernel.org/r/20250319181316.91271-1-ebiggers@kernel.org Signed-off-by: Eric Biggers <ebiggers@google.com>
2025-03-19Merge tag 'chinese-doc-6.15-rc1' of ↵Jonathan Corbet
gitolite.kernel.org:pub/scm/linux/kernel/git/alexs/linux into docs-mw Chinese translation docs for 6.15-rc1 This is the Chinese translation subtree for 6.15-rc1. It just includes few changes: - Chinese disclaimer change - add a new translation doc: snp-tdx-threat-model - fix a typo Above patches are tested by 'make htmldocs/pdfdocs' Signed-off-by: Alex Shi <alexs@kernel.org>
2025-03-19wifi: mt76: mt7996: fix locking in mt7996_mac_sta_rc_work()Johannes Berg
The 'continue' statements need to be under spinlock, since the spinlock needs to be held as a loop invariant. Fixes: 0762bdd30279 ("wifi: mt76: mt7996: rework mt7996_mac_sta_rc_work to support MLO") Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-03-19Merge tag 'for-net-2025-03-14' of ↵Paolo Abeni
git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth Luiz Augusto von Dentz says: ==================== bluetooth pull request for net: - hci_event: Fix connection regression between LE and non-LE adapters - Fix error code in chan_alloc_skb_cb() * tag 'for-net-2025-03-14' of git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth: Bluetooth: hci_event: Fix connection regression between LE and non-LE adapters Bluetooth: Fix error code in chan_alloc_skb_cb() ==================== Link: https://patch.msgid.link/20250314163847.110069-1-luiz.dentz@gmail.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-03-19Merge tag 'mt76-next-2025-03-19' of https://github.com/nbd168/wirelessJohannes Berg
Felix Fietkau says: ==================== mt76 patches for 6.15 - preparation for mt7996 mlo support - fixes ==================== Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-03-19net: macb: Add __nonstring annotations for unterminated stringsKees Cook
When a character array without a terminating NUL character has a static initializer, GCC 15's -Wunterminated-string-initialization will only warn if the array lacks the "nonstring" attribute[1]. Mark the arrays with __nonstring to correctly identify the char array as "not a C string" and thereby eliminate the warning: In file included from ../drivers/net/ethernet/cadence/macb_main.c:42: ../drivers/net/ethernet/cadence/macb.h:1070:35: warning: initializer-string for array of 'char' truncates NUL terminator but destination lacks 'nonstring' attribute (33 chars into 32 available) [-Wunterminated-string-initialization] 1070 | GEM_STAT_TITLE(TX1519CNT, "tx_greater_than_1518_byte_frames"), | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ../drivers/net/ethernet/cadence/macb.h:1050:24: note: in definition of macro 'GEM_STAT_TITLE_BITS' 1050 | .stat_string = title, \ | ^~~~~ ../drivers/net/ethernet/cadence/macb.h:1070:9: note: in expansion of macro 'GEM_STAT_TITLE' 1070 | GEM_STAT_TITLE(TX1519CNT, "tx_greater_than_1518_byte_frames"), | ^~~~~~~~~~~~~~ ../drivers/net/ethernet/cadence/macb.h:1097:35: warning: initializer-string for array of 'char' truncates NUL terminator but destination lacks 'nonstring' attribute (33 chars into 32 available) [-Wunterminated-string-initialization] 1097 | GEM_STAT_TITLE(RX1519CNT, "rx_greater_than_1518_byte_frames"), | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ../drivers/net/ethernet/cadence/macb.h:1050:24: note: in definition of macro 'GEM_STAT_TITLE_BITS' 1050 | .stat_string = title, \ | ^~~~~ ../drivers/net/ethernet/cadence/macb.h:1097:9: note: in expansion of macro 'GEM_STAT_TITLE' 1097 | GEM_STAT_TITLE(RX1519CNT, "rx_greater_than_1518_byte_frames"), | ^~~~~~~~~~~~~~ Since these strings are copied with memcpy() they do not need to be NUL terminated, and can use __nonstring: memcpy(p, gem_statistics[i].stat_string, ETH_GSTRING_LEN); Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117178 [1] Signed-off-by: Kees Cook <kees@kernel.org> Reviewed-by: Jacob Keller <jacob.e.keller@intel.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://patch.msgid.link/20250312200700.make.521-kees@kernel.org Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-03-19Merge branch 'netconsole-allow-selection-of-egress-interface-via-mac-address'Paolo Abeni
Uday Shankar says: ==================== netconsole: allow selection of egress interface via MAC address This series adds support for selecting a netconsole egress interface by specifying the MAC address (in place of the interface name) in the boot/module parameter. Signed-off-by: Uday Shankar <ushankar@purestorage.com> ==================== Link: https://patch.msgid.link/20250312-netconsole-v6-0-3437933e79b8@purestorage.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-03-19netconsole: allow selection of egress interface via MAC addressUday Shankar
Currently, netconsole has two methods of configuration - module parameter and configfs. The former interface allows for netconsole activation earlier during boot (by specifying the module parameter on the kernel command line), so it is preferred for debugging issues which arise before userspace is up/the configfs interface can be used. The module parameter syntax requires specifying the egress interface name. This requirement makes it hard to use for a couple reasons: - The egress interface name can be hard or impossible to predict. For example, installing a new network card in a system can change the interface names assigned by the kernel. - When constructing the module parameter, one may have trouble determining the original (kernel-assigned) name of the interface (which is the name that should be given to netconsole) if some stable interface naming scheme is in effect. A human can usually look at kernel logs to determine the original name, but this is very painful if automation is constructing the parameter. For these reasons, allow selection of the egress interface via MAC address when configuring netconsole using the module parameter. Update the netconsole documentation with an example of the new syntax. Selection of egress interface by MAC address via configfs is far less interesting (since when this interface can be used, one should be able to easily convert between MAC address and interface name), so it is left unimplemented. Signed-off-by: Uday Shankar <ushankar@purestorage.com> Reviewed-by: Breno Leitao <leitao@debian.org> Tested-by: Breno Leitao <leitao@debian.org> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/20250312-netconsole-v6-2-3437933e79b8@purestorage.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-03-19net, treewide: define and use MAC_ADDR_STR_LENUday Shankar
There are a few places in the tree which compute the length of the string representation of a MAC address as 3 * ETH_ALEN - 1. Define a constant for this and use it where relevant. No functionality changes are expected. Signed-off-by: Uday Shankar <ushankar@purestorage.com> Reviewed-by: Michal Swiatkowski <michal.swiatkowski@linux.intel.com> Acked-by: Johannes Berg <johannes@sipsolutions.net> Reviewed-by: Breno Leitao <leitao@debian.org> Reviewed-by: Simon Horman <horms@verge.net.au> Link: https://patch.msgid.link/20250312-netconsole-v6-1-3437933e79b8@purestorage.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-03-19Merge tag 'hwmon-fixes-for-v6.14-rc8/6.14' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging Pull hwmon fixes from Guenter Roeck: - Fix an entry in MAINTAINERS to avoid sending hwmon review requests to the i2c mailing list - Fix an out-of-bounds access in nct6775 driver * tag 'hwmon-fixes-for-v6.14-rc8/6.14' of git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging: hwmon: (nct6775-core) Fix out of bounds access for NCT679{8,9} MAINTAINERS: correct list and scope of LTC4286 HARDWARE MONITOR
2025-03-19net: stmmac: dwc-qos-eth: use devm_kzalloc() for AXI dataRussell King (Oracle)
Everywhere else in the driver uses devm_kzalloc() when allocating the AXI data, so there is no kfree() of this structure. However, dwc-qos-eth uses kzalloc(), which leads to this memory being leaked. Switch to use devm_kzalloc(). Fixes: d8256121a91a ("stmmac: adding new glue driver dwmac-dwc-qos-eth") Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://patch.msgid.link/E1tsRyv-0064nU-O9@rmk-PC.armlinux.org.uk Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-03-19gpu: host1x: Do not assume that a NULL domain means no DMA IOMMUJason Gunthorpe
Previously with tegra-smmu, even with CONFIG_IOMMU_DMA, the default domain could have been left as NULL. The NULL domain is specially recognized by host1x_iommu_attach() as meaning it is not the DMA domain and should be replaced with the special shared domain. This happened prior to the below commit because tegra-smmu was using the NULL domain to mean IDENTITY. Now that the domain is properly labled the test in DRM doesn't see NULL. Check for IDENTITY as well to enable the special domains. This is the same issue and basic fix as seen in commit fae6e669cdc5 ("drm/tegra: Do not assume that a NULL domain means no DMA IOMMU"). Fixes: c8cc2655cc6c ("iommu/tegra-smmu: Implement an IDENTITY domain") Reported-by: Diogo Ivo <diogo.ivo@tecnico.ulisboa.pt> Closes: https://lore.kernel.org/all/c6a6f114-3acd-4d56-a13b-b88978e927dc@tecnico.ulisboa.pt/ Tested-by: Diogo Ivo <diogo.ivo@tecnico.ulisboa.pt> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com> Signed-off-by: Thierry Reding <treding@nvidia.com> Link: https://patchwork.freedesktop.org/patch/msgid/0-v1-10dcc8ce3869+3a7-host1x_identity_jgg@nvidia.com
2025-03-19r8169: switch away from deprecated pcim_iomap_tableHeiner Kallweit
Avoid using deprecated pcim_iomap_table by switching to pcim_iomap_region. Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Reviewed-by: Jacob Keller <jacob.e.keller@intel.com> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/a36b4cf3-c792-40fa-8164-5dc9d5f14dd0@gmail.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-03-19ASoC: ops: Apply platform_max after deciding control typeCharles Keepax
It doesn't really make sense for the type of a control to change based on the platform_max field. platform_max allows a specific system to limit values of a control for safety but it seems reasonable the control type should remain the same between different systems, even if it is restricted down to just two values. Move the application of platform_max to after control type determination in soc_info_volsw(). Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://patch.msgid.link/20250319175123.3835849-4-ckeepax@opensource.cirrus.com Signed-off-by: Mark Brown <broonie@kernel.org>
2025-03-19ASoC: ops: Remove some unnecessary local variablesCharles Keepax
Remove some local variables that aren't adding much in terms of clarity or space saving. Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://patch.msgid.link/20250319175123.3835849-3-ckeepax@opensource.cirrus.com Signed-off-by: Mark Brown <broonie@kernel.org>
2025-03-19ASoC: ops: Factor out common code from get callbacksCharles Keepax
There are only two differences between snd_soc_get_volsw() and snd_soc_get_volsw_sx(). The maximum field is handled differently, and snd_soc_get_volsw() supports double controls with both values in the same register. Factor out the common code into a new helper and pass in the appropriate max value such that it is handled correctly for each control. Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://patch.msgid.link/20250319175123.3835849-2-ckeepax@opensource.cirrus.com Signed-off-by: Mark Brown <broonie@kernel.org>
2025-03-19Merge branch 'net-bring-back-dev_addr_sem'Paolo Abeni
Stanislav Fomichev says: ==================== net: bring back dev_addr_sem Kohei reports an issue with dev_addr_sem conversion to netdev instance lock in [0]. Based on the discussion, switching to netdev instance lock to protect the address might not work for the devices that are not using netdev ops lock. Bring dev_addr_sem instance lock back but fix the ordering. 0: https://lore.kernel.org/netdev/20250308203835.60633-2-enjuk@amazon.com ==================== Link: https://patch.msgid.link/20250312190513.1252045-1-sdf@fomichev.me Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-03-19net: reorder dev_addr_sem lockStanislav Fomichev
Lockdep complains about circular lock in 1 -> 2 -> 3 (see below). Change the lock ordering to be: - rtnl_lock - dev_addr_sem - netdev_ops (only for lower devices!) - team_lock (or other per-upper device lock) 1. rtnl_lock -> netdev_ops -> dev_addr_sem rtnl_setlink rtnl_lock do_setlink IFLA_ADDRESS on lower netdev_ops dev_addr_sem 2. rtnl_lock -> team_lock -> netdev_ops rtnl_newlink rtnl_lock do_setlink IFLA_MASTER on lower do_set_master team_add_slave team_lock team_port_add dev_set_mtu netdev_ops 3. rtnl_lock -> dev_addr_sem -> team_lock rtnl_newlink rtnl_lock do_setlink IFLA_ADDRESS on upper dev_addr_sem netif_set_mac_address team_set_mac_address team_lock 4. rtnl_lock -> netdev_ops -> dev_addr_sem rtnl_lock dev_ifsioc dev_set_mac_address_user __tun_chr_ioctl rtnl_lock dev_set_mac_address_user tap_ioctl rtnl_lock dev_set_mac_address_user dev_set_mac_address_user netdev_lock_ops netif_set_mac_address_user dev_addr_sem v2: - move lock reorder to happen after kmalloc (Kuniyuki) Cc: Kohei Enju <enjuk@amazon.com> Fixes: df43d8bf1031 ("net: replace dev_addr_sem with netdev instance lock") Signed-off-by: Stanislav Fomichev <sdf@fomichev.me> Reviewed-by: Kuniyuki Iwashima <kuniyu@amazon.com> Link: https://patch.msgid.link/20250312190513.1252045-3-sdf@fomichev.me Tested-by: Lei Yang <leiyang@redhat.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-03-19Revert "net: replace dev_addr_sem with netdev instance lock"Stanislav Fomichev
This reverts commit df43d8bf10316a7c3b1e47e3cc0057a54df4a5b8. Cc: Kohei Enju <enjuk@amazon.com> Reviewed-by: Kuniyuki Iwashima <kuniyu@amazon.com> Fixes: df43d8bf1031 ("net: replace dev_addr_sem with netdev instance lock") Signed-off-by: Stanislav Fomichev <sdf@fomichev.me> Link: https://patch.msgid.link/20250312190513.1252045-2-sdf@fomichev.me Tested-by: Lei Yang <leiyang@redhat.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-03-19tc-tests: Update tc police action tests for tc buffer size rounding fixes.Jonathan Lennox
Before tc's recent change to fix rounding errors, several tests which specified a burst size of "1m" would translate back to being 1048574 bytes (2b less than 1Mb). sprint_size prints this as "1024Kb". With the tc fix, the burst size is instead correctly reported as 1048576 bytes (precisely 1Mb), which sprint_size prints as "1Mb". This updates the expected output in the tests' matchPattern values to accept either the old or the new output. Signed-off-by: Jonathan Lennox <jonathan.lennox@8x8.com> Link: https://patch.msgid.link/20250312174804.313107-1-jonathan.lennox@8x8.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-03-19block: correct locking order for protecting blk-wbt parametersNilay Shroff
The commit '245618f8e45f ("block: protect wbt_lat_usec using q-> elevator_lock")' introduced q->elevator_lock to protect updates to blk-wbt parameters when writing to the sysfs attribute wbt_ lat_usec and the cgroup attribute io.cost.qos. However, both these attributes also acquire q->rq_qos_mutex, leading to the following lockdep warning: ====================================================== WARNING: possible circular locking dependency detected 6.14.0-rc5+ #138 Not tainted ------------------------------------------------------ bash/5902 is trying to acquire lock: c000000085d495a0 (&q->rq_qos_mutex){+.+.}-{4:4}, at: wbt_init+0x164/0x238 but task is already holding lock: c000000085d498c8 (&q->elevator_lock){+.+.}-{4:4}, at: queue_wb_lat_store+0xb0/0x20c which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 (&q->elevator_lock){+.+.}-{4:4}: __mutex_lock+0xf0/0xa58 ioc_qos_write+0x16c/0x85c cgroup_file_write+0xc4/0x32c kernfs_fop_write_iter+0x1b8/0x29c vfs_write+0x410/0x584 ksys_write+0x84/0x140 system_call_exception+0x134/0x360 system_call_vectored_common+0x15c/0x2ec -> #0 (&q->rq_qos_mutex){+.+.}-{4:4}: __lock_acquire+0x1b6c/0x2ae0 lock_acquire+0x140/0x430 __mutex_lock+0xf0/0xa58 wbt_init+0x164/0x238 queue_wb_lat_store+0x1dc/0x20c queue_attr_store+0x12c/0x164 sysfs_kf_write+0x6c/0xb0 kernfs_fop_write_iter+0x1b8/0x29c vfs_write+0x410/0x584 ksys_write+0x84/0x140 system_call_exception+0x134/0x360 system_call_vectored_common+0x15c/0x2ec other info that might help us debug this: Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&q->elevator_lock); lock(&q->rq_qos_mutex); lock(&q->elevator_lock); lock(&q->rq_qos_mutex); *** DEADLOCK *** 6 locks held by bash/5902: #0: c000000051122400 (sb_writers#3){.+.+}-{0:0}, at: ksys_write+0x84/0x140 #1: c00000007383f088 (&of->mutex#2){+.+.}-{4:4}, at: kernfs_fop_write_iter+0x174/0x29c #2: c000000008550428 (kn->active#182){.+.+}-{0:0}, at: kernfs_fop_write_iter+0x180/0x29c #3: c000000085d493a8 (&q->q_usage_counter(io)#5){++++}-{0:0}, at: blk_mq_freeze_queue_nomemsave+0x28/0x40 #4: c000000085d493e0 (&q->q_usage_counter(queue)#5){++++}-{0:0}, at: blk_mq_freeze_queue_nomemsave+0x28/0x40 #5: c000000085d498c8 (&q->elevator_lock){+.+.}-{4:4}, at: queue_wb_lat_store+0xb0/0x20c stack backtrace: CPU: 17 UID: 0 PID: 5902 Comm: bash Kdump: loaded Not tainted 6.14.0-rc5+ #138 Hardware name: IBM,9043-MRX POWER10 (architected) 0x800200 0xf000006 of:IBM,FW1060.00 (NM1060_028) hv:phyp pSeries Call Trace: [c0000000721ef590] [c00000000118f8a8] dump_stack_lvl+0x108/0x18c (unreliable) [c0000000721ef5c0] [c00000000022563c] print_circular_bug+0x448/0x604 [c0000000721ef670] [c000000000225a44] check_noncircular+0x24c/0x26c [c0000000721ef740] [c00000000022bf28] __lock_acquire+0x1b6c/0x2ae0 [c0000000721ef870] [c000000000229240] lock_acquire+0x140/0x430 [c0000000721ef970] [c0000000011cfbec] __mutex_lock+0xf0/0xa58 [c0000000721efaa0] [c00000000096c46c] wbt_init+0x164/0x238 [c0000000721efaf0] [c0000000008f8cd8] queue_wb_lat_store+0x1dc/0x20c [c0000000721efb50] [c0000000008f8fa0] queue_attr_store+0x12c/0x164 [c0000000721efc60] [c0000000007c11cc] sysfs_kf_write+0x6c/0xb0 [c0000000721efca0] [c0000000007bfa4c] kernfs_fop_write_iter+0x1b8/0x29c [c0000000721efcf0] [c0000000006a281c] vfs_write+0x410/0x584 [c0000000721efdc0] [c0000000006a2cc8] ksys_write+0x84/0x140 [c0000000721efe10] [c000000000031b64] system_call_exception+0x134/0x360 [c0000000721efe50] [c00000000000cedc] system_call_vectored_common+0x15c/0x2ec >From the above log it's apparent that method which writes to sysfs attr wbt_lat_usec acquires q->elevator_lock first, and then acquires q->rq_ qos_mutex. However the another method which writes to io.cost.qos, acquires q->rq_qos_mutex first, and then acquires q->rq_qos_mutex. So this could potentially cause the deadlock. A closer look at ioc_qos_write shows that correcting the lock order is non-trivial because q->rq_qos_mutex is acquired in blkg_conf_open_bdev and released in blkg_conf_exit. The function blkg_conf_open_bdev is responsible for parsing user input and finding the corresponding block device (bdev) from the user provided major:minor number. Since we do not know the bdev until blkg_conf_open_bdev completes, we cannot simply move q->elevator_lock acquisition before blkg_conf_open_ bdev. So to address this, we intoduce new helpers blkg_conf_open_bdev_ frozen and blkg_conf_exit_frozen which are just wrappers around blkg_ conf_open_bdev and blkg_conf_exit respectively. The helper blkg_conf_ open_bdev_frozen is similar to blkg_conf_open_bdev, but additionally freezes the queue, acquires q->elevator_lock and ensures the correct locking order is followed between q->elevator_lock and q->rq_qos_mutex. Similarly another helper blkg_conf_exit_frozen in addition to unfreezing the queue ensures that we release the locks in correct order. By using these helpers, now we maintain the same locking order in all code paths where we update blk-wbt parameters. Fixes: 245618f8e45f ("block: protect wbt_lat_usec using q->elevator_lock") Reported-by: kernel test robot <oliver.sang@intel.com> Closes: https://lore.kernel.org/oe-lkp/202503171650.cc082b66-lkp@intel.com Signed-off-by: Nilay Shroff <nilay@linux.ibm.com> Link: https://lore.kernel.org/r/20250319105518.468941-3-nilay@linux.ibm.com Signed-off-by: Jens Axboe <axboe@kernel.dk>
2025-03-19block: release q->elevator_lock in ioc_qos_writeNilay Shroff
The ioc_qos_write method acquires q->elevator_lock to protect updates to blk-wbt parameters. Once these updates are complete, the lock should be released before returning from ioc_qos_write. However, in one code path, the release of q->elevator_lock was mistakenly omitted, potentially leading to a lock leak. This commit fixes the issue by ensuring that q->elevator_lock is properly released in all return paths of ioc_qos_write. Fixes: 245618f8e45f ("block: protect wbt_lat_usec using q->elevator_lock") Reported-by: kernel test robot <oliver.sang@intel.com> Closes: https://lore.kernel.org/oe-lkp/202503171650.cc082b66-lkp@intel.com Signed-off-by: Nilay Shroff <nilay@linux.ibm.com> Reviewed-by: Ming Lei <ming.lei@redhat.com> Link: https://lore.kernel.org/r/20250319105518.468941-2-nilay@linux.ibm.com Signed-off-by: Jens Axboe <axboe@kernel.dk>
2025-03-19net: stmmac: dwmac-rk: Provide FIFO sizes for DWMAC 1000Chen-Yu Tsai
The DWMAC 1000 DMA capabilities register does not provide actual FIFO sizes, nor does the driver really care. If they are not provided via some other means, the driver will work fine, only disallowing changing the MTU setting. Provide the FIFO sizes through the driver's platform data to enable MTU changes. The FIFO sizes are confirmed to be the same across RK3288, RK3328, RK3399 and PX30, based on their respective manuals. It is likely that Rockchip synthesized their DWMAC 1000 with the same parameters on all their chips that have it. Signed-off-by: Chen-Yu Tsai <wens@csie.org> Reviewed-by: Jacob Keller <jacob.e.keller@intel.com> Link: https://patch.msgid.link/20250312163426.2178314-1-wens@kernel.org Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-03-19cgroup/rstat: avoid disabling irqs for O(num_cpu)Eric Dumazet
cgroup_rstat_flush_locked() grabs the irq safe cgroup_rstat_lock while iterating all possible cpus. It only drops the lock if there is scheduler or spin lock contention. If neither, then interrupts can be disabled for a long time. On large machines this can disable interrupts for a long enough time to drop network packets. On 400+ CPU machines I've seen interrupt disabled for over 40 msec. Prevent rstat from disabling interrupts while processing all possible cpus. Instead drop and reacquire cgroup_rstat_lock for each cpu. This approach was previously discussed in https://lore.kernel.org/lkml/ZBz%2FV5a7%2F6PZeM7S@slm.duckdns.org/, though this was in the context of an non-irq rstat spin lock. Benchmark this change with: 1) a single stat_reader process with 400 threads, each reading a test memcg's memory.stat repeatedly for 10 seconds. 2) 400 memory hog processes running in the test memcg and repeatedly charging memory until oom killed. Then they repeat charging and oom killing. v6.14-rc6 with CONFIG_IRQSOFF_TRACER with stat_reader and hogs, finds interrupts are disabled by rstat for 45341 usec: # => started at: _raw_spin_lock_irq # => ended at: cgroup_rstat_flush # # # _------=> CPU# # / _-----=> irqs-off/BH-disabled # | / _----=> need-resched # || / _---=> hardirq/softirq # ||| / _--=> preempt-depth # |||| / _-=> migrate-disable # ||||| / delay # cmd pid |||||| time | caller # \ / |||||| \ | / stat_rea-96532 52d.... 0us*: _raw_spin_lock_irq stat_rea-96532 52d.... 45342us : cgroup_rstat_flush stat_rea-96532 52d.... 45342us : tracer_hardirqs_on <-cgroup_rstat_flush stat_rea-96532 52d.... 45343us : <stack trace> => memcg1_stat_format => memory_stat_format => memory_stat_show => seq_read_iter => vfs_read => ksys_read => do_syscall_64 => entry_SYSCALL_64_after_hwframe With this patch the CONFIG_IRQSOFF_TRACER doesn't find rstat to be the longest holder. The longest irqs-off holder has irqs disabled for 4142 usec, a huge reduction from previous 45341 usec rstat finding. Running stat_reader memory.stat reader for 10 seconds: - without memory hogs: 9.84M accesses => 12.7M accesses - with memory hogs: 9.46M accesses => 11.1M accesses The throughput of memory.stat access improves. The mode of memory.stat access latency after grouping by of 2 buckets: - without memory hogs: 64 usec => 16 usec - with memory hogs: 64 usec => 8 usec The memory.stat latency improves. Signed-off-by: Eric Dumazet <edumazet@google.com> Signed-off-by: Greg Thelen <gthelen@google.com> Tested-by: Greg Thelen <gthelen@google.com> Acked-by: Michal Koutný <mkoutny@suse.com> Reviewed-by: Yosry Ahmed <yosry.ahmed@linux.dev> Signed-off-by: Tejun Heo <tj@kernel.org>
2025-03-19selftests: drv-net: use defer in the ping testJakub Kicinski
Make sure the test cleans up after itself. The XDP off statements at the end of the test may not be reached. Fixes: 75cc19c8ff89 ("selftests: drv-net: add xdp cases for ping.py") Signed-off-by: Jakub Kicinski <kuba@kernel.org> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/20250312131040.660386-1-kuba@kernel.org Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-03-19Merge branch 'net-mlx5-hw-steering-cleanups'Paolo Abeni
Tariq Toukan says: ==================== net/mlx5: HW Steering cleanups This short series by Yevgeny contains several small HW Steering cleanups: - Patch 1: removing unused FW commands - Patch 2: using list_move() instead of list_del/add - Patch 3: printing the unsupported combination of match fields ==================== Link: https://patch.msgid.link/1741780194-137519-1-git-send-email-tariqt@nvidia.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-03-19net/mlx5: HWS, log the unsupported mask in definerYevgeny Kliteynik
If a user requested to match on an unsupported combination of fields, print the unsupported combination in the error message. Signed-off-by: Yevgeny Kliteynik <kliteyn@nvidia.com> Reviewed-by: Vlad Dogaru <vdogaru@nvidia.com> Reviewed-by: Mark Bloch <mbloch@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Link: https://patch.msgid.link/1741780194-137519-4-git-send-email-tariqt@nvidia.com Reviewed-by: Dawid Osuchowski <dawid.osuchowski@linux.intel.com> Reviewed-by: Michal Kubiak <michal.kubiak@intel.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-03-19net/mlx5: HWS, use list_move() instead of del/addYevgeny Kliteynik
Wherever applicable, use list_move function instead of list_del + list_add. Signed-off-by: Yevgeny Kliteynik <kliteyn@nvidia.com> Reviewed-by: Vlad Dogaru <vdogaru@nvidia.com> Reviewed-by: Mark Bloch <mbloch@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Link: https://patch.msgid.link/1741780194-137519-3-git-send-email-tariqt@nvidia.com Reviewed-by: Dawid Osuchowski <dawid.osuchowski@linux.intel.com> Reviewed-by: Michal Kubiak <michal.kubiak@intel.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-03-19net/mlx5: HWS, remove unused code for alias flow tablesYevgeny Kliteynik
Alias flow tables are not in use by HWS - remove the unused code. Signed-off-by: Yevgeny Kliteynik <kliteyn@nvidia.com> Reviewed-by: Vlad Dogaru <vdogaru@nvidia.com> Reviewed-by: Mark Bloch <mbloch@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Link: https://patch.msgid.link/1741780194-137519-2-git-send-email-tariqt@nvidia.com Reviewed-by: Dawid Osuchowski <dawid.osuchowski@linux.intel.com> Reviewed-by: Michal Kubiak <michal.kubiak@intel.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-03-19Merge branch 'net-stmmac-deprecate-snps-en-tx-lpi-clockgating-property'Paolo Abeni
Russell King says: ==================== net: stmmac: deprecate "snps,en-tx-lpi-clockgating" property This series deprecates the "snps,en-tx-lpi-clockgating" property for stmmac. MII Transmit clock gating, where the MAC hardware supports gating this clock, is a function of the connected PHY capabilities, which it reports through its status register. GMAC versions that support transmit clock gating twiddle the LPITCSE bit accordingly in the LPI control/status register, which is handled by the GMAC core specific code. So, "snps,en-tx-lpi-clockgating" not something that is a GMAC property, but is a work-around for phylib not providing an interface to determine whether the PHY allows the transmit clock to be disabled. This series converts the two SoCs that make use of this property (which, I hasten to add, is set in the SoC code) to use the PHY capability bit instead of a DT property, then removes the DT property from the .dtsi, deprecates it in the snps,dwmac binding, and finally in the stmmac code. I am expecting some discussion on how to merge this, as I think the order in which these changes is made is important - we don't want to deprecate the old way until the new code has landed. ==================== Link: https://patch.msgid.link/Z9FVHEf3uUqtKzyt@shell.armlinux.org.uk Signed-off-by: Paolo Abeni <pabeni@redhat.com>