Author: Joe Hattori <[email protected]> Date: Wed Dec 11 12:28:12 2024 +0900 ACPI: fan: cleanup resources in the error path of .probe() [ Upstream commit c759bc8e9046f9812238f506d70f07d3ea4206d4 ] Call thermal_cooling_device_unregister() and sysfs_remove_link() in the error path of acpi_fan_probe() to fix possible memory leak. This bug was found by an experimental static analysis tool that I am developing. Fixes: 05a83d972293 ("ACPI: register ACPI Fan as generic thermal cooling device") Signed-off-by: Joe Hattori <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Rafael J. Wysocki <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: David Howells <[email protected]> Date: Mon Dec 16 20:41:14 2024 +0000 afs: Fix cleanup of immediately failed async calls [ Upstream commit 9750be93b2be12b6d92323b97d7c055099d279e6 ] If we manage to begin an async call, but fail to transmit any data on it due to a signal, we then abort it which causes a race between the notification of call completion from rxrpc and our attempt to cancel the notification. The notification will be necessary, however, for async FetchData to terminate the netfs subrequest. However, since we get a notification from rxrpc upon completion of a call (aborted or otherwise), we can just leave it to that. This leads to calls not getting cleaned up, but appearing in /proc/net/rxrpc/calls as being aborted with code 6. Fix this by making the "error_do_abort:" case of afs_make_call() abort the call and then abandon it to the notification handler. Fixes: 34fa47612bfe ("afs: Fix race in async call refcounting") Reported-by: Marc Dionne <[email protected]> Signed-off-by: David Howells <[email protected]> Link: https://lore.kernel.org/r/[email protected] cc: [email protected] Signed-off-by: Christian Brauner <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: David Howells <[email protected]> Date: Mon Dec 16 20:41:03 2024 +0000 afs: Fix directory format encoding struct [ Upstream commit 07a10767853adcbdbf436dc91393b729b52c4e81 ] The AFS directory format structure, union afs_xdr_dir_block::meta, has too many alloc counter slots declared and so pushes the hash table along and over the data. This doesn't cause a problem at the moment because I'm currently ignoring the hash table and only using the correct number of alloc_ctrs in the code anyway. In future, however, I should start using the hash table to try and speed up afs_lookup(). Fix this by using the correct constant to declare the counter array. Fixes: 4ea219a839bf ("afs: Split the directory content defs into a header") Signed-off-by: David Howells <[email protected]> Link: https://lore.kernel.org/r/[email protected] cc: Marc Dionne <[email protected]> cc: [email protected] Signed-off-by: Christian Brauner <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: David Howells <[email protected]> Date: Mon Dec 16 20:41:02 2024 +0000 afs: Fix EEXIST error returned from afs_rmdir() to be ENOTEMPTY [ Upstream commit b49194da2aff2c879dec9c59ef8dec0f2b0809ef ] AFS servers pass back a code indicating EEXIST when they're asked to remove a directory that is not empty rather than ENOTEMPTY because not all the systems that an AFS server can run on have the latter error available and AFS preexisted the addition of that error in general. Fix afs_rmdir() to translate EEXIST to ENOTEMPTY. Fixes: 260a980317da ("[AFS]: Add "directory write" support.") Signed-off-by: David Howells <[email protected]> Link: https://lore.kernel.org/r/[email protected] cc: Marc Dionne <[email protected]> cc: [email protected] Signed-off-by: Christian Brauner <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: David Howells <[email protected]> Date: Tue Jan 14 14:46:03 2025 +0000 afs: Fix the fallback handling for the YFS.RemoveFile2 RPC call [ Upstream commit e30458d690f35abb01de8b3cbc09285deb725d00 ] Fix a pair of bugs in the fallback handling for the YFS.RemoveFile2 RPC call: (1) Fix the abort code check to also look for RXGEN_OPCODE. The lack of this masks the second bug. (2) call->server is now not used for ordinary filesystem RPC calls that have an operation descriptor. Fix to use call->op->server instead. Fixes: e49c7b2f6de7 ("afs: Build an abstraction around an "operation" concept") Signed-off-by: David Howells <[email protected]> Link: https://lore.kernel.org/r/[email protected] cc: Marc Dionne <[email protected]> cc: [email protected] Signed-off-by: Christian Brauner <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Suren Baghdasaryan <[email protected]> Date: Thu Dec 26 13:16:38 2024 -0800 alloc_tag: avoid current->alloc_tag manipulations when profiling is disabled [ Upstream commit 07438779313caafe52ac1a1a6958d735a5938988 ] When memory allocation profiling is disabled there is no need to update current->alloc_tag and these manipulations add unnecessary overhead. Fix the overhead by skipping these extra updates. I ran comprehensive testing on Pixel 6 on Big, Medium and Little cores: Overhead before fixes Overhead after fixes slab alloc page alloc slab alloc page alloc Big 6.21% 5.32% 3.31% 4.93% Medium 4.51% 5.05% 3.79% 4.39% Little 7.62% 1.82% 6.68% 1.02% This is an allocation microbenchmark doing allocations in a tight loop. Not a really realistic scenario and useful only to make performance comparisons. Link: https://lkml.kernel.org/r/[email protected] Fixes: b951aaff5035 ("mm: enable page allocation tagging") Signed-off-by: Suren Baghdasaryan <[email protected]> Cc: David Wang <[email protected]> Cc: Kent Overstreet <[email protected]> Cc: Yu Zhao <[email protected]> Cc: Zhenhua Huang <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Kailang Yang <[email protected]> Date: Mon Dec 30 14:44:01 2024 +0800 ALSA: hda/realtek - Fixed headphone distorted sound on Acer Aspire A115-31 laptop [ Upstream commit 5cb4e5b056772e341b590755a976081776422053 ] Sound played through headphones is distorted. Fixes: 34ab5bbc6e82 ("ALSA: hda/realtek - Add Headset Mic supported Acer NB platform") Closes: https://lore.kernel.org/linux-sound/[email protected]/ Signed-off-by: Kailang Yang <[email protected]> Link: https://lore.kernel.org/[email protected] Signed-off-by: Takashi Iwai <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Cezary Rojewski <[email protected]> Date: Fri Jan 10 12:33:25 2025 +0100 ALSA: hda: Fix compilation of snd_hdac_adsp_xxx() helpers [ Upstream commit 7579790915387396e26041ceafbc07348658edef ] The snd_hdac_adsp_xxx() wrap snd_hdac_reg_xxx() helpers to simplify register access for AudioDSP drivers e.g.: the avs-driver. Byte- and word-variants of said helps do not expand to bare readx/writex() operations but functions instead and, due to pointer type incompatibility, cause compilation to fail. As the macros are utilized by the avs-driver alone, relocate the code introduced with commit c19bd02e9029 ("ALSA: hda: Add helper macros for DSP capable devices") into the avs/ directory and update it to operate on 'adev' i.e.: the avs-driver-context directly to fix the issue. Fixes: c19bd02e9029 ("ALSA: hda: Add helper macros for DSP capable devices") Signed-off-by: Cezary Rojewski <[email protected]> Acked-by: Mark Brown <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Takashi Iwai <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Takashi Iwai <[email protected]> Date: Wed Jan 1 13:55:47 2025 +0100 ALSA: seq: Make dependency on UMP clearer [ Upstream commit 9001d515443518d72222ba4d58e247696b625071 ] CONFIG_SND_SEQ_UMP_CLIENT is a Kconfig for a sequencer client corresponding to the UMP rawmidi, while we have another major knob CONFIG_SND_SEQ_UMP that specifies whether the sequencer core supports UMP packets or not. Strictly speaking both of them are independent, but practically seen, it makes no sense to enable CONFIG_SND_SEQ_UMP_CLIENT without UMP support itself. This patch makes such an implicit dependency clearer. Now CONFIG_SND_SEQ_UMP_CLIENT depends on both CONFIG_SND_UMP and CONFIG_SND_SEQ_UMP. Meanwhile, CONFIG_SND_SEQ_UMP is enabled as default when CONFIG_SND_UMP is set. Fixes: 81fd444aa371 ("ALSA: seq: Bind UMP device") Link: https://patch.msgid.link/[email protected] Signed-off-by: Takashi Iwai <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Lianqin Hu <[email protected]> Date: Sun Jan 26 03:51:11 2025 +0000 ALSA: usb-audio: Add delay quirk for iBasso DC07 Pro commit d85fc52cbb9a719c8335d93a28d6a79d7acd419f upstream. Audio control requests that sets sampling frequency sometimes fail on this card. Adding delay between control messages eliminates that problem. usb 1-1: New USB device found, idVendor=2fc6, idProduct=f0b7 usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3 usb 1-1: Product: iBasso DC07 Pro usb 1-1: Manufacturer: iBasso usb 1-1: SerialNumber: CTUA171130B Signed-off-by: Lianqin Hu <[email protected]> Cc: <[email protected]> Link: https://patch.msgid.link/TYUPR06MB62174A48D04E09A37996DF84D2ED2@TYUPR06MB6217.apcprd06.prod.outlook.com Signed-off-by: Takashi Iwai <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Ross Burton <[email protected]> Date: Fri Dec 13 16:12:58 2024 +0000 arm64: defconfig: remove obsolete CONFIG_SM_DISPCC_8650 [ Upstream commit 9be2923ff9641d6491b8ea43791382966505435f ] This option was removed from the Kconfig in commit 802b83205519 ("clk: qcom: fold dispcc-sm8650 info dispcc-sm8550") but it was not removed from the defconfig. Fixes: 802b83205519 ("clk: qcom: fold dispcc-sm8650 info dispcc-sm8550") Signed-off-by: Ross Burton <[email protected]> Reviewed-by: Krzysztof Kozlowski <[email protected]> Reviewed-by: Neil Armstrong <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bjorn Andersson <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Shengjiu Wang <[email protected]> Date: Tue Nov 19 09:58:05 2024 +0800 arm64: dts: imx93: Use IMX93_CLK_SPDIF_IPG as SPDIF IPG clock [ Upstream commit 570b890e66334f283710af36feb2115f16c7a27c ] IMX93_CLK_BUS_WAKEUP is not accurate IPG clock, which missed the clock gate part. IMX93_CLK_SPDIF_IPG is the correct clock. Fixes: 1c4a4f7362fd ("arm64: dts: imx93: Add audio device nodes") Signed-off-by: Shengjiu Wang <[email protected]> Reviewed-by: Frank Li <[email protected]> Acked-by: Shawn Guo <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Abel Vesa <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Josua Mayer <[email protected]> Date: Tue Nov 19 18:33:08 2024 +0100 arm64: dts: marvell: cn9131-cf-solidwan: fix cp1 comphy links [ Upstream commit 09cdb973afa7a18ce8e66807daff94609cc4b8a4 ] Marvell CN913x platforms use common phy framework for configuring and linking serdes lanes according to their usage. Each CP (X) features 5 serdes lanes (Y) represented by cpX_comphyY nodes. CN9131 SolidWAN uses CP1 serdes lanes 3 and 5 for eth1 and eth2 of CP1 respectively. Devicetree however wrongly links from these ports to the comphy of CP0. Replace the wrong links to cp0_comphy with cp1_comphy inside cp1_eth1, cp1_eth2. Fixes: 1280840d2030 ("arm64: dts: add description for solidrun cn9131 solidwan board") Signed-off-by: Josua Mayer <[email protected]> Signed-off-by: Gregory CLEMENT <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Chen-Yu Tsai <[email protected]> Date: Wed Dec 11 13:24:25 2024 +0800 arm64: dts: medaitek: mt8395-nio-12l: Drop regulator-compatible property [ Upstream commit ab60442f26b15ba69b210974722a851ed03188ff ] The "regulator-compatible" property has been deprecated since 2012 in commit 13511def87b9 ("regulator: deprecate regulator-compatible DT property"), which is so old it's not even mentioned in the converted regulator bindings YAML file. It should not have been used for new submissions such as the MT6315. Drop the "regulator-compatible" property from the board dts. The property values are the same as the node name, so everything should continue to work. Fixes: 96564b1e2ea4 ("arm64: dts: mediatek: Introduce the MT8395 Radxa NIO 12L board") Signed-off-by: Chen-Yu Tsai <[email protected]> Reviewed-by: AngeloGioacchino Del Regno <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: AngeloGioacchino Del Regno <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Val Packett <[email protected]> Date: Wed Dec 25 16:26:20 2024 -0300 arm64: dts: mediatek: add per-SoC compatibles for keypad nodes [ Upstream commit 6139d9e9e397dc9711cf10f8f548a8f9da3b5323 ] The mt6779-keypad binding specifies using a compatible for the actual SoC before the generic MT6779 one. Fixes: a8013418d35c ("arm64: dts: mediatek: mt8183: add keyboard node") Fixes: 6ff945376556 ("arm64: dts: mediatek: Initial mt8365-evk support") Signed-off-by: Val Packett <[email protected]> Reviewed-by: Mattijs Korpershoek <[email protected]> Reviewed-by: AngeloGioacchino Del Regno <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: AngeloGioacchino Del Regno <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Frank Wunderlich <[email protected]> Date: Tue Dec 17 10:12:19 2024 +0100 arm64: dts: mediatek: mt7988: Add missing clock-div property for i2c [ Upstream commit e14b49db0087aa5d72f736d7306220ff2e3777f5 ] I2C binding requires clock-div property. Signed-off-by: Frank Wunderlich <[email protected]> Fixes: 660c230bf302 ("arm64: dts: mediatek: mt7988: add I2C controllers") Reviewed-by: AngeloGioacchino Del Regno <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: AngeloGioacchino Del Regno <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Chen-Yu Tsai <[email protected]> Date: Wed Dec 11 13:24:21 2024 +0800 arm64: dts: mediatek: mt8173-elm: Drop regulator-compatible property [ Upstream commit 4b907b3ea5fba240808136cc5599d14b52230b39 ] The "regulator-compatible" property has been deprecated since 2012 in commit 13511def87b9 ("regulator: deprecate regulator-compatible DT property"), which is so old it's not even mentioned in the converted regulator bindings YAML file. It is also not listed in the MT6397 regulator bindings. Having them present produces a whole bunch of validation errors: Unevaluated properties are not allowed ('regulator-compatible' was unexpected) Drop the "regulator-compatible" property from the board dts. The property values are the same as the node name, so everything should continue to work. Fixes: 689b937bedde ("arm64: dts: mediatek: add mt8173 elm and hana board") Signed-off-by: Chen-Yu Tsai <[email protected]> Reviewed-by: AngeloGioacchino Del Regno <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: AngeloGioacchino Del Regno <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Chen-Yu Tsai <[email protected]> Date: Tue Dec 10 17:26:12 2024 +0800 arm64: dts: mediatek: mt8173-elm: Fix MT6397 PMIC sub-node names [ Upstream commit beb06b727194f68b0a4b5183e50c88265ce185af ] The MT6397 PMIC bindings specify exact names for its sub-nodes. The names used in the current dts don't match, causing a validation error. Fix up the names. Also drop the label for the regulators node, since any reference should be against the individual regulator sub-nodes. Fixes: 689b937bedde ("arm64: dts: mediatek: add mt8173 elm and hana board") Signed-off-by: Chen-Yu Tsai <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: AngeloGioacchino Del Regno <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Chen-Yu Tsai <[email protected]> Date: Wed Dec 11 13:24:20 2024 +0800 arm64: dts: mediatek: mt8173-evb: Drop regulator-compatible property [ Upstream commit a6d5983e40f5d5b219337569cdd269727f5a3e2e ] The "regulator-compatible" property has been deprecated since 2012 in commit 13511def87b9 ("regulator: deprecate regulator-compatible DT property"), which is so old it's not even mentioned in the converted regulator bindings YAML file. It is also not listed in the MT6397 regulator bindings. Having them present produces a whole bunch of validation errors: Unevaluated properties are not allowed ('regulator-compatible' was unexpected) Drop the "regulator-compatible" property from the board dts. The property values are the same as the node name, so everything should continue to work. Fixes: 16ea61fc5614 ("arm64: dts: mt8173-evb: Add PMIC support") Signed-off-by: Chen-Yu Tsai <[email protected]> Reviewed-by: AngeloGioacchino Del Regno <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: AngeloGioacchino Del Regno <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Chen-Yu Tsai <[email protected]> Date: Tue Dec 10 17:26:13 2024 +0800 arm64: dts: mediatek: mt8173-evb: Fix MT6397 PMIC sub-node names [ Upstream commit 9545ba142865b9099d43c972b9ebcf463606499a ] The MT6397 PMIC bindings specify exact names for its sub-nodes. The names used in the current dts don't match, causing a validation error. Fix up the names. Also drop the label for the regulators node, since any reference should be against the individual regulator sub-nodes. Fixes: 16ea61fc5614 ("arm64: dts: mt8173-evb: Add PMIC support") Signed-off-by: Chen-Yu Tsai <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: AngeloGioacchino Del Regno <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Chen-Yu Tsai <[email protected]> Date: Wed Oct 30 15:02:20 2024 +0800 arm64: dts: mediatek: mt8183-kukui-jacuzzi: Drop pp3300_panel voltage settings [ Upstream commit 0b5b1c881a909f17c05ef4b1ccb421e077f6e466 ] The pp3300_panel fixed regulator is just a load switch. It does not have any regulating capabilities. Thus having voltage constraints on it is wrong. Remove the voltage constraints. Fixes: cabc71b08eb5 ("arm64: dts: mt8183: Add kukui-jacuzzi-damu board") Signed-off-by: Chen-Yu Tsai <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: AngeloGioacchino Del Regno <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Hsin-Te Yuan <[email protected]> Date: Fri Dec 13 05:27:47 2024 +0000 arm64: dts: mediatek: mt8183: kenzo: Support second source touchscreen [ Upstream commit 5ec5dc73c5ac0c6e06803dc3b5aea4493e856568 ] Some kenzo devices use second source touchscreen. Fixes: 0a9cefe21aec ("arm64: dts: mt8183: Add kukui-jacuzzi-kenzo board") Signed-off-by: Hsin-Te Yuan <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: AngeloGioacchino Del Regno <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Hsin-Te Yuan <[email protected]> Date: Fri Dec 13 05:27:48 2024 +0000 arm64: dts: mediatek: mt8183: willow: Support second source touchscreen [ Upstream commit 9594935260d76bffe200bea6cfab6ba0752e70d9 ] Some willow devices use second source touchscreen. Fixes: f006bcf1c972 ("arm64: dts: mt8183: Add kukui-jacuzzi-willow board") Signed-off-by: Hsin-Te Yuan <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: AngeloGioacchino Del Regno <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Nícolas F. R. A. Prado <[email protected]> Date: Wed Nov 6 16:01:45 2024 -0500 arm64: dts: mediatek: mt8186: Move wakeup to MTU3 to get working suspend [ Upstream commit 253b4e96f5783fddede1b82274a7b4e0aa57d761 ] The current DT has the wakeup-source and mediatek,syscon-wakeup properties in the XHCI nodes, which configures USB wakeup after powering down the XHCI hardware block. However, since the XHCI controller is behind an MTU3 (USB3 DRD controller), the MTU3 only gets powered down after USB wakeup has been configured, causing the system to detect a wakeup, and results in broken suspend support as the system resumes immediately. Move the wakeup properties to the MTU3 nodes so that USB wakeup is only enabled after the MTU3 has powered down. With this change in place, it is possible to suspend and resume, and also to wakeup through USB, as tested on the Google Steelix (Lenovo 300e Yoga Chromebook Gen 4). Fixes: f6c3e61c5486 ("arm64: dts: mediatek: mt8186: Add MTU3 nodes") Reported-by: Wojciech Macek <[email protected]> Suggested-by: AngeloGioacchino Del Regno <[email protected]> Signed-off-by: Nícolas F. R. A. Prado <[email protected]> Reviewed-by: AngeloGioacchino Del Regno <[email protected]> Link: https://lore.kernel.org/r/20241106-mt8186-suspend-with-usb-wakeup-v1-1-07734a4c8236@collabora.com Signed-off-by: AngeloGioacchino Del Regno <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Chen-Yu Tsai <[email protected]> Date: Wed Dec 11 13:24:22 2024 +0800 arm64: dts: mediatek: mt8192-asurada: Drop regulator-compatible property [ Upstream commit d1fb968551c8688652b8b817bb081fdc9c25cd48 ] The "regulator-compatible" property has been deprecated since 2012 in commit 13511def87b9 ("regulator: deprecate regulator-compatible DT property"), which is so old it's not even mentioned in the converted regulator bindings YAML file. It should not have been used for new submissions such as the MT6315. Drop the "regulator-compatible" property from the board dts. The property values are the same as the node name, so everything should continue to work. Fixes: 3183cb62b033 ("arm64: dts: mediatek: asurada: Add SPMI regulators") Signed-off-by: Chen-Yu Tsai <[email protected]> Reviewed-by: AngeloGioacchino Del Regno <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: AngeloGioacchino Del Regno <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Chen-Yu Tsai <[email protected]> Date: Wed Dec 11 13:24:23 2024 +0800 arm64: dts: mediatek: mt8195-cherry: Drop regulator-compatible property [ Upstream commit 4dbaa5d5def2c49e44efaa5e796c23d9b904be09 ] The "regulator-compatible" property has been deprecated since 2012 in commit 13511def87b9 ("regulator: deprecate regulator-compatible DT property"), which is so old it's not even mentioned in the converted regulator bindings YAML file. It should not have been used for new submissions such as the MT6315. Drop the "regulator-compatible" property from the board dts. The property values are the same as the node name, so everything should continue to work. Fixes: 260c04d425eb ("arm64: dts: mediatek: cherry: Enable MT6315 regulators on SPMI bus") Signed-off-by: Chen-Yu Tsai <[email protected]> Reviewed-by: AngeloGioacchino Del Regno <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: AngeloGioacchino Del Regno <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Chen-Yu Tsai <[email protected]> Date: Wed Dec 11 13:24:24 2024 +0800 arm64: dts: mediatek: mt8195-demo: Drop regulator-compatible property [ Upstream commit 2a8af9b95f504260a6d8200a11f0ae5c90e9f787 ] The "regulator-compatible" property has been deprecated since 2012 in commit 13511def87b9 ("regulator: deprecate regulator-compatible DT property"), which is so old it's not even mentioned in the converted regulator bindings YAML file. It is also not listed in the MT6360 regulator and charger bindings. Drop the "regulator-compatible" property from the board dts. The MT6360 bindings actually require the lowercase name, so with the property present the regulators were likely not actually working. Fixes: 6147314aeedc ("arm64: dts: mediatek: Add device-tree for MT8195 Demo board") Signed-off-by: Chen-Yu Tsai <[email protected]> Reviewed-by: AngeloGioacchino Del Regno <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: AngeloGioacchino Del Regno <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Nícolas F. R. A. Prado <[email protected]> Date: Wed Dec 18 19:01:08 2024 -0300 arm64: dts: mediatek: mt8195: Remove suspend-breaking reset from pcie1 [ Upstream commit 3d7fdd8e38aafd4858935df2392762c1ab8fb40f ] The MAC reset for PCIe port 1 on MT8195 when asserted during suspend causes the system to hang during resume with the following error (with no_console_suspend enabled): mtk-pcie-gen3 112f8000.pcie: PCIe link down, current LTSSM state: detect.quiet (0x0) mtk-pcie-gen3 112f8000.pcie: PM: dpm_run_callback(): genpd_resume_noirq+0x0/0x24 returns -110 mtk-pcie-gen3 112f8000.pcie: PM: failed to resume noirq: error -110 This issue is specific to MT8195. On MT8192 with the PCIe reset, MT8192_INFRA_RST4_PCIE_TOP_SWRST, added to the DT node, the issue is not observed. Since without the reset, the PCIe controller and WiFi card connected to it, work just as well, remove the reset to allow the system to suspend and resume properly. Fixes: ecc0af6a3fe6 ("arm64: dts: mt8195: Add pcie and pcie phy nodes") Signed-off-by: Nícolas F. R. A. Prado <[email protected]> Link: https://lore.kernel.org/r/20241218-mt8195-pcie1-reset-suspend-fix-v1-1-1c021dda42a6@collabora.com Signed-off-by: AngeloGioacchino Del Regno <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Chen-Yu Tsai <[email protected]> Date: Wed Dec 11 13:24:26 2024 +0800 arm64: dts: mediatek: mt8395-genio-1200-evk: Drop regulator-compatible property [ Upstream commit b99bf07c2c8b3c85c1935ddca2a73bc686f8d847 ] The "regulator-compatible" property has been deprecated since 2012 in commit 13511def87b9 ("regulator: deprecate regulator-compatible DT property"), which is so old it's not even mentioned in the converted regulator bindings YAML file. It should not have been used for new submissions such as the MT6315. Drop the "regulator-compatible" property from the board dts. The property values are the same as the node name, so everything should continue to work. Fixes: f2b543a191b6 ("arm64: dts: mediatek: add device-tree for Genio 1200 EVK board") Signed-off-by: Chen-Yu Tsai <[email protected]> Reviewed-by: AngeloGioacchino Del Regno <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: AngeloGioacchino Del Regno <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Val Packett <[email protected]> Date: Wed Dec 4 16:05:06 2024 -0300 arm64: dts: mediatek: mt8516: add i2c clock-div property [ Upstream commit eb72341fd92b7af510d236e5a8554d855ed38d3c ] Move the clock-div property from the pumpkin board dtsi to the SoC's since it belongs to the SoC itself and is required on other devices. Fixes: 5236347bde42 ("arm64: dts: mediatek: add dtsi for MT8516") Signed-off-by: Val Packett <[email protected]> Reviewed-by: AngeloGioacchino Del Regno <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: AngeloGioacchino Del Regno <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Val Packett <[email protected]> Date: Wed Dec 4 16:05:04 2024 -0300 arm64: dts: mediatek: mt8516: fix GICv2 range [ Upstream commit e3ee31e4409f051c021a30122f3c470f093a7386 ] On the MT8167 which is based on the MT8516 DTS, the following error was appearing on boot, breaking interrupt operation: GICv2 detected, but range too small and irqchip.gicv2_force_probe not set Similar to what's been proposed for MT7622 which has the same issue, fix by using the range reported by force_probe. Link: https://lore.kernel.org/all/YmhNSLgp%[email protected]/ Fixes: 5236347bde42 ("arm64: dts: mediatek: add dtsi for MT8516") Signed-off-by: Val Packett <[email protected]> Reviewed-by: AngeloGioacchino Del Regno <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: AngeloGioacchino Del Regno <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Val Packett <[email protected]> Date: Wed Dec 4 16:05:05 2024 -0300 arm64: dts: mediatek: mt8516: fix wdt irq type [ Upstream commit 03a80442030e7147391738fb6cbe5fa0b3b91bb1 ] The GICv2 does not support EDGE_FALLING interrupts, so the watchdog would refuse to attach due to a failing check coming from the GIC driver. Fixes: 5236347bde42 ("arm64: dts: mediatek: add dtsi for MT8516") Signed-off-by: Val Packett <[email protected]> Reviewed-by: AngeloGioacchino Del Regno <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: AngeloGioacchino Del Regno <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Val Packett <[email protected]> Date: Wed Dec 4 16:05:07 2024 -0300 arm64: dts: mediatek: mt8516: reserve 192 KiB for TF-A [ Upstream commit 2561c7d5d497b988deccc36fe5eac7fd50b937f8 ] The Android DTB for the related MT8167 reserves 0x30000. This is likely correct for MT8516 Android devices as well, and there's never any harm in reserving 64KiB more. Fixes: 5236347bde42 ("arm64: dts: mediatek: add dtsi for MT8516") Signed-off-by: Val Packett <[email protected]> Reviewed-by: AngeloGioacchino Del Regno <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: AngeloGioacchino Del Regno <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Hsin-Yi Wang <[email protected]> Date: Wed Nov 13 16:16:53 2024 +0800 arm64: dts: mt8183: set DMIC one-wire mode on Damu [ Upstream commit 6c379e8b984815fc8f876e4bc78c4d563f13ddae ] Sets DMIC one-wire mode on Damu. Fixes: cabc71b08eb5 ("arm64: dts: mt8183: Add kukui-jacuzzi-damu board") Signed-off-by: Hsin-Yi Wang <[email protected]> Reviewed-by: AngeloGioacchino Del Regno <[email protected]> Signed-off-by: Hsin-Te Yuan <[email protected]> Reviewed-by: Matthias Brugger <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: AngeloGioacchino Del Regno <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Dmitry Baryshkov <[email protected]> Date: Tue Dec 24 12:17:00 2024 +0200 arm64: dts: qcom: msm8916: correct sleep clock frequency [ Upstream commit f088b921890cef28862913e5627bb2e2b5f82125 ] The MSM8916 platform uses PM8916 to provide sleep clock. According to the documentation, that clock has 32.7645 kHz frequency. Correct the sleep clock definition. Fixes: f4fb6aeafaaa ("arm64: dts: qcom: msm8916: Add fixed rate on-board oscillators") Signed-off-by: Dmitry Baryshkov <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bjorn Andersson <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Dmitry Baryshkov <[email protected]> Date: Tue Dec 24 12:17:01 2024 +0200 arm64: dts: qcom: msm8939: correct sleep clock frequency [ Upstream commit 5c775f586cde4fca3c5591c43b6dc8b243bc304c ] The MSM8939 platform uses PM8916 to provide sleep clock. According to the documentation, that clock has 32.7645 kHz frequency. Correct the sleep clock definition. Fixes: 61550c6c156c ("arm64: dts: qcom: Add msm8939 SoC") Signed-off-by: Dmitry Baryshkov <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bjorn Andersson <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Dmitry Baryshkov <[email protected]> Date: Tue Dec 24 12:17:02 2024 +0200 arm64: dts: qcom: msm8994: correct sleep clock frequency [ Upstream commit a4148d869d47d8c86da0291dd95d411a5ebe90c8 ] The MSM8994 platform uses PM8994/6 to provide sleep clock. According to the documentation, that clock has 32.7645 kHz frequency. Correct the sleep clock definition. Fixes: feeaf56ac78d ("arm64: dts: msm8994 SoC and Huawei Angler (Nexus 6P) support") Signed-off-by: Dmitry Baryshkov <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bjorn Andersson <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Konrad Dybcio <[email protected]> Date: Fri Nov 29 23:12:48 2024 +0100 arm64: dts: qcom: msm8994: Describe USB interrupts [ Upstream commit c910544d2234709660d60f80345c285616e73b1c ] Previously the interrupt lanes were not described, fix that. Fixes: d9be0bc95f25 ("arm64: dts: qcom: msm8994: Add USB support") Signed-off-by: Konrad Dybcio <[email protected]> Tested-by: Petr Vorel <[email protected]> Link: https://lore.kernel.org/r/20241129-topic-qcom_usb_dtb_fixup-v1-4-cba24120c058@oss.qualcomm.com Signed-off-by: Bjorn Andersson <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Marek Vasut <[email protected]> Date: Sun Oct 6 04:19:48 2024 +0200 arm64: dts: qcom: msm8996-xiaomi-gemini: Fix LP5562 LED1 reg property [ Upstream commit 02e784c5023232c48c6ec79b52ac8929d4e4db34 ] The LP5562 led@1 reg property should likely be set to 1 to match the unit. Fix it. Fixes: 4ac46b3682c5 ("arm64: dts: qcom: msm8996: xiaomi-gemini: Add support for Xiaomi Mi 5") Signed-off-by: Marek Vasut <[email protected]> Reviewed-by: Dmitry Baryshkov <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bjorn Andersson <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Konrad Dybcio <[email protected]> Date: Fri Nov 29 23:12:47 2024 +0100 arm64: dts: qcom: msm8996: Fix up USB3 interrupts [ Upstream commit 9cb9c9f4e1380da317a056afd26d66a835c5796c ] Add the missing interrupt lines and fix qusb2_phy being an impostor of hs_phy_irq. This happens to also fix warnings such as: usb@6af8800: interrupt-names: ['hs_phy_irq', 'ss_phy_irq'] is too short Fixes: 4753492de9df ("arm64: dts: qcom: msm8996: Add usb3 interrupts") Signed-off-by: Konrad Dybcio <[email protected]> Link: https://lore.kernel.org/r/20241129-topic-qcom_usb_dtb_fixup-v1-3-cba24120c058@oss.qualcomm.com Signed-off-by: Bjorn Andersson <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Dmitry Baryshkov <[email protected]> Date: Tue Dec 24 12:17:04 2024 +0200 arm64: dts: qcom: q[dr]u1000: correct sleep clock frequency [ Upstream commit 5546604e034b6c383b65676ff8615b346897eccd ] The Q[DR]U1000 platforms use PM8150 to provide sleep clock. According to the documentation, that clock has 32.7645 kHz frequency. Correct the sleep clock definition. Fixes: d1f2cfe2f669 ("arm64: dts: qcom: Add base QDU1000/QRU1000 IDP DTs") Signed-off-by: Dmitry Baryshkov <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bjorn Andersson <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Neil Armstrong <[email protected]> Date: Mon Dec 30 13:44:44 2024 +0100 arm64: dts: qcom: qcm6490-shift-otter: remove invalid orientation-switch [ Upstream commit abb00f0fbf31d71b9f725e58d6a29634175f28a8 ] The orientation-switch property is not documented in the PHY bindings, remove it. This fixes: qcm6490-shift-otter.dts: phy@88e3000: 'orientation-switch' does not match any of the regexes: 'pinctrl-[0-9]+' from schema $id: http://devicetree.org/schemas/phy/qcom,usb-snps-femto-v2.yaml# Reviewed-by: Dmitry Baryshkov <[email protected]> Signed-off-by: Neil Armstrong <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bjorn Andersson <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Dmitry Baryshkov <[email protected]> Date: Tue Dec 24 12:17:03 2024 +0200 arm64: dts: qcom: qcs404: correct sleep clock frequency [ Upstream commit 1473ff0b69de68b23ce9874548cdabc64d72725e ] The QCS40x platforms use PMS405 to provide sleep clock. According to the documentation, that clock has 32.7645 kHz frequency. Correct the sleep clock definition. Fixes: 9181bb939984 ("arm64: dts: qcom: Add SDX75 platform and IDP board support") Signed-off-by: Dmitry Baryshkov <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bjorn Andersson <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Dmitry Baryshkov <[email protected]> Date: Tue Dec 24 12:17:05 2024 +0200 arm64: dts: qcom: qrb4210-rb2: correct sleep clock frequency [ Upstream commit 298192f365a343d84e9d2755e47bebebf0cfb82e ] Qualcomm RB2 board uses PM6125 to provide sleep clock. According to the documentation, that clock has 32.7645 kHz frequency. Correct the sleep clock definition. Fixes: 8d58a8c0d930 ("arm64: dts: qcom: Add base qrb4210-rb2 board dts") Signed-off-by: Dmitry Baryshkov <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bjorn Andersson <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Maulik Shah <[email protected]> Date: Tue Nov 12 16:31:51 2024 +0530 arm64: dts: qcom: sa8775p: Add CPUs to psci power domain [ Upstream commit 736f50489e08ba7329a9e828c35a2358968dacf0 ] Commit 4f79d0deae37 ("arm64: dts: qcom: sa8775p: add CPU idle states") already added cpu and cluster idle-states but have not added CPU devices to psci power domain without which idle states do not get detected. Add CPUs to psci power domain. Fixes: 4f79d0deae37 ("arm64: dts: qcom: sa8775p: add CPU idle states") Signed-off-by: Maulik Shah <[email protected]> Reviewed-by: Bartosz Golaszewski <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bjorn Andersson <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Taniya Das <[email protected]> Date: Fri Oct 25 14:22:53 2024 +0530 arm64: dts: qcom: sa8775p: Update sleep_clk frequency [ Upstream commit 30f7dfd2c4899630becf477447e8bbe92683d2c6 ] Fix the sleep_clk frequency is 32000 on SA8775P. Fixes: 603f96d4c9d0 ("arm64: dts: qcom: add initial support for qcom sa8775p-ride") Reviewed-by: Konrad Dybcio <[email protected]> Signed-off-by: Taniya Das <[email protected]> Link: https://lore.kernel.org/r/20241025-sa8775p-mm-v4-resend-patches-v6-1-329a2cac09ae@quicinc.com Signed-off-by: Bjorn Andersson <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Konrad Dybcio <[email protected]> Date: Fri Nov 8 22:41:18 2024 +0100 arm64: dts: qcom: sa8775p: Use a SoC-specific compatible for GPI DMA [ Upstream commit a8d18df5a5a114f948a3526537de2de276c9fa7d ] The commit adding these nodes did not use a SoC-specific node, fix that to comply with bindings guidelines. Fixes: 34d17ccb5db8 ("arm64: dts: qcom: sa8775p: Add GPI configuration") Signed-off-by: Konrad Dybcio <[email protected]> Reviewed-by: Dmitry Baryshkov <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bjorn Andersson <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Konrad Dybcio <[email protected]> Date: Thu Nov 7 22:14:23 2024 +0100 arm64: dts: qcom: sa8775p: Use valid node names for GPI DMAs [ Upstream commit 86348c7587f556d3f0a3f117c3f5b91a69c39df6 ] As pointed out by Intel's robot, the node name doesn't adhere to dt-bindings. Fix errors like this one: qcs9100-ride.dtb: qcom,gpi-dma@800000: $nodename:0: 'qcom,gpi-dma@800000' does not match '^dma-controller(@.*)?$' Fixes: 34d17ccb5db8 ("arm64: dts: qcom: sa8775p: Add GPI configuration") Reported-by: kernel test robot <[email protected]> Closes: https://lore.kernel.org/oe-kbuild-all/[email protected]/ Signed-off-by: Konrad Dybcio <[email protected]> Reviewed-by: Dmitry Baryshkov <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bjorn Andersson <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Neil Armstrong <[email protected]> Date: Mon Dec 30 13:44:47 2024 +0100 arm64: dts: qcom: sc7180-trogdor-pompom: rename 5v-choke thermal zone [ Upstream commit 9180b38d706c29ed212181a77999c35ae9ff6879 ] Rename the 5v-choke thermal zone to satisfy the bindings. This fixes: sc7180-trogdor-pompom-r2-lte.dts: thermal-zones: '5v-choke-thermal' does not match any of the regexes: '^[a-zA-Z][a-zA-Z0-9\\-]{1,10}-thermal$', 'pinctrl-[0-9]+' from schema $id: http://devicetree.org/schemas/thermal/thermal-zones.yaml# Reviewed-by: Douglas Anderson <[email protected]> Reviewed-by: Dmitry Baryshkov <[email protected]> Signed-off-by: Neil Armstrong <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bjorn Andersson <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Neil Armstrong <[email protected]> Date: Mon Dec 30 13:44:46 2024 +0100 arm64: dts: qcom: sc7180-trogdor-quackingstick: add missing avee-supply [ Upstream commit aa09de104d421e7ff8d8cde9af98568ce62a002c ] The bindings requires the avee-supply, use the same regulator as the avdd (positive voltage) which would also provide the negative voltage by definition. The fixes: sc7180-trogdor-quackingstick-r0.dts: panel@0: 'avee-supply' is a required property from schema $id: http://devicetree.org/schemas/display/panel/boe,tv101wum-nl6.yaml# Reviewed-by: Douglas Anderson <[email protected]> Signed-off-by: Neil Armstrong <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bjorn Andersson <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Neil Armstrong <[email protected]> Date: Mon Dec 30 13:44:48 2024 +0100 arm64: dts: qcom: sc7180: fix psci power domain node names commit 092febd32a99800902f865ed86b83314faa9c7e4 upstream. Rename the psci power domain node names to match the bindings. This Fixes: sc7180-acer-aspire1.dts: psci: 'cpu-cluster0', 'cpu0', 'cpu1', 'cpu2', 'cpu3', 'cpu4', 'cpu5', 'cpu6', 'cpu7' do not match any of the regexes: '^power-domain-', 'pinctrl-[0-9]+' Reviewed-by: Douglas Anderson <[email protected]> Reviewed-by: Dmitry Baryshkov <[email protected]> Signed-off-by: Neil Armstrong <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bjorn Andersson <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Dmitry Baryshkov <[email protected]> Date: Tue Dec 24 12:17:07 2024 +0200 arm64: dts: qcom: sc7280: correct sleep clock frequency [ Upstream commit f6ccdca14eac545320ab03d6ca91ca343e7372e5 ] The SC7280 platform uses PMK8350 to provide sleep clock. According to the documentation, that clock has 32.7645 kHz frequency. Correct the sleep clock definition. Fixes: 7a1f4e7f740d ("arm64: dts: qcom: sc7280: Add basic dts/dtsi files for sc7280 soc") Signed-off-by: Dmitry Baryshkov <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bjorn Andersson <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Vladimir Zapolskiy <[email protected]> Date: Wed Nov 27 14:29:48 2024 +0200 arm64: dts: qcom: sc8280xp: Fix interrupt type of camss interrupts [ Upstream commit b08535cd41c27b4f32319b5bff754c9da6dc2205 ] Qualcomm IP catalog says that all CAMSS interrupts are edge rising, fix it in the CAMSS device tree node for sc8280xp SoC. Fixes: 5994dd60753e ("arm64: dts: qcom: sc8280xp: camss: Add CAMSS block definition") Signed-off-by: Vladimir Zapolskiy <[email protected]> Reviewed-by: Bryan O'Donoghue <[email protected]> Tested-by: Johan Hovold <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bjorn Andersson <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Konrad Dybcio <[email protected]> Date: Thu Dec 12 23:19:37 2024 +0100 arm64: dts: qcom: sc8280xp: Fix up remoteproc register space sizes [ Upstream commit 7ec7e327286182c65d0b5b81dff498d620fe9e8c ] Make sure the remoteproc reg ranges reflect the entire register space they refer to. Since they're unused by the driver, there's no functional change. Fixes: 152d1faf1e2f ("arm64: dts: qcom: add SC8280XP platform") Signed-off-by: Konrad Dybcio <[email protected]> Reviewed-by: Bryan O'Donoghue <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bjorn Andersson <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Neil Armstrong <[email protected]> Date: Mon Dec 30 13:44:45 2024 +0100 arm64: dts: qcom: sdm845-db845c-navigation-mezzanine: remove disabled ov7251 camera [ Upstream commit 80b47f14d5433068dd6738c9e6e17ff6648bae41 ] The ov7251node has bindings check errors in the endpoint, and the camera node was disabled since the beginning. Even when switching the node to okay, the endpoint description to the csiphy is missing along with the csiphy parameters. Drop the ov7251 camera entirely until it's properly described. This obviously fixes: sdm845-db845c-navigation-mezzanine.dtso: camera@60: port:endpoint:data-lanes: [0, 1] is too long from schema $id: http://devicetree.org/schemas/media/i2c/ovti,ov7251.yaml# Reviewed-by: Konrad Dybcio <[email protected]> Signed-off-by: Neil Armstrong <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bjorn Andersson <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Vladimir Zapolskiy <[email protected]> Date: Wed Nov 27 14:29:49 2024 +0200 arm64: dts: qcom: sdm845: Fix interrupt types of camss interrupts [ Upstream commit cb96722b728e81ad97f5b5b20dea64cd294a5452 ] Qualcomm IP catalog says that all CAMSS interrupts is edge rising, fix it in the CAMSS device tree node for sdm845 SoC. Fixes: d48a6698a6b7 ("arm64: dts: qcom: sdm845: Add CAMSS ISP node") Signed-off-by: Vladimir Zapolskiy <[email protected]> Reviewed-by: Bryan O'Donoghue <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bjorn Andersson <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Dmitry Baryshkov <[email protected]> Date: Tue Dec 24 12:17:08 2024 +0200 arm64: dts: qcom: sdx75: correct sleep clock frequency [ Upstream commit b8021da9ddc65fa041e12ea1e0ff2dfce5c926eb ] The SDX75 platform uses PMK8550 to provide sleep clock. According to the documentation, that clock has 32.7645 kHz frequency. Correct the sleep clock definition. Fixes: 9181bb939984 ("arm64: dts: qcom: Add SDX75 platform and IDP board support") Signed-off-by: Dmitry Baryshkov <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bjorn Andersson <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Dmitry Baryshkov <[email protected]> Date: Tue Dec 24 12:17:09 2024 +0200 arm64: dts: qcom: sm4450: correct sleep clock frequency [ Upstream commit 158e67cf3619dbb5b9914bb364889041f4b90eea ] The SM4450 platform uses PM4450 to provide sleep clock. According to the documentation, that clock has 32.7645 kHz frequency. Correct the sleep clock definition. Fixes: 7a1fd03e7410 ("arm64: dts: qcom: Adds base SM4450 DTSI") Signed-off-by: Dmitry Baryshkov <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bjorn Andersson <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Dmitry Baryshkov <[email protected]> Date: Tue Dec 24 12:17:10 2024 +0200 arm64: dts: qcom: sm6125: correct sleep clock frequency [ Upstream commit b3c547e1507862f0e4d46432b665c5c6e61e14d6 ] The SM6125 platform uses PM6125 to provide sleep clock. According to the documentation, that clock has 32.7645 kHz frequency. Correct the sleep clock definition. Fixes: cff4bbaf2a2d ("arm64: dts: qcom: Add support for SM6125") Signed-off-by: Dmitry Baryshkov <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bjorn Andersson <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Dmitry Baryshkov <[email protected]> Date: Tue Dec 24 12:17:11 2024 +0200 arm64: dts: qcom: sm6375: correct sleep clock frequency [ Upstream commit 223382c94f1f07c475d39713e4c058401480b441 ] The SM6375 platform uses PM6125 to provide sleep clock. According to the documentation, that clock has 32.7645 kHz frequency. Correct the sleep clock definition. Fixes: 59d34ca97f91 ("arm64: dts: qcom: Add initial device tree for SM6375") Signed-off-by: Dmitry Baryshkov <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bjorn Andersson <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Luca Weiss <[email protected]> Date: Fri Dec 20 09:55:01 2024 +0100 arm64: dts: qcom: sm7225-fairphone-fp4: Drop extra qcom,msm-id value [ Upstream commit 7fb88e0d4dc1a40a29d49b603faa1484334c60f3 ] The ID 434 is for SM6350 while 459 is for SM7225. Fairphone 4 is only SM7225, so drop the unused 434 entry. Fixes: 4cbea668767d ("arm64: dts: qcom: sm7225: Add device tree for Fairphone 4") Signed-off-by: Luca Weiss <[email protected]> Reviewed-by: Konrad Dybcio <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bjorn Andersson <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Neil Armstrong <[email protected]> Date: Mon Dec 30 13:44:49 2024 +0100 arm64: dts: qcom: sm8150-microsoft-surface-duo: fix typos in da7280 properties [ Upstream commit 9875adffb87da5c40f4013e55104f5e2fc071c2a ] The dlg,const-op-mode & dlg,periodic-op-mode were mis-names with twice the "dlg," prefix, drop one to match the bindings. This fixes: sm8150-microsoft-surface-duo.dtb: da7280@4a: 'dlg,const-op-mode' is a required property from schema $id: http://devicetree.org/schemas/input/dlg,da7280.yaml# m8150-microsoft-surface-duo.dtb: da7280@4a: 'dlg,periodic-op-mode' is a required property from schema $id: http://devicetree.org/schemas/input/dlg,da7280.yaml# sm8150-microsoft-surface-duo.dtb: da7280@4a: 'dlg,dlg,const-op-mode', 'dlg,dlg,periodic-op-mode' do not match any of the regexes: 'pinctrl-[0-9]+' from schema $id: http://devicetree.org/schemas/input/dlg,da7280.yaml# With the dlg,da7280.yaml converted from dlg,da7280.txt at [1]. [1] https://lore.kernel.org/all/[email protected]/ Fixes: d1f781db47a8 ("arm64: dts: qcom: add initial device-tree for Microsoft Surface Duo") Reviewed-by: Dmitry Baryshkov <[email protected]> Signed-off-by: Neil Armstrong <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bjorn Andersson <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Dmitry Baryshkov <[email protected]> Date: Tue Dec 24 12:17:12 2024 +0200 arm64: dts: qcom: sm8250: correct sleep clock frequency [ Upstream commit 75420e437eed69fa95d1d7c339dad86dea35319a ] The SM8250 platform uses PM8150 to provide sleep clock. According to the documentation, that clock has 32.7645 kHz frequency. Correct the sleep clock definition. Fixes: 9ff8b0591fcf ("arm64: dts: qcom: sm8250: use the right clock-freqency for sleep-clk") Signed-off-by: Dmitry Baryshkov <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bjorn Andersson <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Vladimir Zapolskiy <[email protected]> Date: Wed Nov 27 14:29:50 2024 +0200 arm64: dts: qcom: sm8250: Fix interrupt types of camss interrupts [ Upstream commit 6c7bba42ebc3da56e64d4aec4c4a31dd454e05fd ] Qualcomm IP catalog says that all CAMSS interrupts is edge rising, fix it in the CAMSS device tree node for sm8250 SoC. Fixes: 30325603b910 ("arm64: dts: qcom: sm8250: camss: Add CAMSS block definition") Signed-off-by: Vladimir Zapolskiy <[email protected]> Reviewed-by: Bryan O'Donoghue <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bjorn Andersson <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Dmitry Baryshkov <[email protected]> Date: Tue Dec 24 12:17:13 2024 +0200 arm64: dts: qcom: sm8350: correct sleep clock frequency [ Upstream commit f4cc8c75cfc5d06084a31da2ff67e477565f0cae ] The SM8350 platform uses PMK8350 to provide sleep clock. According to the documentation, that clock has 32.7645 kHz frequency. Correct the sleep clock definition. Fixes: b7e8f433a673 ("arm64: dts: qcom: Add basic devicetree support for SM8350 SoC") Signed-off-by: Dmitry Baryshkov <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bjorn Andersson <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Dmitry Baryshkov <[email protected]> Date: Tue Dec 24 12:17:14 2024 +0200 arm64: dts: qcom: sm8450: correct sleep clock frequency [ Upstream commit c375ff3b887abf376607d4769c1114c5e3b6ea72 ] The SM8450 platform uses PMK8350 to provide sleep clock. According to the documentation, that clock has 32.7645 kHz frequency. Correct the sleep clock definition. Fixes: 5188049c9b36 ("arm64: dts: qcom: Add base SM8450 DTSI") Signed-off-by: Dmitry Baryshkov <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bjorn Andersson <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Dmitry Baryshkov <[email protected]> Date: Tue Dec 24 12:17:15 2024 +0200 arm64: dts: qcom: sm8550: correct sleep clock frequency [ Upstream commit e59334a088c3e722c0a287d4616af997f46c985e ] The SM8550 platform uses PMK8550 to provide sleep clock. According to the documentation, that clock has 32.7645 kHz frequency. Correct the sleep clock definition. Fixes: 0b12da4e28d8 ("arm64: dts: qcom: add base AIM300 dtsi") Fixes: b5e25ded2721 ("arm64: dts: qcom: sm8550: add support for the SM8550-HDK board") Fixes: 71342fb91eae ("arm64: dts: qcom: Add base SM8550 MTP dts") Fixes: d228efe88469 ("arm64: dts: qcom: sm8550-qrd: add QRD8550") Fixes: ba2c082a401f ("arm64: dts: qcom: sm8550: Add support for Samsung Galaxy Z Fold5") Fixes: 39c596304e44 ("arm64: dts: qcom: Add SM8550 Xperia 1 V") Signed-off-by: Dmitry Baryshkov <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bjorn Andersson <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Dmitry Baryshkov <[email protected]> Date: Tue Dec 24 12:17:16 2024 +0200 arm64: dts: qcom: sm8650: correct sleep clock frequency [ Upstream commit 448db0ba6ad2aafee2cbd91b491246749f6a6abc ] The SM8650 platform uses PMK8550 to provide sleep clock. According to the documentation, that clock has 32.7645 kHz frequency. Correct the sleep clock definition. Fixes: 6fbdb3c1fac7 ("arm64: dts: qcom: sm8650: add initial SM8650 MTP dts") Fixes: a834911d50c1 ("arm64: dts: qcom: sm8650: add initial SM8650 QRD dts") Fixes: 01061441029e ("arm64: dts: qcom: sm8650: add support for the SM8650-HDK board") Signed-off-by: Dmitry Baryshkov <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bjorn Andersson <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Krzysztof Kozlowski <[email protected]> Date: Mon Nov 4 15:42:04 2024 +0100 arm64: dts: qcom: sm8650: Fix CDSP context banks unit addresses [ Upstream commit ff2b76ae689b71e2d7a2e70bfd8d71537c39164d ] There is a mismatch between 'reg' property and unit address for last there CDSP compute context banks. Current values were taken as-is from downstream source. Considering that 'reg' is used by Linux driver as SID of context bank and that least significant bytes of IOMMU value match the 'reg', assume the unit-address is wrong and needs fixing. This also won't have any practical impact, except adhering to Devicetree spec. Fixes: dae8cdb0a9e1 ("arm64: dts: qcom: sm8650: Add three missing fastrpc-compute-cb nodes") Signed-off-by: Krzysztof Kozlowski <[email protected]> Reviewed-by: Konrad Dybcio <[email protected]> Reviewed-by: Neil Armstrong <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bjorn Andersson <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Joel Stanley <[email protected]> Date: Wed Jan 8 23:14:59 2025 +1030 arm64: dts: qcom: x1e80100-romulus: Update firmware nodes [ Upstream commit 983833061d9599a534e44fd6d335080d1a0ba985 ] Other x1e machines use _dtbs.elf for these firmwares, which matches the filenames shipped by Windows. Fixes: 09d77be56093 ("arm64: dts: qcom: Add support for X1-based Surface Laptop 7 devices") Signed-off-by: Joel Stanley <[email protected]> Reviewed-by: Konrad Dybcio <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bjorn Andersson <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Dmitry Baryshkov <[email protected]> Date: Tue Dec 24 12:17:17 2024 +0200 arm64: dts: qcom: x1e80100: correct sleep clock frequency [ Upstream commit 67e25a3e12d128336114a5d1572e055a8bd33129 ] The X1E80100 platform uses PMK8550 to provide sleep clock. According to the documentation, that clock has 32.7645 kHz frequency. Correct the sleep clock definition. Fixes: af16b00578a7 ("arm64: dts: qcom: Add base X1E80100 dtsi and the QCP dts") Signed-off-by: Dmitry Baryshkov <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bjorn Andersson <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Claudiu Beznea <[email protected]> Date: Fri Nov 15 15:43:58 2024 +0200 arm64: dts: renesas: rzg3s-smarc: Fix the debug serial alias [ Upstream commit 08811b984f5af8eeda4fb157894fe9bf230ec1e1 ] The debug serial of the RZ/G3S is SCIF0 which is routed on the Renesas RZ SMARC Carrier II board on the SER3_UART. Use serial3 alias for it for better hardware description. Along with it, the chosen properties were moved to the device tree corresponding to the RZ SMARC Carrier II board. Fixes: adb4f0c5699c ("arm64: dts: renesas: Add initial support for RZ/G3S SMARC SoM") Fixes: d1ae4200bb26 ("arm64: dts: renesas: Add initial device tree for RZ SMARC Carrier-II Board") Signed-off-by: Claudiu Beznea <[email protected]> Reviewed-by: Geert Uytterhoeven <[email protected]> Link: https://lore.kernel.org/[email protected] Signed-off-by: Geert Uytterhoeven <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Michael Riesch <[email protected]> Date: Wed Dec 18 11:43:11 2024 +0100 arm64: dts: rockchip: fix num-channels property of wolfvision pf5 mic [ Upstream commit 11d07966c83f5eccf6b927cb32862aef58488e23 ] The Rockchip RK3568 PDM block always considers stereo inputs. Therefore, the number of channels must be always an even number, even if a single mono microphone is attached. Fixes: 0be29f76633a ("arm64: dts: rockchip: add wolfvision pf5 mainboard") Signed-off-by: Michael Riesch <[email protected]> Link: https://lore.kernel.org/r/20241218-b4-wolfvision-pf5-update-v1-1-1d1959858708@wolfvision.net Signed-off-by: Heiko Stuebner <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Jagan Teki <[email protected]> Date: Sat Dec 21 20:47:58 2024 +0530 arm64: dts: rockchip: Fix PCIe3 handling for Edgeble-6TOPS Modules [ Upstream commit e2ee8a440869281620fbcacdca6e13cbeebcc1be ] The Edgeble 6TOPS modules has configured the PCIe3.0 with - 2 lanes on Port1 of pcie3x2 controller for M.2 M-Key - 2 lanes on Port0 of pcie3x4 controller for B and E-Key The, current DT uses opposite controller nodes that indeed uses incorrect reset, regulator nodes. The configuration also uses refclk oscillator that need to enable explicitly in DT to avoid the probe hang on while reading DBI. So, this patch fixes all these essential issues and make this PCIe work properly. Issues fixed are, - Fix the associate controller nodes for M and B, E-Key - Fix the reset gpio handlings - Fix the regulator handlings and naming convensions - Support pcie_refclk oscillator Fixes: 92eaee21abbd ("arm64: dts: rockchip: Add Edgeble NCM6A-IO M.2 B-Key, E-Key") Fixes: 5d85d4c7e03b ("arm64: dts: rockchip: Add Edgeble NCM6A-IO M.2 M-Key") Reported-by: Mitchell Ma <[email protected]> Co-developed-by: Mitchell Ma <[email protected]> Signed-off-by: Jagan Teki <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Heiko Stuebner <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Jonas Karlman <[email protected]> Date: Tue Nov 19 23:08:36 2024 +0000 arm64: dts: rockchip: Fix sdmmc access on rk3308-rock-s0 v1.1 boards [ Upstream commit 26c100232b09ced0857306ac9831a4fa9c9aa231 ] BootROM leave GPIO4_D6 configured as SDMMC_PWREN function and DW MCI driver set PRWEN high on MMC_POWER_UP and low on MMC_POWER_OFF. Similarly U-Boot also set PRWEN high before accessing mmc. However, HW revision prior to v1.2 must pull GPIO4_D6 low to access sdmmc. For HW revision v1.2 the state of GPIO4_D6 has no impact. Model an always-on active low fixed regulator using GPIO4_D6 to fix use of sdmmc on older HW revisions of the board. Fixes: adeb5d2a4ba4 ("arm64: dts: rockchip: Add Radxa ROCK S0") Signed-off-by: Jonas Karlman <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Heiko Stuebner <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Bryan Brattlof <[email protected]> Date: Tue Dec 10 14:59:24 2024 -0600 arm64: dts: ti: k3-am62: Remove duplicate GICR reg [ Upstream commit 72c691d77ea5d0c4636fd3e9f0ad80d813c7d1a7 ] The GIC Redistributor control register range is mapped twice. Remove the extra entry from the reg range. Fixes: f1d17330a5be ("arm64: dts: ti: Introduce base support for AM62x SoC") Reported-by: Bin Liu <[email protected]> Signed-off-by: Bryan Brattlof <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Nishanth Menon <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Bryan Brattlof <[email protected]> Date: Tue Dec 10 14:59:25 2024 -0600 arm64: dts: ti: k3-am62a: Remove duplicate GICR reg [ Upstream commit 6f0232577e260cdbc25508e27bb0b75ade7e7ebc ] The GIC Redistributor control range is mapped twice. Remove the extra entry from the reg range. Fixes: 5fc6b1b62639 ("arm64: dts: ti: Introduce AM62A7 family of SoCs") Reported-by: Bin Liu <[email protected]> Signed-off-by: Bryan Brattlof <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Nishanth Menon <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Josua Mayer <[email protected]> Date: Wed Jan 1 13:30:22 2025 +0100 arm64: dts: ti: k3-am642-hummingboard-t: Convert overlay to board dts [ Upstream commit e2b69180431968250bf3c0c581155f1b37d057c1 ] SolidRun HummingBoard-T has two options for M.2 connector, supporting either PCI-E or USB-3.1 Gen 1 - depending on configuration of a mux on the serdes lane. The required configurations in device-tree were modeled as overlays. The USB-3.1 overlay uses /delete-property/ to unset a boolean property on the usb controller limiting it to USB-2.0 by default. Overlays can not delete a property from the base dtb, therefore this overlay is at this time useless. Convert both overlays into full dts by including the base board dts. While the pcie overlay was functional, both are converted for a consistent user experience when selecting between the two mutually exclusive configurations. Reported-by: Geert Uytterhoeven <[email protected]> Closes: https://lore.kernel.org/linux-devicetree/CAMuHMdXTgpTnJ9U7egC2XjFXXNZ5uiY1O+WxNd6LPJW5Rs5KTw@mail.gmail.com Fixes: bbef42084cc1 ("arm64: dts: ti: hummingboard-t: add overlays for m.2 pci-e and usb-3") Signed-off-by: Josua Mayer <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Nishanth Menon <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Siddharth Vadapalli <[email protected]> Date: Thu Dec 5 16:20:33 2024 +0530 arm64: dts: ti: Makefile: Fix typo "k3-j7200-evm-pcie1-ep.dtbo" [ Upstream commit a7543eaeb31544b9c3f6248cac8189aa1480c0f5 ] The list of "dtbs" should contain the resultant "dtb" formed by applying the "dtbo" overlay on the base "dtb", rather than the "dtbo" itself. Hence, change "k3-j7200-evm-pcie1-ep.dtbo" to "k3-j7200-evm-pcie1-ep.dtb" in the list of "dtbs". Fixes: f43ec89bbc83 ("arm64: dts: ti: k3-j7200-evm: Add overlay for PCIE1 Endpoint Mode") Signed-off-by: Siddharth Vadapalli <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Nishanth Menon <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Akhil R <[email protected]> Date: Fri Dec 6 16:22:00 2024 +0530 arm64: tegra: Fix DMA ID for SPI2 [ Upstream commit 346bf459db26325c09ed841fdfd6678de1b1cb3a ] DMA ID for SPI2 is '16'. Update the incorrect value in the devicetree. Fixes: bb9667d8187b ("arm64: tegra: Add SPI device tree nodes for Tegra234") Signed-off-by: Akhil R <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Thierry Reding <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Nicolas Ferre <[email protected]> Date: Mon Nov 25 17:56:48 2024 +0100 ARM: at91: pm: change BU Power Switch to automatic mode [ Upstream commit 6fc5bdfa872b7da51b5507a1327a17c3db2fcf95 ] Change how the Backup Unit Power is configured and force the automatic/hardware mode. This change eliminates the need for software management of the power switch, ensuring it transitions to the backup power source before entering low power modes. This is done in the only location where this switch was configured. It's usually done in the bootloader. Previously, the loss of the VDDANA (or VDDIN33) power source was not automatically compensated by an alternative power source. This resulted in the loss of Backup Unit content, including Backup Self-refresh low power mode information, OTP emulation configuration, and boot configuration, for instance. Fixes: ac809e7879b1 ("ARM: at91: pm: switch backup area to vbat in backup mode") Signed-off-by: Nicolas Ferre <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Claudiu Beznea <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Ricky CX Wu <[email protected]> Date: Thu Oct 3 15:42:45 2024 +0800 ARM: dts: aspeed: yosemite4: Add required properties for IOE on fan boards [ Upstream commit c64ac96f8f8d957cdc6ec3c93dd9a6c4e6d78506 ] Add the required properties for IO expander on fan boards. Fixes: 2b8d94f4b4a4 ("ARM: dts: aspeed: yosemite4: add Facebook Yosemite 4 BMC") Signed-off-by: Ricky CX Wu <[email protected]> Signed-off-by: Delphine CC Chiu <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Andrew Jeffery <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Ricky CX Wu <[email protected]> Date: Thu Oct 3 15:42:46 2024 +0800 ARM: dts: aspeed: yosemite4: correct the compatible string for max31790 [ Upstream commit b1a1ecb669bfa763ee5e86a038d7c9363eee7548 ] Fix the compatible string for max31790 to match the binding document. Fixes: 2b8d94f4b4a4 ("ARM: dts: aspeed: yosemite4: add Facebook Yosemite 4 BMC") Signed-off-by: Ricky CX Wu <[email protected]> Signed-off-by: Delphine CC Chiu <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Andrew Jeffery <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Ricky CX Wu <[email protected]> Date: Fri Sep 27 16:52:13 2024 +0800 ARM: dts: aspeed: yosemite4: correct the compatible string of adm1272 [ Upstream commit ece3e20e3389ec8a32944ad44746ee379bf1d3eb ] Remove the space in the compatible string of adm1272 to match the pattern of compatible. Fixes: 2b8d94f4b4a4 ("ARM: dts: aspeed: yosemite4: add Facebook Yosemite 4 BMC") Signed-off-by: Ricky CX Wu <[email protected]> Signed-off-by: Delphine CC Chiu <[email protected]> Fixes: 2b8d94f4b4a4765d ("ARM: dts: aspeed: yosemite4: add Facebook Yosemite 4 BMC") Reviewed-by: Andrew Jeffery <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Andrew Jeffery <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Alexander Stein <[email protected]> Date: Fri Nov 8 14:49:21 2024 +0100 ARM: dts: imx7-tqma7: add missing vs-supply for LM75A (rev. 01xxx) [ Upstream commit 78e08cebfe41a99d12a3a79d3e3be913559182e2 ] Add missing supply for LM75. Fixes the kernel warning: lm75 0-0048: supply vs not found, using dummy regulator Fixes: c9d4affbe60a ("ARM: dts: imx: tqma7: add lm75a sensor (rev. 01xxx)") Signed-off-by: Alexander Stein <[email protected]> Reviewed-by: Markus Niebel <[email protected]> Reviewed-by: Bruno Thomsen <[email protected]> Signed-off-by: Shawn Guo <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Rafał Miłecki <[email protected]> Date: Mon Jun 17 11:46:33 2024 +0200 ARM: dts: mediatek: mt7623: fix IR nodename [ Upstream commit 90234cf9b37c57201a24b78c217a91a8af774109 ] Fix following validation error: arch/arm/boot/dts/mediatek/mt7623a-rfb-emmc.dtb: cir@10013000: $nodename:0: 'cir@10013000' does not match '^ir(-receiver)?(@[a-f0-9]+)?$' from schema $id: http://devicetree.org/schemas/media/mediatek,mt7622-cir.yaml# Fixes: 91044f38dae7 ("arm: dts: mt7623: add ir nodes to the mt7623.dtsi file") Cc: [email protected] Signed-off-by: Rafał Miłecki <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Matthias Brugger <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Cristian Birsan <[email protected]> Date: Tue Nov 19 18:01:07 2024 +0200 ARM: dts: microchip: sama5d27_wlsom1_ek: Add no-1-8-v property to sdmmc0 node [ Upstream commit 4d9e5965df04c0adf260c3009c55d5fe240f7286 ] Add no-1-8-v property to sdmmc0 node to keep VDDSDMMC power rail at 3.3V. This property will stop the LDO regulator from switching to 1.8V when the MMC core detects an UHS SD Card. VDDSDMMC power rail is used by all the SDMMC interface pins in GPIO mode (PA0 - PA13). On this board, PA10 is used as GPIO to enable the power switch controlling USB Vbus for the USB Host. The change is needed to fix the PA10 voltage level to 3.3V instead of 1.8V. Fixes: 5d4c3cfb63fe ("ARM: dts: at91: sama5d27_wlsom1: add SAMA5D27 wlsom1 and wlsom1-ek") Suggested-by: Mihai Sain <[email protected]> Signed-off-by: Cristian Birsan <[email protected]> Tested-by: Andrei Simion <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Claudiu Beznea <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Cristian Birsan <[email protected]> Date: Tue Nov 19 18:01:06 2024 +0200 ARM: dts: microchip: sama5d29_curiosity: Add no-1-8-v property to sdmmc0 node [ Upstream commit c21c23a0f2e9869676eff0d53fb89e151e14c873 ] Add no-1-8-v property to sdmmc0 node to keep VDDSDMMC power rail at 3.3V. This property will stop the LDO regulator from switching to 1.8V when the MMC core detects an UHS SD Card. VDDSDMMC power rail is used by all the SDMMC interface pins in GPIO mode (PA0 - PA13). On this board, PA6 is used as GPIO to enable the power switch controlling USB Vbus for the USB Host. The change is needed to fix the PA6 voltage level to 3.3V instead of 1.8V. Fixes: d85c4229e925 ("ARM: dts: at91: sama5d29_curiosity: Add device tree for sama5d29_curiosity board") Suggested-by: Mihai Sain <[email protected]> Signed-off-by: Cristian Birsan <[email protected]> Tested-by: Andrei Simion <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Claudiu Beznea <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Mamta Shukla <[email protected]> Date: Mon Oct 28 15:59:07 2024 +0100 arm: dts: socfpga: use reset-name "stmmaceth-ocp" instead of "ahb" [ Upstream commit 62a40a0d5634834790f7166ab592be247390d857 ] The ahb reset is deasserted in probe before first register access, while the stmmacheth-ocp reset needs to be asserted every time before changing the phy mode in Arria10[1]. Changed in Upstream to "ahb"(331085a423b arm64: dts: socfpga: change the reset-name of "stmmaceth-ocp" to "ahb" ).This change was intended for arm64 socfpga and it is not applicable to Arria10. Further with STMMAC-SELFTEST Driver enabled, ethtool test also FAILS. $ ethtool -t eth0 [ 322.946709] socfpga-dwmac ff800000.ethernet eth0: entered promiscuous mode [ 323.374558] socfpga-dwmac ff800000.ethernet eth0: left promiscuous mode The test result is FAIL The test extra info: 1. MAC Loopback 0 2. PHY Loopback -110 3. MMC Counters -110 4. EEE -95 5. Hash Filter MC 0 6. Perfect Filter UC -110 7. MC Filter -110 8. UC Filter 0 9. Flow Control -110 10. RSS -95 11. VLAN Filtering -95 12. VLAN Filtering (perf) -95 13. Double VLAN Filter -95 14. Double VLAN Filter (perf) -95 15. Flexible RX Parser -95 16. SA Insertion (desc) -95 17. SA Replacement (desc) -95 18. SA Insertion (reg) -95 19. SA Replacement (reg) -95 20. VLAN TX Insertion -95 21. SVLAN TX Insertion -95 22. L3 DA Filtering -95 23. L3 SA Filtering -95 24. L4 DA TCP Filtering -95 25. L4 SA TCP Filtering -95 26. L4 DA UDP Filtering -95 27. L4 SA UDP Filtering -95 28. ARP Offload -95 29. Jumbo Frame -110 30. Multichannel Jumbo -95 31. Split Header -95 32. TBS (ETF Scheduler) -95 [ 324.881327] socfpga-dwmac ff800000.ethernet eth0: Link is Down [ 327.995360] socfpga-dwmac ff800000.ethernet eth0: Link is Up - 1Gbps/Full - flow control rx/tx Link:[1] https://www.intel.com/content/www/us/en/docs/programmable/683711/21-2/functional-description-of-the-emac.html Fixes: 331085a423b ("arm64: dts: socfpga: change the reset-name of "stmmaceth-ocp" to "ahb") Signed-off-by: Mamta Shukla <[email protected]> Tested-by: Ahmad Fatoum <[email protected]> Reviewed-by: Ahmad Fatoum <[email protected]> Signed-off-by: Dinh Nguyen <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Marek Vasut <[email protected]> Date: Wed Nov 6 00:29:44 2024 +0100 ARM: dts: stm32: Deduplicate serial aliases and chosen node for STM32MP15xx DHCOM SoM [ Upstream commit 73317d327123472cb70e9ecbe050310f1d235e93 ] Deduplicate /aliases { serialN = ... } and /chosen node into stm32mp15xx-dhcom-som.dtsi , since the content is identical on all carrier boards using the STM32MP15xx DHCOM SoM. No functional change. Signed-off-by: Marek Vasut <[email protected]> Reviewed-by: Christoph Niedermaier <[email protected]> Signed-off-by: Alexandre Torgue <[email protected]> Stable-dep-of: 479b8227ffc4 ("ARM: dts: stm32: Swap USART3 and UART8 alias on STM32MP15xx DHCOM SoM") Signed-off-by: Sasha Levin <[email protected]>
Author: Arnaud Pouliquen <[email protected]> Date: Fri Dec 6 18:17:59 2024 +0100 ARM: dts: stm32: Fix IPCC EXTI declaration on stm32mp151 [ Upstream commit 4ea654242e0c75bdf6b45d3c619c5fdcb2e9312a ] The GIC IRQ type used for IPCC RX should be IRQ_TYPE_LEVEL_HIGH. Replacing the interrupt with the EXTI event changes the type to the numeric value 1, meaning IRQ_TYPE_EDGE_RISING. The issue is that EXTI event 61 is a direct event.The IRQ type of direct events is not used by EXTI and is propagated to the parent IRQ controller of EXTI, the GIC. Align the IRQ type to the value expected by the GIC by replacing the second parameter "1" with IRQ_TYPE_LEVEL_HIGH. Fixes: 7d9802bb0e34 ("ARM: dts: stm32: remove the IPCC "wakeup" IRQ on stm32mp151") Signed-off-by: Arnaud Pouliquen <[email protected]> Signed-off-by: Alexandre Torgue <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Marek Vasut <[email protected]> Date: Tue Nov 5 23:46:22 2024 +0100 ARM: dts: stm32: Increase CPU core voltage on STM32MP13xx DHCOR SoM [ Upstream commit a4422a9183278162093d4524fdf4b6bbd7dd8a28 ] The STM32MP13xx DHCOR DHSBC is populated with STM32MP13xx part capable of 1 GHz operation, increase the CPU core voltage to 1.35 V to make sure the SoC is stable even if the blobs unconditionally force the CPU to 1 GHz operation. It is not possible to make use of CPUfreq on the STM32MP13xx because the SCMI protocol 0x13 is not implemented by upstream OpTee-OS which is the SCMI provider. Fixes: 6331bddce649 ("ARM: dts: stm32: Add support for STM32MP13xx DHCOR SoM and DHSBC board") Signed-off-by: Marek Vasut <[email protected]> Signed-off-by: Alexandre Torgue <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Marek Vasut <[email protected]> Date: Wed Nov 6 00:40:41 2024 +0100 ARM: dts: stm32: Sort M24256E write-lockable page in DH STM32MP13xx DHCOR SoM DT [ Upstream commit 41e12cebd9c39c9ef7b6686f2c4e8bc451a386fc ] Move the M24256E write-lockable page subnode after RTC subnode in DH STM32MP13xx DHCOR SoM DT to keep the list of nodes sorted by I2C address. No functional change. Fixes: 3f2e7d167307 ("ARM: dts: stm32: Describe M24256E write-lockable page in DH STM32MP13xx DHCOR SoM DT") Signed-off-by: Marek Vasut <[email protected]> Signed-off-by: Alexandre Torgue <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Marek Vasut <[email protected]> Date: Fri Dec 13 23:36:25 2024 +0100 ARM: dts: stm32: Swap USART3 and UART8 alias on STM32MP15xx DHCOM SoM [ Upstream commit 479b8227ffc433929ba49200182b6383569f9615 ] Swap USART3 and UART8 aliases on STM32MP15xx DHCOM SoM, make sure UART8 is listed first, USART3 second, because the UART8 is labeled as UART2 on the SoM pinout, while USART3 is labeled as UART3 on the SoM pinout. Fixes: 34e0c7847dcf ("ARM: dts: stm32: Add DH Electronics DHCOM STM32MP1 SoM and PDK2 board") Signed-off-by: Marek Vasut <[email protected]> Reviewed-by: Christoph Niedermaier <[email protected]> Signed-off-by: Alexandre Torgue <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Aaro Koskinen <[email protected]> Date: Wed Jan 1 14:12:15 2025 +0200 ARM: omap1: Fix up the Retu IRQ on Nokia 770 [ Upstream commit ad455e48bba7f21bb5108406da0854cf8dede8ea ] The Retu IRQ is off by one, as a result the power button does not work. Fix it. Fixes: 084b6f216778 ("ARM: omap1: Fix up the Nokia 770 board device IRQs") Signed-off-by: Aaro Koskinen <[email protected]> Reviewed-by: Linus Walleij <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Kevin Hilman <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Daniel Baluta <[email protected]> Date: Mon Jan 27 10:34:22 2025 +0200 ASoC: amd: acp: Fix possible deadlock [ Upstream commit 3ff53862c322aa7bb115d84348d5a641dc905d87 ] On error path, function acp_i2s_set_tdm_slot returns without releasing the lock and this could result in potential deadlocks in the future. Error reported by sparse: sound/soc/amd/acp/acp-i2s.c:95:12: error: context imbalance in 'acp_i2s_set_tdm_slot' - different lock contexts for basic block Fixes: cd60dec8994c ("ASoC: amd: acp: Refactor TDM slots selction based on acp revision id") Signed-off-by: Daniel Baluta <[email protected]> Reviewed-by: Ranjani Sridharan <[email protected]> Reviewed-by: Pierre-Louis Bossart <[email protected]> Reviewed-by: Bard Liao <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Takashi Iwai <[email protected]> Date: Tue Dec 3 15:18:16 2024 +0100 ASoC: cs40l50: Use *-y for Makefile [ Upstream commit 3f0b8d367db5b0c0a0096b1c2ff02ec7c5c893b6 ] We should use *-y instead of *-objs in Makefile for the module objects. *-objs is used rather for host programs. Fixes: c486def5b3ba ("ASoC: cs40l50: Support I2S streaming to CS40L50") Signed-off-by: Takashi Iwai <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Takashi Iwai <[email protected]> Date: Tue Dec 3 15:18:19 2024 +0100 ASoC: cs42l84: Use *-y for Makefile [ Upstream commit 7916a8d8782d4e53fe0133c8dace20a925e0204e ] We should use *-y instead of *-objs in Makefile for the module objects. *-objs is used rather for host programs. Fixes: 250304a0fb34 ("ASoC: cs42l84: Add new codec driver") Signed-off-by: Takashi Iwai <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Claudiu Beznea <[email protected]> Date: Thu Jan 23 14:10:36 2025 +0200 ASoC: da7213: Initialize the mutex commit 4a32a38cb68f55ff9e100df348ddb3d4b3e50643 upstream. Initialize the struct da7213_priv::ctrl_lock mutex. Without it the following stack trace is displayed when rebooting and lockdep is enabled: DEBUG_LOCKS_WARN_ON(lock->magic != lock) WARNING: CPU: 0 PID: 180 at kernel/locking/mutex.c:564 __mutex_lock+0x254/0x4e4 CPU: 0 UID: 0 PID: 180 Comm: alsactl Not tainted 6.13.0-next-20250123-arm64-renesas-00002-g132083a22d3d #30 Hardware name: Renesas SMARC EVK version 2 based on r9a08g045s33 (DT) pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : __mutex_lock+0x254/0x4e4 lr : __mutex_lock+0x254/0x4e4 sp : ffff800082c13c00 x29: ffff800082c13c00 x28: ffff00001002b500 x27: 0000000000000000 x26: 0000000000000000 x25: ffff800080b30db4 x24: 0000000000000002 x23: ffff800082c13c70 x22: 0000ffffc2a68a70 x21: ffff000010348000 x20: 0000000000000000 x19: ffff00000be2e488 x18: 0000000000000000 x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 x14: 00000000000003c1 x13: 00000000000003c1 x12: 0000000000000000 x11: 0000000000000011 x10: 0000000000001420 x9 : ffff800082c13a70 x8 : 0000000000000001 x7 : ffff800082c13a50 x6 : ffff800082c139e0 x5 : ffff800082c14000 x4 : ffff800082c13a50 x3 : 0000000000000000 x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff00001002b500 Call trace: __mutex_lock+0x254/0x4e4 (P) mutex_lock_nested+0x20/0x28 da7213_volsw_locked_get+0x34/0x60 snd_ctl_elem_read+0xbc/0x114 snd_ctl_ioctl+0x878/0xa70 __arm64_sys_ioctl+0x94/0xc8 invoke_syscall+0x44/0x104 el0_svc_common.constprop.0+0xb4/0xd4 do_el0_svc+0x18/0x20 el0_svc+0x3c/0xf0 el0t_64_sync_handler+0xc0/0xc4 el0t_64_sync+0x154/0x158 irq event stamp: 7713 hardirqs last enabled at (7713): [<ffff800080170d94>] ktime_get_coarse_real_ts64+0xf0/0x10c hardirqs last disabled at (7712): [<ffff800080170d58>] ktime_get_coarse_real_ts64+0xb4/0x10c softirqs last enabled at (7550): [<ffff8000800179d4>] fpsimd_restore_current_state+0x30/0xb8 softirqs last disabled at (7548): [<ffff8000800179a8>] fpsimd_restore_current_state+0x4/0xb8 ---[ end trace 0000000000000000 ]--- Fixes: 64c3259b5f86 ("ASoC: da7213: Add new kcontrol for tonegen") Cc: [email protected] Signed-off-by: Claudiu Beznea <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Cezary Rojewski <[email protected]> Date: Thu Jan 9 13:22:04 2025 +0100 ASoC: Intel: avs: Do not readq() u32 registers [ Upstream commit bca0fa5f6b5e96c03daac1ed62b1e5c5057a2048 ] Register reporting ROM status is 4-bytes wide. Fixes: 092cf7b26a48 ("ASoC: Intel: avs: Code loading over HDA") Signed-off-by: Cezary Rojewski <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Amadeusz Sławiński <[email protected]> Date: Thu Jan 9 13:22:07 2025 +0100 ASoC: Intel: avs: Fix init-config parsing [ Upstream commit e9ca3db9f01a7ce91ceab35cd5fa52f0c5aca174 ] When parsing init configs correct token should be looked up. Fixes: 1b4217ebbb3e ("ASoC: Intel: avs: Add topology parsing support for initial config") Signed-off-by: Amadeusz Sławiński <[email protected]> Signed-off-by: Cezary Rojewski <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Cezary Rojewski <[email protected]> Date: Thu Jan 9 13:22:05 2025 +0100 ASoC: Intel: avs: Fix the minimum firmware version numbers [ Upstream commit dbda5c35b88794f6e5efe1b5b20044b0b3a340d4 ] For few TGL-based platforms the minor version number for AudioDSP firmware is incorrect forcing users to utilize ignore_fw_version module parameter. Fixes: 5acb19ecd198 ("ASoC: Intel: avs: TGL-based platforms support") Signed-off-by: Cezary Rojewski <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Cezary Rojewski <[email protected]> Date: Thu Jan 9 13:22:06 2025 +0100 ASoC: Intel: avs: Fix theoretical infinite loop [ Upstream commit cf4d74256fe103ece7b2647550e6c063048e5682 ] While 'stack_dump_size' is a u32 bitfield of 16 bits, u32 has a bigger upper bound than the type u16 of loop counter 'offset' what in theory may lead to infinite loop condition. Found out by Coverity static analyzer. Fixes: c8c960c10971 ("ASoC: Intel: avs: APL-based platforms support") Signed-off-by: Cezary Rojewski <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Bard Liao <[email protected]> Date: Fri Dec 6 15:58:54 2024 +0800 ASoC: Intel: sof_sdw: correct mach_params->dmic_num [ Upstream commit 4ab80a2961c75562ffbac1f80de151a978c31659 ] mach_params->dmic_num will be used to set the cfg-mics value of card->components string which should be the dmic channels. However dmic_num is dmic link number and could be set due to the SOC_SDW_PCH_DMIC quirk. Set mach_params->dmic_num to the default value if the dmic link is created due to the SOC_SDW_PCH_DMIC quirk. Fixes: 7db9f6361170 ("ASoC: Intel: sof_sdw: overwrite mach_params->dmic_num") Signed-off-by: Bard Liao <[email protected]> Reviewed-by: Kai Vehmanen <[email protected]> Reviewed-by: Péter Ujfalusi <[email protected]> Reviewed-by: Liam Girdwood <[email protected]> Reviewed-by: Ranjani Sridharan <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Simon Trimmer <[email protected]> Date: Thu Jan 2 20:33:35 2025 +0800 ASoC: Intel: sof_sdw: Fix DMI match for Lenovo 83JX, 83MC and 83NM [ Upstream commit 17615e4216115a0454e0f2007267a006231dcb7d ] Update the DMI match for a Lenovo laptop to a new DMI identifier. This laptop ships with a different DMI identifier to what was expected and now has three match entries. It also has the DMICs connected to the host rather than the cs42l43 codec. Signed-off-by: Simon Trimmer <[email protected]> Fixes: 83c062ae81e8 ("ASoC: Intel: sof_sdw: Add quirks for some new Lenovo laptops") Reviewed-by: Liam Girdwood <[email protected]> Reviewed-by: Ranjani Sridharan <[email protected]> Signed-off-by: Bard Liao <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Simon Trimmer <[email protected]> Date: Thu Jan 2 20:33:34 2025 +0800 ASoC: Intel: sof_sdw: Fix DMI match for Lenovo 83LC [ Upstream commit c9e05763f334845ba69494dd71d7cbfd05fd0e6e ] Update the DMI match for a Lenovo laptop to the new DMI identifier. This laptop ships with a different DMI identifier to what was expected, and also has the DMICs connected to the host rather than the cs42l43 codec. Signed-off-by: Simon Trimmer <[email protected]> Fixes: 83c062ae81e8 ("ASoC: Intel: sof_sdw: Add quirks for some new Lenovo laptops") Reviewed-by: Liam Girdwood <[email protected]> Reviewed-by: Ranjani Sridharan <[email protected]> Signed-off-by: Bard Liao <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Takashi Iwai <[email protected]> Date: Tue Dec 3 15:18:17 2024 +0100 ASoC: mediatek: mt8365: Use *-y for Makefile [ Upstream commit e9d2a2f49244d9737f0ec33f4b7f3580faecd805 ] We should use *-y instead of *-objs in Makefile for the module objects. *-objs is used rather for host programs. Fixes: 5bbfdad8cf8d ("ASoC: mediatek: Add MT8365 support") Signed-off-by: Takashi Iwai <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Claudiu Beznea <[email protected]> Date: Tue Dec 10 19:09:34 2024 +0200 ASoC: renesas: rz-ssi: Use only the proper amount of dividers [ Upstream commit 55c209cd4318c701e6e88e0b2512a0f12dd02a7d ] There is no need to populate the ckdv[] with invalid dividers as that part will not be indexed anyway. The ssi->audio_mck/bclk_rate should always be >= 0. While at it, change the ckdv type as u8, as the divider 128 was previously using the s8 sign bit. Signed-off-by: Claudiu Beznea <[email protected]> Fixes: 03e786bd43410fa9 ("ASoC: sh: Add RZ/G2L SSIF-2 driver") Reviewed-by: Geert Uytterhoeven <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Detlev Casanova <[email protected]> Date: Fri Jan 17 11:31:02 2025 -0500 ASoC: rockchip: i2s_tdm: Re-add the set_sysclk callback [ Upstream commit 5323186e2e8d33c073fad51e24f18e2d6dbae2da ] In commit 9e2ab4b18ebd ("ASoC: rockchip: i2s-tdm: Fix inaccurate sampling rates"), the set_sysclk callback was removed as considered unused as the mclk rate can be set in the hw_params callback. The difference between hw_params and set_sysclk is that the former is called with the audio sampling rate set in the params (e.g.: 48000 Hz) while the latter is called with a clock rate already computed with sampling_rate * mclk-fs (e.g.: 48000 * 256) For HDMI audio using the Rockchip I2S TDM driver, the mclk-fs value must be set to 128 instead of the default 256, and that value is set in the device tree at the machine driver level (like a simple-audio-card compatible node). Therefore, the i2s_tdm driver has no idea that another mclk-fs value can be configured and simply computes the mclk rate in the hw_params callback with DEFAULT_MCLK_FS * params_rate(params), which is wrong for HDMI audio. Re-add the set_sysclk callback so that the mclk rate is computed by the machine driver which has the correct mclk-fs value set in its device tree node. Fixes: 9e2ab4b18ebd ("ASoC: rockchip: i2s-tdm: Fix inaccurate sampling rates") Signed-off-by: Detlev Casanova <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Takashi Iwai <[email protected]> Date: Tue Dec 3 15:18:18 2024 +0100 ASoC: SDCA: Use *-y for Makefile [ Upstream commit f60646d9c3bd5b390728ed1a1caa9ded53d47afc ] We should use *-y instead of *-objs in Makefile for the module objects. *-objs is used rather for host programs. Fixes: 3a513da1ae33 ("ASoC: SDCA: add initial module") Signed-off-by: Takashi Iwai <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: George Lander <[email protected]> Date: Mon Nov 11 17:55:29 2024 +0100 ASoC: sun4i-spdif: Add clock multiplier settings [ Upstream commit 0a2319308de88b9e819c0b43d0fccd857123eb31 ] There have been intermittent issues with the SPDIF output on H3 and H2+ devices which has been fixed by setting the s_clk to 4 times the audio pll. Add a quirk for the clock multiplier as not every supported SoC requires it. Without the multiplier, the audio at normal sampling rates was distorted and did not play at higher sampling rates. Fixes: 1bd92af877ab ("ASoC: sun4i-spdif: Add support for the H3 SoC") Signed-off-by: George Lander <[email protected]> Signed-off-by: Marcus Cooper <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Takashi Iwai <[email protected]> Date: Tue Dec 3 15:18:20 2024 +0100 ASoC: wcd937x: Use *-y for Makefile [ Upstream commit 582057d2233a5a38e1aec3f4a6d66b362b42076c ] We should use *-y instead of *-objs in Makefile for the module objects. *-objs is used rather for host programs. Fixes: 313e978df7fc ("ASoC: codecs: wcd937x: add audio routing and Kconfig") Signed-off-by: Takashi Iwai <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Eric Dumazet <[email protected]> Date: Fri Jan 3 21:05:14 2025 +0000 ax25: rcu protect dev->ax25_ptr [ Upstream commit 95fc45d1dea8e1253f8ec58abc5befb71553d666 ] syzbot found a lockdep issue [1]. We should remove ax25 RTNL dependency in ax25_setsockopt() This should also fix a variety of possible UAF in ax25. [1] WARNING: possible circular locking dependency detected 6.13.0-rc3-syzkaller-00762-g9268abe611b0 #0 Not tainted ------------------------------------------------------ syz.5.1818/12806 is trying to acquire lock: ffffffff8fcb3988 (rtnl_mutex){+.+.}-{4:4}, at: ax25_setsockopt+0xa55/0xe90 net/ax25/af_ax25.c:680 but task is already holding lock: ffff8880617ac258 (sk_lock-AF_AX25){+.+.}-{0:0}, at: lock_sock include/net/sock.h:1618 [inline] ffff8880617ac258 (sk_lock-AF_AX25){+.+.}-{0:0}, at: ax25_setsockopt+0x209/0xe90 net/ax25/af_ax25.c:574 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 (sk_lock-AF_AX25){+.+.}-{0:0}: lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5849 lock_sock_nested+0x48/0x100 net/core/sock.c:3642 lock_sock include/net/sock.h:1618 [inline] ax25_kill_by_device net/ax25/af_ax25.c:101 [inline] ax25_device_event+0x24d/0x580 net/ax25/af_ax25.c:146 notifier_call_chain+0x1a5/0x3f0 kernel/notifier.c:85 __dev_notify_flags+0x207/0x400 dev_change_flags+0xf0/0x1a0 net/core/dev.c:9026 dev_ifsioc+0x7c8/0xe70 net/core/dev_ioctl.c:563 dev_ioctl+0x719/0x1340 net/core/dev_ioctl.c:820 sock_do_ioctl+0x240/0x460 net/socket.c:1234 sock_ioctl+0x626/0x8e0 net/socket.c:1339 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:906 [inline] __se_sys_ioctl+0xf5/0x170 fs/ioctl.c:892 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f -> #0 (rtnl_mutex){+.+.}-{4:4}: check_prev_add kernel/locking/lockdep.c:3161 [inline] check_prevs_add kernel/locking/lockdep.c:3280 [inline] validate_chain+0x18ef/0x5920 kernel/locking/lockdep.c:3904 __lock_acquire+0x1397/0x2100 kernel/locking/lockdep.c:5226 lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5849 __mutex_lock_common kernel/locking/mutex.c:585 [inline] __mutex_lock+0x1ac/0xee0 kernel/locking/mutex.c:735 ax25_setsockopt+0xa55/0xe90 net/ax25/af_ax25.c:680 do_sock_setsockopt+0x3af/0x720 net/socket.c:2324 __sys_setsockopt net/socket.c:2349 [inline] __do_sys_setsockopt net/socket.c:2355 [inline] __se_sys_setsockopt net/socket.c:2352 [inline] __x64_sys_setsockopt+0x1ee/0x280 net/socket.c:2352 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f other info that might help us debug this: Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(sk_lock-AF_AX25); lock(rtnl_mutex); lock(sk_lock-AF_AX25); lock(rtnl_mutex); *** DEADLOCK *** 1 lock held by syz.5.1818/12806: #0: ffff8880617ac258 (sk_lock-AF_AX25){+.+.}-{0:0}, at: lock_sock include/net/sock.h:1618 [inline] #0: ffff8880617ac258 (sk_lock-AF_AX25){+.+.}-{0:0}, at: ax25_setsockopt+0x209/0xe90 net/ax25/af_ax25.c:574 stack backtrace: CPU: 1 UID: 0 PID: 12806 Comm: syz.5.1818 Not tainted 6.13.0-rc3-syzkaller-00762-g9268abe611b0 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 Call Trace: <TASK> __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120 print_circular_bug+0x13a/0x1b0 kernel/locking/lockdep.c:2074 check_noncircular+0x36a/0x4a0 kernel/locking/lockdep.c:2206 check_prev_add kernel/locking/lockdep.c:3161 [inline] check_prevs_add kernel/locking/lockdep.c:3280 [inline] validate_chain+0x18ef/0x5920 kernel/locking/lockdep.c:3904 __lock_acquire+0x1397/0x2100 kernel/locking/lockdep.c:5226 lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5849 __mutex_lock_common kernel/locking/mutex.c:585 [inline] __mutex_lock+0x1ac/0xee0 kernel/locking/mutex.c:735 ax25_setsockopt+0xa55/0xe90 net/ax25/af_ax25.c:680 do_sock_setsockopt+0x3af/0x720 net/socket.c:2324 __sys_setsockopt net/socket.c:2349 [inline] __do_sys_setsockopt net/socket.c:2355 [inline] __se_sys_setsockopt net/socket.c:2352 [inline] __x64_sys_setsockopt+0x1ee/0x280 net/socket.c:2352 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f7b62385d29 Fixes: c433570458e4 ("ax25: fix a use-after-free in ax25_fillin_cb()") Reported-by: syzbot <[email protected]> Signed-off-by: Eric Dumazet <[email protected]> Reviewed-by: Kuniyuki Iwashima <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Rafał Miłecki <[email protected]> Date: Mon Jan 27 09:51:59 2025 -0800 bgmac: reduce max frame size to support just MTU 1500 [ Upstream commit 752e5fcc2e77358936d36ef8e522d6439372e201 ] bgmac allocates new replacement buffer before handling each received frame. Allocating & DMA-preparing 9724 B each time consumes a lot of CPU time. Ideally bgmac should just respect currently set MTU but it isn't the case right now. For now just revert back to the old limited frame size. This change bumps NAT masquerade speed by ~95%. Since commit 8218f62c9c9b ("mm: page_frag: use initial zero offset for page_frag_alloc_align()"), the bgmac driver fails to open its network interface successfully and runs out of memory in the following call stack: bgmac_open -> bgmac_dma_init -> bgmac_dma_rx_skb_for_slot -> netdev_alloc_frag BGMAC_RX_ALLOC_SIZE = 10048 and PAGE_FRAG_CACHE_MAX_SIZE = 32768. Eventually we land into __page_frag_alloc_align() with the following parameters across multiple successive calls: __page_frag_alloc_align: fragsz=10048, align_mask=-1, size=32768, offset=0 __page_frag_alloc_align: fragsz=10048, align_mask=-1, size=32768, offset=10048 __page_frag_alloc_align: fragsz=10048, align_mask=-1, size=32768, offset=20096 __page_frag_alloc_align: fragsz=10048, align_mask=-1, size=32768, offset=30144 So in that case we do indeed have offset + fragsz (40192) > size (32768) and so we would eventually return NULL. Reverting to the older 1500 bytes MTU allows the network driver to be usable again. Fixes: 8c7da63978f1 ("bgmac: configure MTU and add support for frames beyond 8192 byte size") Signed-off-by: Rafał Miłecki <[email protected]> [florian: expand commit message about recent commits] Reviewed-by: Simon Horman <[email protected]> Signed-off-by: Florian Fainelli <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Christoph Hellwig <[email protected]> Date: Fri Jan 10 06:47:10 2025 +0100 block: add a queue_limits_commit_update_frozen helper [ Upstream commit aa427d7b73b196f657d6d2cf0e94eff6b883fdef ] Add a helper that freezes the queue, updates the queue limits and unfreezes the queue and convert all open coded versions of that to the new helper. Signed-off-by: Christoph Hellwig <[email protected]> Reviewed-by: John Garry <[email protected]> Reviewed-by: Ming Lei <[email protected]> Reviewed-by: Damien Le Moal <[email protected]> Reviewed-by: Martin K. Petersen <[email protected]> Reviewed-by: Nilay Shroff <[email protected]> Reviewed-by: Johannes Thumshirn <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jens Axboe <[email protected]> Stable-dep-of: c99f66e4084a ("block: fix queue freeze vs limits lock order in sysfs store methods") Signed-off-by: Sasha Levin <[email protected]>
Author: Christoph Hellwig <[email protected]> Date: Fri Jan 10 06:47:13 2025 +0100 block: add a store_limit operations for sysfs entries [ Upstream commit a16230649ce27f8ac7dd8a5b079d9657aa96de16 ] De-duplicate the code for updating queue limits by adding a store_limit method that allows having common code handle the actual queue limits update. Note that this is a pure refactoring patch and does not address the existing freeze vs limits lock order problem in the refactored code, which will be addressed next. Signed-off-by: Christoph Hellwig <[email protected]> Reviewed-by: Ming Lei <[email protected]> Reviewed-by: Damien Le Moal <[email protected]> Reviewed-by: Martin K. Petersen <[email protected]> Reviewed-by: Nilay Shroff <[email protected]> Reviewed-by: Johannes Thumshirn <[email protected]> Reviewed-by: John Garry <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jens Axboe <[email protected]> Stable-dep-of: c99f66e4084a ("block: fix queue freeze vs limits lock order in sysfs store methods") Signed-off-by: Sasha Levin <[email protected]>
Author: Christoph Hellwig <[email protected]> Date: Fri Jan 10 06:47:11 2025 +0100 block: check BLK_FEAT_POLL under q_usage_count [ Upstream commit 958148a6ac061a9a80a184ea678a5fa872d0c56f ] Otherwise feature reconfiguration can race with I/O submission. Also drop the bio_clear_polled in the error path, as the flag does not matter for instant error completions, it is a left over from when we allowed polled I/O to proceed unpolled in this case. Signed-off-by: Christoph Hellwig <[email protected]> Reviewed-by: Ming Lei <[email protected]> Reviewed-by: Nilay Shroff <[email protected]> Reviewed-by: Martin K. Petersen <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jens Axboe <[email protected]> Stable-dep-of: d432c817c21a ("block: don't update BLK_FEAT_POLL in __blk_mq_update_nr_hw_queues") Signed-off-by: Sasha Levin <[email protected]>
Author: Christoph Hellwig <[email protected]> Date: Thu Nov 28 16:52:32 2024 +0530 block: copy back bounce buffer to user-space correctly in case of split [ Upstream commit 031141976be0bd5f385775727a4ed3cc845eb7ba ] Copy back the bounce buffer to user-space in entirety when the parent bio completes. The existing code uses bip_iter.bi_size for sizing the copy, which can be modified. So move away from that and fetch it from the vector passed to the block layer. While at it, switch to using better variable names. Fixes: 492c5d455969f ("block: bio-integrity: directly map user buffers") Signed-off-by: Christoph Hellwig <[email protected]> Signed-off-by: Anuj Gupta <[email protected]> Reviewed-by: Keith Busch <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jens Axboe <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Christoph Hellwig <[email protected]> Date: Fri Jan 10 06:47:12 2025 +0100 block: don't update BLK_FEAT_POLL in __blk_mq_update_nr_hw_queues [ Upstream commit d432c817c21a48c3baaa0d28e4d3e74b6aa238a0 ] When __blk_mq_update_nr_hw_queues changes the number of tag sets, it might have to disable poll queues. Currently it does so by adjusting the BLK_FEAT_POLL, which is a bit against the intent of features that describe hardware / driver capabilities, but more importantly causes nasty lock order problems with the broadly held freeze when updating the number of hardware queues and the limits lock. Fix this by leaving BLK_FEAT_POLL alone, and instead check for the number of poll queues in the bio submission and poll handlers. While this adds extra work to the fast path, the variables are in cache lines used by these operations anyway, so it should be cheap enough. Fixes: 8023e144f9d6 ("block: move the poll flag to queue_limits") Signed-off-by: Christoph Hellwig <[email protected]> Reviewed-by: Ming Lei <[email protected]> Reviewed-by: Damien Le Moal <[email protected]> Reviewed-by: Martin K. Petersen <[email protected]> Reviewed-by: Johannes Thumshirn <[email protected]> Reviewed-by: Nilay Shroff <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jens Axboe <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: John Garry <[email protected]> Date: Thu Jan 9 11:39:59 2025 +0000 block: Ensure start sector is aligned for stacking atomic writes [ Upstream commit 6564862d646e7d630929ba1ff330740bb215bdac ] For stacking atomic writes, ensure that the start sector is aligned with the device atomic write unit min and any boundary. Otherwise, we may permit misaligned atomic writes. Rework bdev_can_atomic_write() into a common helper to resuse the alignment check. There also use atomic_write_hw_unit_min, which is more proper (than atomic_write_unit_min). Fixes: d7f36dc446e89 ("block: Support atomic writes limits for stacked devices") Reviewed-by: Christoph Hellwig <[email protected]> Signed-off-by: John Garry <[email protected]> Reviewed-by: Martin K. Petersen <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jens Axboe <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Christoph Hellwig <[email protected]> Date: Fri Jan 10 06:47:14 2025 +0100 block: fix queue freeze vs limits lock order in sysfs store methods [ Upstream commit c99f66e4084a62a2cc401c4704a84328aeddc9ec ] queue_attr_store() always freezes a device queue before calling the attribute store operation. For attributes that control queue limits, the store operation will also lock the queue limits with a call to queue_limits_start_update(). However, some drivers (e.g. SCSI sd) may need to issue commands to a device to obtain limit values from the hardware with the queue limits locked. This creates a potential ABBA deadlock situation if a user attempts to modify a limit (thus freezing the device queue) while the device driver starts a revalidation of the device queue limits. Avoid such deadlock by not freezing the queue before calling the ->store_limit() method in struct queue_sysfs_entry and instead use the queue_limits_commit_update_frozen helper to freeze the queue after taking the limits lock. This also removes taking the sysfs lock for the store_limit method as it doesn't protect anything here, but creates even more nesting. Hopefully it will go away from the actual sysfs methods entirely soon. (commit log adapted from a similar patch from Damien Le Moal) Fixes: ff956a3be95b ("block: use queue_limits_commit_update in queue_discard_max_store") Fixes: 0327ca9d53bf ("block: use queue_limits_commit_update in queue_max_sectors_store") Signed-off-by: Christoph Hellwig <[email protected]> Reviewed-by: Ming Lei <[email protected]> Reviewed-by: Damien Le Moal <[email protected]> Reviewed-by: Martin K. Petersen <[email protected]> Reviewed-by: Nilay Shroff <[email protected]> Reviewed-by: Johannes Thumshirn <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jens Axboe <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Yang Erkun <[email protected]> Date: Mon Dec 9 19:04:35 2024 +0800 block: retry call probe after request_module in blk_request_module [ Upstream commit 457ef47c08d2979f3e59ce66267485c3faed70c8 ] Set kernel config: CONFIG_BLK_DEV_LOOP=m CONFIG_BLK_DEV_LOOP_MIN_COUNT=0 Do latter: mknod loop0 b 7 0 exec 4<> loop0 Before commit e418de3abcda ("block: switch gendisk lookup to a simple xarray"), lookup_gendisk will first use base_probe to load module loop, and then the retry will call loop_probe to prepare the loop disk. Finally open for this disk will success. However, after this commit, we lose the retry logic, and open will fail with ENXIO. Block device autoloading is deprecated and will be removed soon, but maybe we should keep open success until we really remove it. So, give a retry to fix it. Fixes: e418de3abcda ("block: switch gendisk lookup to a simple xarray") Suggested-by: Christoph Hellwig <[email protected]> Signed-off-by: Yang Erkun <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jens Axboe <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Charles Han <[email protected]> Date: Fri Dec 27 17:20:46 2024 +0800 Bluetooth: btbcm: Fix NULL deref in btbcm_get_board_name() [ Upstream commit b88655bc6593c6a7fdc1248b212d17e581c4334e ] devm_kstrdup() can return a NULL pointer on failure,but this returned value in btbcm_get_board_name() is not checked. Add NULL check in btbcm_get_board_name(), to handle kernel NULL pointer dereference error. Fixes: f9183eaad915 ("Bluetooth: btbcm: Use devm_kstrdup()") Signed-off-by: Charles Han <[email protected]> Signed-off-by: Luiz Augusto von Dentz <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Neeraj Sanjay Kale <[email protected]> Date: Mon Jan 20 19:49:46 2025 +0530 Bluetooth: btnxpuart: Fix glitches seen in dual A2DP streaming [ Upstream commit 7de119bb79a63f6a1959b83117a98734914fb0b0 ] This fixes a regression caused by previous commit for fixing truncated ACL data, which is causing some intermittent glitches when running two A2DP streams. serdev_device_write_buf() is the root cause of the glitch, which is reverted, and the TX work will continue to write until the queue is empty. This change fixes both issues. No A2DP streaming glitches or truncated ACL data issue observed. Fixes: 8023dd220425 ("Bluetooth: btnxpuart: Fix driver sending truncated data") Fixes: 689ca16e5232 ("Bluetooth: NXP: Add protocol support for NXP Bluetooth chipsets") Signed-off-by: Neeraj Sanjay Kale <[email protected]> Signed-off-by: Luiz Augusto von Dentz <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Max Chou <[email protected]> Date: Tue Dec 31 14:57:19 2024 +0800 Bluetooth: btrtl: check for NULL in btrtl_setup_realtek() [ Upstream commit 3c15082f3567032d196e8760753373332508c2ca ] If insert an USB dongle which chip is not maintained in ic_id_table, it will hit the NULL point accessed. Add a null point check to avoid the Kernel Oops. Fixes: b39910bb54d9 ("Bluetooth: Populate hci_set_hw_info for Intel and Realtek") Reviewed-by: Alex Lu <[email protected]> Signed-off-by: Max Chou <[email protected]> Signed-off-by: Luiz Augusto von Dentz <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Douglas Anderson <[email protected]> Date: Wed Jan 15 19:36:36 2025 -0800 Bluetooth: btusb: mediatek: Add locks for usb_driver_claim_interface() [ Upstream commit e9087e828827e5a5c85e124ce77503f2b81c3491 ] The documentation for usb_driver_claim_interface() says that "the device lock" is needed when the function is called from places other than probe(). This appears to be the lock for the USB interface device. The Mediatek btusb code gets called via this path: Workqueue: hci0 hci_power_on [bluetooth] Call trace: usb_driver_claim_interface btusb_mtk_claim_iso_intf btusb_mtk_setup hci_dev_open_sync hci_power_on process_scheduled_works worker_thread kthread With the above call trace the device lock hasn't been claimed. Claim it. Without this fix, we'd sometimes see the error "Failed to claim iso interface". Sometimes we'd even see worse errors, like a NULL pointer dereference (where `intf->dev.driver` was NULL) with a trace like: Call trace: usb_suspend_both usb_runtime_suspend __rpm_callback rpm_suspend pm_runtime_work process_scheduled_works Both errors appear to be fixed with the proper locking. Fixes: ceac1cb0259d ("Bluetooth: btusb: mediatek: add ISO data transmission functions") Signed-off-by: Douglas Anderson <[email protected]> Signed-off-by: Luiz Augusto von Dentz <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Cosmin Ratiu <[email protected]> Date: Mon Jan 27 12:41:47 2025 +0200 bonding: Correctly support GSO ESP offload [ Upstream commit 9e6c4e6b605c1fa3e24f74ee0b641e95f090188a ] The referenced fix is incomplete. It correctly computes bond_dev->gso_partial_features across slaves, but unfortunately netdev_fix_features discards gso_partial_features from the feature set if NETIF_F_GSO_PARTIAL isn't set in bond_dev->features. This is visible with ethtool -k bond0 | grep esp: tx-esp-segmentation: off [requested on] esp-hw-offload: on esp-tx-csum-hw-offload: on This patch reworks the bonding GSO offload support by: - making aggregating gso_partial_features across slaves similar to the other feature sets (this part is a no-op). - advertising the default partial gso features on empty bond devs, same as with other feature sets (also a no-op). - adding NETIF_F_GSO_PARTIAL to hw_enc_features filtered across slaves. - adding NETIF_F_GSO_PARTIAL to features in bond_setup() With all of these, 'ethtool -k bond0 | grep esp' now reports: tx-esp-segmentation: on esp-hw-offload: on esp-tx-csum-hw-offload: on Fixes: 4861333b4217 ("bonding: add ESP offload features when slaves support") Signed-off-by: Hangbin Liu <[email protected]> Signed-off-by: Cosmin Ratiu <[email protected]> Acked-by: Jay Vosburgh <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Paolo Abeni <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Martin KaFai Lau <[email protected]> Date: Wed Dec 18 11:30:00 2024 -0800 bpf: bpf_local_storage: Always use bpf_mem_alloc in PREEMPT_RT [ Upstream commit 8eef6ac4d70eb1f0099fff93321d90ce8fa49ee1 ] In PREEMPT_RT, kmalloc(GFP_ATOMIC) is still not safe in non preemptible context. bpf_mem_alloc must be used in PREEMPT_RT. This patch is to enforce bpf_mem_alloc in the bpf_local_storage when CONFIG_PREEMPT_RT is enabled. [ 35.118559] BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:48 [ 35.118566] in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 1832, name: test_progs [ 35.118569] preempt_count: 1, expected: 0 [ 35.118571] RCU nest depth: 1, expected: 1 [ 35.118577] INFO: lockdep is turned off. ... [ 35.118647] __might_resched+0x433/0x5b0 [ 35.118677] rt_spin_lock+0xc3/0x290 [ 35.118700] ___slab_alloc+0x72/0xc40 [ 35.118723] __kmalloc_noprof+0x13f/0x4e0 [ 35.118732] bpf_map_kzalloc+0xe5/0x220 [ 35.118740] bpf_selem_alloc+0x1d2/0x7b0 [ 35.118755] bpf_local_storage_update+0x2fa/0x8b0 [ 35.118784] bpf_sk_storage_get_tracing+0x15a/0x1d0 [ 35.118791] bpf_prog_9a118d86fca78ebb_trace_inet_sock_set_state+0x44/0x66 [ 35.118795] bpf_trace_run3+0x222/0x400 [ 35.118820] __bpf_trace_inet_sock_set_state+0x11/0x20 [ 35.118824] trace_inet_sock_set_state+0x112/0x130 [ 35.118830] inet_sk_state_store+0x41/0x90 [ 35.118836] tcp_set_state+0x3b3/0x640 There is no need to adjust the gfp_flags passing to the bpf_mem_cache_alloc_flags() which only honors the GFP_KERNEL. The verifier has ensured GFP_KERNEL is passed only in sleepable context. It has been an old issue since the first introduction of the bpf_local_storage ~5 years ago, so this patch targets the bpf-next. bpf_mem_alloc is needed to solve it, so the Fixes tag is set to the commit when bpf_mem_alloc was first used in the bpf_local_storage. Fixes: 08a7ce384e33 ("bpf: Use bpf_mem_cache_alloc/free in bpf_local_storage_elem") Reported-by: Alexei Starovoitov <[email protected]> Signed-off-by: Martin KaFai Lau <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Alexei Starovoitov <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Hou Tao <[email protected]> Date: Fri Jan 17 18:18:15 2025 +0800 bpf: Cancel the running bpf_timer through kworker for PREEMPT_RT [ Upstream commit 58f038e6d209d2dd862fcf5de55407855856794d ] During the update procedure, when overwrite element in a pre-allocated htab, the freeing of old_element is protected by the bucket lock. The reason why the bucket lock is necessary is that the old_element has already been stashed in htab->extra_elems after alloc_htab_elem() returns. If freeing the old_element after the bucket lock is unlocked, the stashed element may be reused by concurrent update procedure and the freeing of old_element will run concurrently with the reuse of the old_element. However, the invocation of check_and_free_fields() may acquire a spin-lock which violates the lockdep rule because its caller has already held a raw-spin-lock (bucket lock). The following warning will be reported when such race happens: BUG: scheduling while atomic: test_progs/676/0x00000003 3 locks held by test_progs/676: #0: ffffffff864b0240 (rcu_read_lock_trace){....}-{0:0}, at: bpf_prog_test_run_syscall+0x2c0/0x830 #1: ffff88810e961188 (&htab->lockdep_key){....}-{2:2}, at: htab_map_update_elem+0x306/0x1500 #2: ffff8881f4eac1b8 (&base->softirq_expiry_lock){....}-{2:2}, at: hrtimer_cancel_wait_running+0xe9/0x1b0 Modules linked in: bpf_testmod(O) Preemption disabled at: [<ffffffff817837a3>] htab_map_update_elem+0x293/0x1500 CPU: 0 UID: 0 PID: 676 Comm: test_progs Tainted: G ... 6.12.0+ #11 Tainted: [W]=WARN, [O]=OOT_MODULE Hardware name: QEMU Standard PC (i440FX + PIIX, 1996)... Call Trace: <TASK> dump_stack_lvl+0x57/0x70 dump_stack+0x10/0x20 __schedule_bug+0x120/0x170 __schedule+0x300c/0x4800 schedule_rtlock+0x37/0x60 rtlock_slowlock_locked+0x6d9/0x54c0 rt_spin_lock+0x168/0x230 hrtimer_cancel_wait_running+0xe9/0x1b0 hrtimer_cancel+0x24/0x30 bpf_timer_delete_work+0x1d/0x40 bpf_timer_cancel_and_free+0x5e/0x80 bpf_obj_free_fields+0x262/0x4a0 check_and_free_fields+0x1d0/0x280 htab_map_update_elem+0x7fc/0x1500 bpf_prog_9f90bc20768e0cb9_overwrite_cb+0x3f/0x43 bpf_prog_ea601c4649694dbd_overwrite_timer+0x5d/0x7e bpf_prog_test_run_syscall+0x322/0x830 __sys_bpf+0x135d/0x3ca0 __x64_sys_bpf+0x75/0xb0 x64_sys_call+0x1b5/0xa10 do_syscall_64+0x3b/0xc0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 ... </TASK> It seems feasible to break the reuse and refill of per-cpu extra_elems into two independent parts: reuse the per-cpu extra_elems with bucket lock being held and refill the old_element as per-cpu extra_elems after the bucket lock is unlocked. However, it will make the concurrent overwrite procedures on the same CPU return unexpected -E2BIG error when the map is full. Therefore, the patch fixes the lock problem by breaking the cancelling of bpf_timer into two steps for PREEMPT_RT: 1) use hrtimer_try_to_cancel() and check its return value 2) if the timer is running, use hrtimer_cancel() through a kworker to cancel it again Considering that the current implementation of hrtimer_cancel() will try to acquire a being held softirq_expiry_lock when the current timer is running, these steps above are reasonable. However, it also has downside. When the timer is running, the cancelling of the timer is delayed when releasing the last map uref. The delay is also fixable (e.g., break the cancelling of bpf timer into two parts: one part in locked scope, another one in unlocked scope), it can be revised later if necessary. It is a bit hard to decide the right fix tag. One reason is that the problem depends on PREEMPT_RT which is enabled in v6.12. Considering the softirq_expiry_lock lock exists since v5.4 and bpf_timer is introduced in v5.15, the bpf_timer commit is used in the fixes tag and an extra depends-on tag is added to state the dependency on PREEMPT_RT. Fixes: b00628b1c7d5 ("bpf: Introduce bpf timers.") Depends-on: v6.12+ with PREEMPT_RT enabled Reported-by: Sebastian Andrzej Siewior <[email protected]> Closes: https://lore.kernel.org/bpf/[email protected] Signed-off-by: Hou Tao <[email protected]> Reviewed-by: Toke Høiland-Jørgensen <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Alexei Starovoitov <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Martin KaFai Lau <[email protected]> Date: Fri Dec 20 12:18:18 2024 -0800 bpf: Reject struct_ops registration that uses module ptr and the module btf_id is missing [ Upstream commit 96ea081ed52bf077cad6d00153b6fba68e510767 ] There is a UAF report in the bpf_struct_ops when CONFIG_MODULES=n. In particular, the report is on tcp_congestion_ops that has a "struct module *owner" member. For struct_ops that has a "struct module *owner" member, it can be extended either by the regular kernel module or by the bpf_struct_ops. bpf_try_module_get() will be used to do the refcounting and different refcount is done based on the owner pointer. When CONFIG_MODULES=n, the btf_id of the "struct module" is missing: WARN: resolve_btfids: unresolved symbol module Thus, the bpf_try_module_get() cannot do the correct refcounting. Not all subsystem's struct_ops requires the "struct module *owner" member. e.g. the recent sched_ext_ops. This patch is to disable bpf_struct_ops registration if the struct_ops has the "struct module *" member and the "struct module" btf_id is missing. The btf_type_is_fwd() helper is moved to the btf.h header file for this test. This has happened since the beginning of bpf_struct_ops which has gone through many changes. The Fixes tag is set to a recent commit that this patch can apply cleanly. Considering CONFIG_MODULES=n is not common and the age of the issue, targeting for bpf-next also. Fixes: 1611603537a4 ("bpf: Create argument information for nullable arguments.") Reported-by: Robert Morris <[email protected]> Closes: https://lore.kernel.org/bpf/74665.1733669976@localhost/ Signed-off-by: Martin KaFai Lau <[email protected]> Tested-by: Eduard Zingerman <[email protected]> Acked-by: Eduard Zingerman <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Alexei Starovoitov <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Puranjay Mohan <[email protected]> Date: Wed Jan 15 10:36:47 2025 +0000 bpf: Send signals asynchronously if !preemptible [ Upstream commit 87c544108b612512b254c8f79aa5c0a8546e2cc4 ] BPF programs can execute in all kinds of contexts and when a program running in a non-preemptible context uses the bpf_send_signal() kfunc, it will cause issues because this kfunc can sleep. Change `irqs_disabled()` to `!preemptible()`. Reported-by: [email protected] Closes: https://lore.kernel.org/all/[email protected]/ Fixes: 1bc7896e9ef4 ("bpf: Fix deadlock with rq_lock in bpf_send_signal()") Signed-off-by: Puranjay Mohan <[email protected]> Acked-by: Yonghong Song <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Alexei Starovoitov <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Daniel Xu <[email protected]> Date: Tue Jan 14 13:28:43 2025 -0700 bpf: tcp: Mark bpf_load_hdr_opt() arg2 as read-write [ Upstream commit 8ac412a3361173e3000b16167af3d1f6f90af613 ] MEM_WRITE attribute is defined as: "Non-presence of MEM_WRITE means that MEM is only being read". bpf_load_hdr_opt() both reads and writes from its arg2 - void *search_res. This matters a lot for the next commit where we more precisely track stack accesses. Without this annotation, the verifier will make false assumptions about the contents of memory written to by helpers and possibly prune valid branches. Fixes: 6fad274f06f0 ("bpf: Add MEM_WRITE attribute") Acked-by: Martin KaFai Lau <[email protected]> Signed-off-by: Daniel Xu <[email protected]> Link: https://lore.kernel.org/r/730e45f8c39be2a5f3d8c4406cceca9d574cbf14.1736886479.git.dxu@dxuuu.xyz Signed-off-by: Alexei Starovoitov <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Pei Xiao <[email protected]> Date: Mon Dec 30 15:16:55 2024 +0800 bpf: Use refcount_t instead of atomic_t for mmap_count [ Upstream commit dfa94ce54f4139c893b9c4ec17df6f7c6a7515d3 ] Use an API that resembles more the actual use of mmap_count. Found by cocci: kernel/bpf/arena.c:245:6-25: WARNING: atomic_dec_and_test variation before object free at line 249. Fixes: b90d77e5fd78 ("bpf: Fix remap of arena.") Reported-by: kernel test robot <[email protected]> Closes: https://lore.kernel.org/oe-kbuild-all/[email protected]/ Signed-off-by: Pei Xiao <[email protected]> Link: https://lore.kernel.org/r/6ecce439a6bc81adb85d5080908ea8959b792a50.1735542814.git.xiaopei01@kylinos.cn Signed-off-by: Alexei Starovoitov <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Qu Wenruo <[email protected]> Date: Thu Dec 12 16:43:58 2024 +1030 btrfs: do proper folio cleanup when cow_file_range() failed commit 06f364284794f149d2abc167c11d556cf20c954b upstream. [BUG] When testing with COW fixup marked as BUG_ON() (this is involved with the new pin_user_pages*() change, which should not result new out-of-band dirty pages), I hit a crash triggered by the BUG_ON() from hitting COW fixup path. This BUG_ON() happens just after a failed btrfs_run_delalloc_range(): BTRFS error (device dm-2): failed to run delalloc range, root 348 ino 405 folio 65536 submit_bitmap 6-15 start 90112 len 106496: -28 ------------[ cut here ]------------ kernel BUG at fs/btrfs/extent_io.c:1444! Internal error: Oops - BUG: 00000000f2000800 [#1] SMP CPU: 0 UID: 0 PID: 434621 Comm: kworker/u24:8 Tainted: G OE 6.12.0-rc7-custom+ #86 Hardware name: QEMU KVM Virtual Machine, BIOS unknown 2/2/2022 Workqueue: events_unbound btrfs_async_reclaim_data_space [btrfs] pc : extent_writepage_io+0x2d4/0x308 [btrfs] lr : extent_writepage_io+0x2d4/0x308 [btrfs] Call trace: extent_writepage_io+0x2d4/0x308 [btrfs] extent_writepage+0x218/0x330 [btrfs] extent_write_cache_pages+0x1d4/0x4b0 [btrfs] btrfs_writepages+0x94/0x150 [btrfs] do_writepages+0x74/0x190 filemap_fdatawrite_wbc+0x88/0xc8 start_delalloc_inodes+0x180/0x3b0 [btrfs] btrfs_start_delalloc_roots+0x174/0x280 [btrfs] shrink_delalloc+0x114/0x280 [btrfs] flush_space+0x250/0x2f8 [btrfs] btrfs_async_reclaim_data_space+0x180/0x228 [btrfs] process_one_work+0x164/0x408 worker_thread+0x25c/0x388 kthread+0x100/0x118 ret_from_fork+0x10/0x20 Code: aa1403e1 9402f3ef aa1403e0 9402f36f (d4210000) ---[ end trace 0000000000000000 ]--- [CAUSE] That failure is mostly from cow_file_range(), where we can hit -ENOSPC. Although the -ENOSPC is already a bug related to our space reservation code, let's just focus on the error handling. For example, we have the following dirty range [0, 64K) of an inode, with 4K sector size and 4K page size: 0 16K 32K 48K 64K |///////////////////////////////////////| |#######################################| Where |///| means page are still dirty, and |###| means the extent io tree has EXTENT_DELALLOC flag. - Enter extent_writepage() for page 0 - Enter btrfs_run_delalloc_range() for range [0, 64K) - Enter cow_file_range() for range [0, 64K) - Function btrfs_reserve_extent() only reserved one 16K extent So we created extent map and ordered extent for range [0, 16K) 0 16K 32K 48K 64K |////////|//////////////////////////////| |<- OE ->|##############################| And range [0, 16K) has its delalloc flag cleared. But since we haven't yet submit any bio, involved 4 pages are still dirty. - Function btrfs_reserve_extent() returns with -ENOSPC Now we have to run error cleanup, which will clear all EXTENT_DELALLOC* flags and clear the dirty flags for the remaining ranges: 0 16K 32K 48K 64K |////////| | | | | Note that range [0, 16K) still has its pages dirty. - Some time later, writeback is triggered again for the range [0, 16K) since the page range still has dirty flags. - btrfs_run_delalloc_range() will do nothing because there is no EXTENT_DELALLOC flag. - extent_writepage_io() finds page 0 has no ordered flag Which falls into the COW fixup path, triggering the BUG_ON(). Unfortunately this error handling bug dates back to the introduction of btrfs. Thankfully with the abuse of COW fixup, at least it won't crash the kernel. [FIX] Instead of immediately unlocking the extent and folios, we keep the extent and folios locked until either erroring out or the whole delalloc range finished. When the whole delalloc range finished without error, we just unlock the whole range with PAGE_SET_ORDERED (and PAGE_UNLOCK for !keep_locked cases), with EXTENT_DELALLOC and EXTENT_LOCKED cleared. And the involved folios will be properly submitted, with their dirty flags cleared during submission. For the error path, it will be a little more complex: - The range with ordered extent allocated (range (1)) We only clear the EXTENT_DELALLOC and EXTENT_LOCKED, as the remaining flags are cleaned up by btrfs_mark_ordered_io_finished()->btrfs_finish_one_ordered(). For folios we finish the IO (clear dirty, start writeback and immediately finish the writeback) and unlock the folios. - The range with reserved extent but no ordered extent (range(2)) - The range we never touched (range(3)) For both range (2) and range(3) the behavior is not changed. Now even if cow_file_range() failed halfway with some successfully reserved extents/ordered extents, we will keep all folios clean, so there will be no future writeback triggered on them. CC: [email protected] Reviewed-by: Boris Burkov <[email protected]> Signed-off-by: Qu Wenruo <[email protected]> Signed-off-by: David Sterba <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Qu Wenruo <[email protected]> Date: Thu Dec 12 16:43:59 2024 +1030 btrfs: do proper folio cleanup when run_delalloc_nocow() failed commit c2b47df81c8e20a8e8cd94f0d7df211137ae94ed upstream. [BUG] With CONFIG_DEBUG_VM set, test case generic/476 has some chance to crash with the following VM_BUG_ON_FOLIO(): BTRFS error (device dm-3): cow_file_range failed, start 1146880 end 1253375 len 106496 ret -28 BTRFS error (device dm-3): run_delalloc_nocow failed, start 1146880 end 1253375 len 106496 ret -28 page: refcount:4 mapcount:0 mapping:00000000592787cc index:0x12 pfn:0x10664 aops:btrfs_aops [btrfs] ino:101 dentry name(?):"f1774" flags: 0x2fffff80004028(uptodate|lru|private|node=0|zone=2|lastcpupid=0xfffff) page dumped because: VM_BUG_ON_FOLIO(!folio_test_locked(folio)) ------------[ cut here ]------------ kernel BUG at mm/page-writeback.c:2992! Internal error: Oops - BUG: 00000000f2000800 [#1] SMP CPU: 2 UID: 0 PID: 3943513 Comm: kworker/u24:15 Tainted: G OE 6.12.0-rc7-custom+ #87 Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE Hardware name: QEMU KVM Virtual Machine, BIOS unknown 2/2/2022 Workqueue: events_unbound btrfs_async_reclaim_data_space [btrfs] pc : folio_clear_dirty_for_io+0x128/0x258 lr : folio_clear_dirty_for_io+0x128/0x258 Call trace: folio_clear_dirty_for_io+0x128/0x258 btrfs_folio_clamp_clear_dirty+0x80/0xd0 [btrfs] __process_folios_contig+0x154/0x268 [btrfs] extent_clear_unlock_delalloc+0x5c/0x80 [btrfs] run_delalloc_nocow+0x5f8/0x760 [btrfs] btrfs_run_delalloc_range+0xa8/0x220 [btrfs] writepage_delalloc+0x230/0x4c8 [btrfs] extent_writepage+0xb8/0x358 [btrfs] extent_write_cache_pages+0x21c/0x4e8 [btrfs] btrfs_writepages+0x94/0x150 [btrfs] do_writepages+0x74/0x190 filemap_fdatawrite_wbc+0x88/0xc8 start_delalloc_inodes+0x178/0x3a8 [btrfs] btrfs_start_delalloc_roots+0x174/0x280 [btrfs] shrink_delalloc+0x114/0x280 [btrfs] flush_space+0x250/0x2f8 [btrfs] btrfs_async_reclaim_data_space+0x180/0x228 [btrfs] process_one_work+0x164/0x408 worker_thread+0x25c/0x388 kthread+0x100/0x118 ret_from_fork+0x10/0x20 Code: 910a8021 a90363f7 a9046bf9 94012379 (d4210000) ---[ end trace 0000000000000000 ]--- [CAUSE] The first two lines of extra debug messages show the problem is caused by the error handling of run_delalloc_nocow(). E.g. we have the following dirtied range (4K blocksize 4K page size): 0 16K 32K |//////////////////////////////////////| | Pre-allocated | And the range [0, 16K) has a preallocated extent. - Enter run_delalloc_nocow() for range [0, 16K) Which found range [0, 16K) is preallocated, can do the proper NOCOW write. - Enter fallback_to_fow() for range [16K, 32K) Since the range [16K, 32K) is not backed by preallocated extent, we have to go COW. - cow_file_range() failed for range [16K, 32K) So cow_file_range() will do the clean up by clearing folio dirty, unlock the folios. Now the folios in range [16K, 32K) is unlocked. - Enter extent_clear_unlock_delalloc() from run_delalloc_nocow() Which is called with PAGE_START_WRITEBACK to start page writeback. But folios can only be marked writeback when it's properly locked, thus this triggered the VM_BUG_ON_FOLIO(). Furthermore there is another hidden but common bug that run_delalloc_nocow() is not clearing the folio dirty flags in its error handling path. This is the common bug shared between run_delalloc_nocow() and cow_file_range(). [FIX] - Clear folio dirty for range [@start, @cur_offset) Introduce a helper, cleanup_dirty_folios(), which will find and lock the folio in the range, clear the dirty flag and start/end the writeback, with the extra handling for the @locked_folio. - Introduce a helper to clear folio dirty, start and end writeback - Introduce a helper to record the last failed COW range end This is to trace which range we should skip, to avoid double unlocking. - Skip the failed COW range for the error handling CC: [email protected] Reviewed-by: Boris Burkov <[email protected]> Signed-off-by: Qu Wenruo <[email protected]> Signed-off-by: David Sterba <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Qu Wenruo <[email protected]> Date: Mon Nov 11 07:29:07 2024 +1030 btrfs: improve the warning and error message for btrfs_remove_qgroup() [ Upstream commit c0def46dec9c547679a25fe7552c4bcbec0b0dd2 ] [WARNING] There are several warnings about the recently introduced qgroup auto-removal that it triggers WARN_ON() for the non-zero rfer/excl numbers, e.g: ------------[ cut here ]------------ WARNING: CPU: 67 PID: 2882 at fs/btrfs/qgroup.c:1854 btrfs_remove_qgroup+0x3df/0x450 CPU: 67 UID: 0 PID: 2882 Comm: btrfs-cleaner Kdump: loaded Not tainted 6.11.6-300.fc41.x86_64 #1 RIP: 0010:btrfs_remove_qgroup+0x3df/0x450 Call Trace: <TASK> btrfs_qgroup_cleanup_dropped_subvolume+0x97/0xc0 btrfs_drop_snapshot+0x44e/0xa80 btrfs_clean_one_deleted_snapshot+0xc3/0x110 cleaner_kthread+0xd8/0x130 kthread+0xd2/0x100 ret_from_fork+0x34/0x50 ret_from_fork_asm+0x1a/0x30 </TASK> ---[ end trace 0000000000000000 ]--- BTRFS warning (device sda): to be deleted qgroup 0/319 has non-zero numbers, rfer 258478080 rfer_cmpr 258478080 excl 0 excl_cmpr 0 [CAUSE] Although the root cause is still unclear, as if qgroup is consistent a fully dropped subvolume (with extra transaction committed) should lead to all zero numbers for the qgroup. My current guess is the subvolume drop triggered the new subtree drop threshold thus marked qgroup inconsistent, then rescan cleared it but some corner case is not properly handled during subvolume dropping. But at least for this particular case, since it's only the rfer/excl not properly reset to 0, and qgroup is already marked inconsistent, there is nothing to be worried for the end users. The user space tool utilizing qgroup would queue a rescan to handle everything, so the kernel wanring is a little overkilled. [ENHANCEMENT] Enhance the warning inside btrfs_remove_qgroup() by: - Only do WARN() if CONFIG_BTRFS_DEBUG is enabled As explained the kernel can handle inconsistent qgroups by simply do a rescan, there is nothing to bother the end users. - Treat the reserved space leak the same as non-zero numbers By outputting the values and trigger a WARN() if it's a debug build. So far I haven't experienced any case related to reserved space so I hope we will never need to bother them. Fixes: 839d6ea4f86d ("btrfs: automatically remove the subvolume qgroup") Link: https://github.com/kdave/btrfs-progs/issues/922 Signed-off-by: Qu Wenruo <[email protected]> Reviewed-by: David Sterba <[email protected]> Signed-off-by: David Sterba <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Qu Wenruo <[email protected]> Date: Tue Dec 10 15:23:06 2024 +1030 btrfs: output the reason for open_ctree() failure commit d0f038104fa37380e2a725e669508e43d0c503e9 upstream. There is a recent ML report that mounting a large fs backed by hardware RAID56 controller (with one device missing) took too much time, and systemd seems to kill the mount attempt. In that case, the only error message is: BTRFS error (device sdj): open_ctree failed There is no reason on why the failure happened, making it very hard to understand the reason. At least output the error number (in the particular case it should be -EINTR) to provide some clue. Link: https://lore.kernel.org/linux-btrfs/[email protected]/ Reported-by: Christoph Anton Mitterer <[email protected]> Cc: [email protected] Reviewed-by: Filipe Manana <[email protected]> Signed-off-by: Qu Wenruo <[email protected]> Reviewed-by: David Sterba <[email protected]> Signed-off-by: David Sterba <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Qu Wenruo <[email protected]> Date: Thu Dec 12 16:44:00 2024 +1030 btrfs: subpage: fix the bitmap dump of the locked flags [ Upstream commit 396294d1afee65a203d6cabd843d0782e5d7388e ] We're dumping the locked bitmap into the @checked_bitmap variable, printing incorrect values during debug. Thankfully even during my development I haven't hit a case where I need to dump the locked bitmap. But for the sake of consistency, fix it by dupping the locked bitmap into @locked_bitmap variable for output. Fixes: 75258f20fb70 ("btrfs: subpage: dump extra subpage bitmaps for debug") Reviewed-by: Boris Burkov <[email protected]> Signed-off-by: Qu Wenruo <[email protected]> Reviewed-by: David Sterba <[email protected]> Signed-off-by: David Sterba <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Pali Rohár <[email protected]> Date: Mon Oct 14 13:43:23 2024 +0200 cifs: Fix getting and setting SACLs over SMB1 [ Upstream commit 8b19dfb34d17e77a0809d433cc128b779282131b ] SMB1 callback get_cifs_acl_by_fid() currently ignores its last argument and therefore ignores request for SACL_SECINFO. Fix this issue by correctly propagating info argument from get_cifs_acl() and get_cifs_acl_by_fid() to CIFSSMBGetCIFSACL() function and pass SACL_SECINFO when requested. For accessing SACLs it is needed to open object with SYSTEM_SECURITY access. Pass this flag when trying to get or set SACLs. Same logic is in the SMB2+ code path. This change fixes getting and setting of "system.cifs_ntsd_full" and "system.smb3_ntsd_full" xattrs over SMB1 as currently it silentely ignored SACL part of passed xattr buffer. Fixes: 3970acf7ddb9 ("SMB3: Add support for getting and setting SACLs") Signed-off-by: Pali Rohár <[email protected]> Signed-off-by: Steve French <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Pali Rohár <[email protected]> Date: Thu Jan 2 21:38:48 2025 +0100 cifs: Use cifs_autodisable_serverino() for disabling CIFS_MOUNT_SERVER_INUM in readdir.c [ Upstream commit 015683d4ed0d23698c71f2194f09bd17dbfad044 ] In all other places is used function cifs_autodisable_serverino() for disabling CIFS_MOUNT_SERVER_INUM mount flag. So use is also in readir.c _initiate_cifs_search() function. Benefit of cifs_autodisable_serverino() is that it also prints dmesg message that server inode numbers are being disabled. Fixes: ec06aedd4454 ("cifs: clean up handling when server doesn't consistently support inode numbers") Fixes: f534dc994397 ("cifs: clear server inode number flag while autodisabling") Signed-off-by: Pali Rohár <[email protected]> Signed-off-by: Steve French <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Pali Rohár <[email protected]> Date: Thu Dec 26 15:20:39 2024 +0100 cifs: Validate EAs for WSL reparse points [ Upstream commit ef201e8759d20bf82b5943101147072de12bc524 ] Major and minor numbers for char and block devices are mandatory for stat. So check that the WSL EA $LXDEV is present for WSL CHR and BLK reparse points. WSL reparse point tag determinate type of the file. But file type is present also in the WSL EA $LXMOD. So check that both file types are same. Fixes: 78e26bec4d6d ("smb: client: parse uid, gid, mode and dev from WSL reparse points") Signed-off-by: Pali Rohár <[email protected]> Signed-off-by: Steve French <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Bo Gan <[email protected]> Date: Thu Aug 29 23:16:39 2024 -0700 clk: analogbits: Fix incorrect calculation of vco rate delta [ Upstream commit d7f12857f095ef38523399d47e68787b357232f6 ] In wrpll_configure_for_rate() we try to determine the best PLL configuration for a target rate. However, in the loop where we try values of R, we should compare the derived `vco` with `target_vco_rate`. However, we were in fact comparing it with `target_rate`, which is actually after Q shift. This is incorrect, and sometimes can result in suboptimal clock rates. Fix it. Fixes: 7b9487a9a5c4 ("clk: analogbits: add Wide-Range PLL library") Signed-off-by: Bo Gan <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Stephen Boyd <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Joe Hattori <[email protected]> Date: Tue Dec 10 22:09:12 2024 +0900 clk: fix an OF node reference leak in of_clk_get_parent_name() [ Upstream commit 28fa3291cad1c201967ef93edc6e7f8ccc9afbc0 ] Current implementation of of_clk_get_parent_name() leaks an OF node reference on error path. Add a of_node_put() call before returning an error. This bug was found by an experimental static analysis tool that I am developing. Fixes: 8da411cc1964 ("clk: let of_clk_get_parent_name() fail for invalid clock-indices") Signed-off-by: Joe Hattori <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Stephen Boyd <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Marek Vasut <[email protected]> Date: Tue Nov 12 02:36:54 2024 +0100 clk: imx8mp: Fix clkout1/2 support [ Upstream commit a9b7c84d22fb1687d63ca2a386773015cf59436b ] The CLKOUTn may be fed from PLL1/2/3, but the PLL1/2/3 has to be enabled first by setting PLL_CLKE bit 11 in CCM_ANALOG_SYS_PLLn_GEN_CTRL register. The CCM_ANALOG_SYS_PLLn_GEN_CTRL bit 11 is modeled by plln_out clock. Fix the clock tree and place the clkout1/2 under plln_sel instead of plain plln to let the clock subsystem correctly control the bit 11 and enable the PLL in case the CLKOUTn is supplied by PLL1/2/3. Fixes: 43896f56b59e ("clk: imx8mp: add clkout1/2 support") Signed-off-by: Marek Vasut <[email protected]> Reviewed-by: Peng Fan <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Abel Vesa <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Shengjiu Wang <[email protected]> Date: Tue Nov 19 09:58:04 2024 +0800 clk: imx93: Add IMX93_CLK_SPDIF_IPG clock [ Upstream commit 6a7853544482e2336b5b8bb9a4b964f9d687f290 ] Split IMX93_CLK_SPDIF_IPG from IMX93_CLK_SPDIF_GATE because the IMX93_CLK_SPDIF_GATE controls the gate of IPG clock and root clock. Without this change, disabling IMX93_CLK_SPDIF_GATE would also disable the IPG clock, causing register access failures. Fixes: 1c4a4f7362fd ("arm64: dts: imx93: Add audio device nodes") Signed-off-by: Shengjiu Wang <[email protected]> Reviewed-by: Frank Li <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Abel Vesa <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Peng Fan <[email protected]> Date: Wed Dec 25 08:14:43 2024 +0800 clk: imx: Apply some clks only for i.MX93 [ Upstream commit 48806be086360846bb308c5ee21fcab8405a3da7 ] Enable the LVDS gate, MIPI DSI, PXP, FLEXIO and MU only for i.MX93, because i.MX91 does not support them. Update enet clk entry format to align with others. Fixes: a27bfff88dd2 ("clk: imx: add i.MX91 clk") Signed-off-by: Peng Fan <[email protected]> Reviewed-by: Abel Vesa <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Abel Vesa <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Dan Carpenter <[email protected]> Date: Wed Nov 20 20:18:38 2024 +0300 clk: mmp: pxa1908-apbc: Fix NULL vs IS_ERR() check [ Upstream commit e5ca5d7b4d7c29246d957dc45d63610584ae3a54 ] The devm_kzalloc() function returns NULL on error, not error pointers. Fix the check. Fixes: 51ce55919273 ("clk: mmp: Add Marvell PXA1908 APBC driver") Signed-off-by: Dan Carpenter <[email protected]> Link: https://lore.kernel.org/r/[email protected] Acked-by: Duje Mihanović <[email protected]> Signed-off-by: Stephen Boyd <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Dan Carpenter <[email protected]> Date: Wed Nov 20 20:18:44 2024 +0300 clk: mmp: pxa1908-apbcp: Fix a NULL vs IS_ERR() check [ Upstream commit 3acea81be689b77b3ceac6ff345ff0366734d967 ] The devm_kzalloc() function doesn't return error pointers, it returns NULL on error. Update the check to match. Fixes: a89233dbd4df ("clk: mmp: Add Marvell PXA1908 APBCP driver") Signed-off-by: Dan Carpenter <[email protected]> Link: https://lore.kernel.org/r/[email protected] Acked-by: Duje Mihanović <[email protected]> Signed-off-by: Stephen Boyd <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Dan Carpenter <[email protected]> Date: Wed Nov 20 20:18:50 2024 +0300 clk: mmp: pxa1908-mpmu: Fix a NULL vs IS_ERR() check [ Upstream commit 7def56f841af22e07977e193eea002e085facbdb ] The devm_kzalloc() function returns NULL on error, not error pointers. Update the check to match. Fixes: ebac87cdd230 ("clk: mmp: Add Marvell PXA1908 MPMU driver") Signed-off-by: Dan Carpenter <[email protected]> Link: https://lore.kernel.org/r/[email protected] Acked-by: Duje Mihanović <[email protected]> Signed-off-by: Stephen Boyd <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Bryan O'Donoghue <[email protected]> Date: Fri Dec 27 13:23:03 2024 +0000 clk: qcom: camcc-x1e80100: Set titan_top_gdsc as the parent GDSC of subordinate GDSCs [ Upstream commit d9377941f2732d2f6f53ec9520321a19c687717a ] The Titan TOP GDSC is the parent GDSC for all other GDSCs in the CAMCC block. None of the subordinate blocks will switch on without the parent GDSC switched on. Fixes: 76126a5129b5 ("clk: qcom: Add camcc clock driver for x1e80100") Acked-by: Rajendra Nayak <[email protected]> Reviewed-by: Konrad Dybcio <[email protected]> Signed-off-by: Bryan O'Donoghue <[email protected]> Reviewed-by: Vladimir Zapolskiy <[email protected]> Link: https://lore.kernel.org/r/20241227-b4-linux-next-24-12-16-titan-top-gdsc-v1-1-c96ef62fc307@linaro.org Signed-off-by: Bjorn Andersson <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Amit Pundir <[email protected]> Date: Mon Dec 9 23:19:12 2024 +0530 clk: qcom: gcc-sdm845: Do not use shared clk_ops for QUPs [ Upstream commit f760a4bb5e927a133dcd75f7b69ccae2a331e42c ] Similar to the earlier fixes meant for sm8x50 and x1e platforms, we have to stop using the shared clk ops for sdm845 QUPs as well. As Stephen Boyd pointed out in earlier fixes, there wasn't a problem to mark QUP clks shared until we started parking shared RCGs at clk registration time in commit 01a0a6cc8cfd ("clk: qcom: Park shared RCGs upon registration"). Parking at init is actually harmful to the UART when earlycon is used. If the device is pumping out data while the frequency changes and we see garbage on the serial console until the driver can probe and actually set a proper frequency. This patch reverts the QUP clk sharing ops part of commit 06391eddb60a ("clk: qcom: Add Global Clock controller (GCC) driver for SDM845"), so that the QUPs on sdm845 don't get parked during clk registration and break UART operations. Fixes: 01a0a6cc8cfd ("clk: qcom: Park shared RCGs upon registration") Signed-off-by: Amit Pundir <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bjorn Andersson <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Abel Vesa <[email protected]> Date: Tue Jan 7 17:55:23 2025 +0200 clk: qcom: gcc-x1e80100: Do not turn off usb_2 controller GDSC commit d26c4ad3fa53e76a602a9974ade171c8399f2a29 upstream. Allowing the usb_2 controller GDSC to be turned off during system suspend renders the controller unable to resume. So use PWRSTS_RET_ON instead in order to make sure this the GDSC doesn't go down. Fixes: 161b7c401f4b ("clk: qcom: Add Global Clock controller (GCC) driver for X1E80100") Cc: [email protected] # 6.8 Signed-off-by: Abel Vesa <[email protected]> Reviewed-by: Johan Hovold <[email protected]> Tested-by: Johan Hovold <[email protected]> Link: https://lore.kernel.org/r/20250107-x1e80100-clk-gcc-fix-usb2-gdsc-pwrsts-v1-1-e15d1a5e7d80@linaro.org Signed-off-by: Bjorn Andersson <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Sergio Paracuellos <[email protected]> Date: Wed Jan 8 10:36:36 2025 +0100 clk: ralink: mtmips: remove duplicated 'xtal' clock for Ralink SoC RT3883 [ Upstream commit 830d8062d25581cf0beaa334486eea06834044da ] Ralink SoC RT3883 has already 'xtal' defined as a base clock so there is no need to redefine it again in fixed clocks section. Hence, remove the duplicate one from there. Fixes: d34db686a3d7 ("clk: ralink: mtmips: fix clocks probe order in oldest ralink SoCs") Signed-off-by: Sergio Paracuellos <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Stephen Boyd <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Javier Carrasco <[email protected]> Date: Thu Oct 31 13:43:16 2024 +0100 clk: renesas: cpg-mssr: Fix 'soc' node handling in cpg_mssr_reserved_init() [ Upstream commit a6ca7e6240f0651412da6a17d0e7a8f66d3455a6 ] A device_node reference obtained via of_find_node_by_path() requires explicit calls to of_node_put() after it is no longer required to avoid leaking the resource. Instead of adding the missing calls to of_node_put() in all execution paths, use the cleanup attribute for 'soc' by means of the __free() macro, which automatically calls of_node_put() when the variable goes out of scope. Fixes: 6aa175476490 ("clk: renesas: cpg-mssr: Ignore all clocks assigned to non-Linux system") Signed-off-by: Javier Carrasco <[email protected]> Reviewed-by: Geert Uytterhoeven <[email protected]> Link: https://lore.kernel.org/20241031-clk-renesas-cpg-mssr-cleanup-v2-1-0010936d1154@gmail.com Signed-off-by: Geert Uytterhoeven <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Vasily Khoruzhick <[email protected]> Date: Fri Jan 3 23:37:00 2025 -0800 clk: sunxi-ng: a64: stop force-selecting PLL-MIPI as TCON0 parent [ Upstream commit 383ca7bee8a93be9ff5a072936981c2710d2856b ] Stop force-selecting PLL-MIPI as TCON0 parent, since it breaks video output on Pinebook that uses RGB to eDP bridge. Partially revert commit ca1170b69968 ("clk: sunxi-ng: a64: force select PLL_MIPI in TCON0 mux"), while still leaving CLK_SET_RATE_NO_REPARENT flag set, since we do not want the clock to be reparented. The issue is that apparently different TCON0 outputs require a different clock, or the mux might be selecting the output type. I did an experiment: I manually configured PLL_MIPI and PLL_VIDEO0_2X to the same clock rate and flipped the switch with devmem. Experiment clearly showed that whenever PLL_MIPI is selected as TCON0 clock parent, the video output stops working. Therefore, TCON0 clock parent corresponding to the output type must be assigned in the device tree. Fixes: ca1170b69968 ("clk: sunxi-ng: a64: force select PLL_MIPI in TCON0 mux") Reviewed-by: Dragan Simic <[email protected]> Reviewed-by: Chen-Yu Tsai <[email protected]> Tested-by: Frank Oltmanns <[email protected]> # on PinePhone Tested-by: Stuart Gathman <[email protected]> # on OG Pinebook Signed-off-by: Vasily Khoruzhick <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Chen-Yu Tsai <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Drew Fustini <[email protected]> Date: Mon Jan 13 12:31:25 2025 -0800 clk: thead: Add CLK_IGNORE_UNUSED to fix TH1520 boot [ Upstream commit 037705e94bf6e1810b7f9dc077d0e23292229e74 ] Add the CLK_IGNORE_UNUSED flag to apb_pclk, cpu2peri_x2h_clk, perisys_apb2_hclk and perisys_apb3_hclk. Without this flag, the boot hangs after "clk: Disabling unused clocks" unless clk_ignore_unused is in the kernel cmdline. Fixes: ae81b69fd2b1 ("clk: thead: Add support for T-Head TH1520 AP_SUBSYS clocks") Signed-off-by: Drew Fustini <[email protected]> Link: https://lore.kernel.org/r/20250113-th1520-clk_ignore_unused-v1-2-0b08fb813438@tenstorrent.com Signed-off-by: Stephen Boyd <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Drew Fustini <[email protected]> Date: Mon Jan 13 12:31:24 2025 -0800 clk: thead: Fix clk gate registration to pass flags [ Upstream commit a826e53fd78c7f07b8ff83446c44b227b2181920 ] Modify the call to devm_clk_hw_register_gate_parent_data() to actually pass the clk flags from hw.init instead of just 0. This is necessary to allow individual clk gates to specify their own clk flags. Fixes: ae81b69fd2b1 ("clk: thead: Add support for T-Head TH1520 AP_SUBSYS clocks") Signed-off-by: Drew Fustini <[email protected]> Link: https://lore.kernel.org/r/20250113-th1520-clk_ignore_unused-v1-1-0b08fb813438@tenstorrent.com Signed-off-by: Stephen Boyd <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Drew Fustini <[email protected]> Date: Fri Dec 27 19:48:04 2024 -0800 clk: thead: Fix cpu2vp_clk for TH1520 AP_SUBSYS clocks [ Upstream commit 3a43cd19f1b8d3f57f835ae50cc869f07902c062 ] cpu2vp_clk is a gate but was mistakenly in th1520_div_clks[] instead of th1520_gate_clks[]. Fixes: ae81b69fd2b1 ("clk: thead: Add support for T-Head TH1520 AP_SUBSYS clocks") Signed-off-by: Drew Fustini <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Stephen Boyd <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Kees Cook <[email protected]> Date: Sat Sep 28 14:08:31 2024 -0700 coredump: Do not lock during 'comm' reporting [ Upstream commit 200f091c95bbc4b8660636bd345805c45d6eced7 ] The 'comm' member will always be NUL terminated, and this is not fast-path, so we can just perform a direct memcpy during a coredump instead of potentially deadlocking while holding the task struct lock. Reported-by: Vegard Nossum <[email protected]> Closes: https://lore.kernel.org/all/[email protected] Fixes: c114e9948c2b ("coredump: Standartize and fix logging") Tested-by: Vegard Nossum <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Kees Cook <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Mario Limonciello <[email protected]> Date: Thu Jan 2 08:12:04 2025 -0600 cpufreq/amd-pstate: Fix prefcore rankings [ Upstream commit fd604ae6c261c5a56bb977ae99f875bbd7264a3f ] commit 50a062a76200 ("cpufreq/amd-pstate: Store the boost numerator as highest perf again") updated the value stored for highest perf to no longer store the highest perf value but instead the boost numerator. This is a fixed value for systems with preferred cores and not appropriate for use ITMT rankings. Update the value used for ITMT rankings to be the preferred core ranking. Reported-and-tested-by: Sebastian <[email protected]> Closes: https://bugzilla.kernel.org/show_bug.cgi?id=219640 Fixes: 50a062a76200 ("cpufreq/amd-pstate: Store the boost numerator as highest perf again") Reviewed-by: Dhananjay Ugwekar <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mario Limonciello <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Gautham R. Shenoy <[email protected]> Date: Mon Jan 13 10:11:07 2025 +0530 cpufreq: ACPI: Fix max-frequency computation [ Upstream commit 0834667545962ef1c5e8684ed32b45d9c574acd3 ] Commit 3c55e94c0ade ("cpufreq: ACPI: Extend frequency tables to cover boost frequencies") introduced an assumption in acpi_cpufreq_cpu_init() that the first entry in the P-state table was the nominal frequency. This assumption is incorrect. The frequency corresponding to the P0 P-State need not be the same as the nominal frequency advertised via CPPC. Since the driver is using the CPPC.highest_perf and CPPC.nominal_perf to compute the boost-ratio, it makes sense to use CPPC.nominal_freq to compute the max-frequency. CPPC.nominal_freq is advertised on platforms supporting CPPC revisions 3 or higher. Hence, fallback to using the first entry in the P-State table only on platforms that do not advertise CPPC.nominal_freq. Fixes: 3c55e94c0ade ("cpufreq: ACPI: Extend frequency tables to cover boost frequencies") Tested-by: Dhananjay Ugwekar <[email protected]> Signed-off-by: Gautham R. Shenoy <[email protected]> Reviewed-by: Mario Limonciello <[email protected]> Link: https://patch.msgid.link/[email protected] [ rjw: Retain reverse X-mas tree ordering of local variable declarations ] [ rjw: Subject and changelog edits ] Signed-off-by: Rafael J. Wysocki <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Manivannan Sadhasivam <[email protected]> Date: Thu Dec 5 22:20:28 2024 +0530 cpufreq: qcom: Fix qcom_cpufreq_hw_recalc_rate() to query LUT if LMh IRQ is not available [ Upstream commit 85d8b11351a8f15d6ec7a5e97909861cb3b6bcec ] Currently, qcom_cpufreq_hw_recalc_rate() returns the LMh throttled frequency for the domain even if LMh IRQ is not available. But as per qcom_cpufreq_hw_get(), the driver has to query LUT entries to get the actual frequency of the domain. So do the same in qcom_cpufreq_hw_recalc_rate(). While doing so, refactor the existing qcom_cpufreq_hw_get() function so that qcom_cpufreq_hw_recalc_rate() can make use of the existing code and avoid code duplication. This also requires setting the qcom_cpufreq_data::policy even if LMh IRQ is not available. Fixes: 4370232c727b ("cpufreq: qcom-hw: Add CPU clock provider support") Signed-off-by: Manivannan Sadhasivam <[email protected]> Signed-off-by: Viresh Kumar <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Manivannan Sadhasivam <[email protected]> Date: Thu Dec 5 22:20:29 2024 +0530 cpufreq: qcom: Implement clk_ops::determine_rate() for qcom_cpufreq* clocks [ Upstream commit a9ba290d0b829012574b6821ba08815046e60c94 ] determine_rate() callback is used by the clk_set_rate() API to get the closest rate of the target rate supported by the clock. If this callback is not implemented (nor round_rate() callback), then the API will assume that the clock cannot set the requested rate. And since there is no parent, it will return -EINVAL. This is not an issue right now as clk_set_rate() mistakenly compares the target rate with cached rate and bails out early. But once that is fixed to compare the target rate with the actual rate of the clock (returned by recalc_rate()), then clk_set_rate() for this clock will start to fail as below: cpu cpu0: _opp_config_clk_single: failed to set clock rate: -22 So implement the determine_rate() callback that just returns the actual rate at which the clock is passed to the CPUs in a domain. Fixes: 4370232c727b ("cpufreq: qcom-hw: Add CPU clock provider support") Reported-by: Johan Hovold <[email protected]> Suggested-by: Stephen Boyd <[email protected]> Signed-off-by: Manivannan Sadhasivam <[email protected]> Reviewed-by: Stephen Boyd <[email protected]> Signed-off-by: Viresh Kumar <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Sultan Alsawaf (unemployed) <[email protected]> Date: Wed Dec 11 17:57:32 2024 -0800 cpufreq: schedutil: Fix superfluous updates caused by need_freq_update [ Upstream commit 8e461a1cb43d69d2fc8a97e61916dce571e6bb31 ] A redundant frequency update is only truly needed when there is a policy limits change with a driver that specifies CPUFREQ_NEED_UPDATE_LIMITS. In spite of that, drivers specifying CPUFREQ_NEED_UPDATE_LIMITS receive a frequency update _all the time_, not just for a policy limits change, because need_freq_update is never cleared. Furthermore, ignore_dl_rate_limit()'s usage of need_freq_update also leads to a redundant frequency update, regardless of whether or not the driver specifies CPUFREQ_NEED_UPDATE_LIMITS, when the next chosen frequency is the same as the current one. Fix the superfluous updates by only honoring CPUFREQ_NEED_UPDATE_LIMITS when there's a policy limits change, and clearing need_freq_update when a requisite redundant update occurs. This is neatly achieved by moving up the CPUFREQ_NEED_UPDATE_LIMITS test and instead setting need_freq_update to false in sugov_update_next_freq(). Fixes: 600f5badb78c ("cpufreq: schedutil: Don't skip freq update when limits change") Signed-off-by: Sultan Alsawaf (unemployed) <[email protected]> Reviewed-by: Christian Loehle <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Rafael J. Wysocki <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: He Rongguang <[email protected]> Date: Thu Dec 12 10:14:59 2024 +0800 cpupower: fix TSC MHz calculation [ Upstream commit 9d6c0e58514f8b57cd9c2c755e41623d6a966025 ] Commit 'cpupower: Make TSC read per CPU for Mperf monitor' (c2adb1877b7) changes TSC counter reads per cpu, but left time diff global (from start of all cpus to end of all cpus), thus diff(time) is too large for a cpu's tsc counting, resulting in far less than acutal TSC_Mhz and thus `cpupower monitor` showing far less than actual cpu realtime frequency. /proc/cpuinfo shows frequency: cat /proc/cpuinfo | egrep -e 'processor' -e 'MHz' ... processor : 171 cpu MHz : 4108.498 ... before fix (System 100% busy): | Mperf || Idle_Stats CPU| C0 | Cx | Freq || POLL | C1 | C2 171| 0.77| 99.23| 2279|| 0.00| 0.00| 0.00 after fix (System 100% busy): | Mperf || Idle_Stats CPU| C0 | Cx | Freq || POLL | C1 | C2 171| 0.46| 99.54| 4095|| 0.00| 0.00| 0.00 Fixes: c2adb1877b76 ("cpupower: Make TSC read per CPU for Mperf monitor") Signed-off-by: He Rongguang <[email protected]> Signed-off-by: Shuah Khan <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Herbert Xu <[email protected]> Date: Fri Nov 15 09:29:02 2024 +0800 crypto: api - Fix boot-up self-test race [ Upstream commit 8dd458cbc5be9ce4427ffce7a9dcdbff4dfc4ac9 ] During the boot process self-tests are postponed so that all algorithms are registered when the test starts. In the event that algorithms are still being registered during these tests, which can occur either because the algorithm is registered at late_initcall, or because a self-test itself triggers the creation of an instance, some self-tests may never start at all. Fix this by setting the flag at the start of crypto_start_tests. Note that this race is theoretical and has never been observed in practice. Fixes: adad556efcdd ("crypto: api - Fix built-in testing dependency failures") Signed-off-by: Herbert Xu <[email protected]> Signed-off-by: Herbert Xu <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Gaurav Jain <[email protected]> Date: Tue Nov 26 12:16:07 2024 +0530 crypto: caam - use JobR's space to access page 0 regs [ Upstream commit 73a7496c218b7ca19ba276f54758e7f0adf269c5 ] On iMX8DXL/QM/QXP(SECO) & iMX8ULP(ELE) SoCs, access to controller region(CAAM page 0) is not permitted from non secure world. use JobR's register space to access page 0 registers. Fixes: 6a83830f649a ("crypto: caam - warn if blob_gen key is insecure") Signed-off-by: Gaurav Jain <[email protected]> Reviewed-by: Ahmad Fatoum <[email protected]> Reviewed-by: Horia Geantă <[email protected]> Signed-off-by: Herbert Xu <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Wenkai Lin <[email protected]> Date: Fri Dec 13 17:13:34 2024 +0800 crypto: hisilicon/sec2 - fix for aead icv error [ Upstream commit fd337f852b2677b53d0859a47b58e6e6bd189f30 ] When the AEAD algorithm is used for encryption or decryption, the input authentication length varies, the hardware needs to obtain the input length to pass the integrity check verification. Currently, the driver uses a fixed authentication length,which causes decryption failure, so the length configuration is modified. In addition, the step of setting the auth length is unnecessary, so it was deleted from the setkey function. Fixes: 2f072d75d1ab ("crypto: hisilicon - Add aead support on SEC2") Signed-off-by: Wenkai Lin <[email protected]> Signed-off-by: Chenghai Huang <[email protected]> Signed-off-by: Herbert Xu <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Wenkai Lin <[email protected]> Date: Fri Dec 13 17:13:35 2024 +0800 crypto: hisilicon/sec2 - fix for aead invalid authsize [ Upstream commit a5a9d959936499a3106a1bf3b9070875d0d3dec4 ] When the digest alg is HMAC-SHAx or another, the authsize may be less than 4 bytes and mac_len of the BD is set to zero, the hardware considers it a BD configuration error and reports a ras error, so the sec driver needs to switch to software calculation in this case, this patch add a check for it and remove unnecessary check that has been done by crypto. Fixes: 2f072d75d1ab ("crypto: hisilicon - Add aead support on SEC2") Signed-off-by: Wenkai Lin <[email protected]> Signed-off-by: Chenghai Huang <[email protected]> Signed-off-by: Herbert Xu <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Kanchana P Sridhar <[email protected]> Date: Sat Dec 21 14:07:07 2024 -0800 crypto: iaa - Fix IAA disabling that occurs when sync_mode is set to 'async' [ Upstream commit 4ebd9a5ca478673cfbb38795cc5b3adb4f35fe04 ] With the latest mm-unstable, setting the iaa_crypto sync_mode to 'async' causes crypto testmgr.c test_acomp() failure and dmesg call traces, and zswap being unable to use 'deflate-iaa' as a compressor: echo async > /sys/bus/dsa/drivers/crypto/sync_mode [ 255.271030] zswap: compressor deflate-iaa not available [ 369.960673] INFO: task cryptomgr_test:4889 blocked for more than 122 seconds. [ 369.970127] Not tainted 6.13.0-rc1-mm-unstable-12-16-2024+ #324 [ 369.977411] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 369.986246] task:cryptomgr_test state:D stack:0 pid:4889 tgid:4889 ppid:2 flags:0x00004000 [ 369.986253] Call Trace: [ 369.986256] <TASK> [ 369.986260] __schedule+0x45c/0xfa0 [ 369.986273] schedule+0x2e/0xb0 [ 369.986277] schedule_timeout+0xe7/0x100 [ 369.986284] ? __prepare_to_swait+0x4e/0x70 [ 369.986290] wait_for_completion+0x8d/0x120 [ 369.986293] test_acomp+0x284/0x670 [ 369.986305] ? __pfx_cryptomgr_test+0x10/0x10 [ 369.986312] alg_test_comp+0x263/0x440 [ 369.986315] ? sched_balance_newidle+0x259/0x430 [ 369.986320] ? __pfx_cryptomgr_test+0x10/0x10 [ 369.986323] alg_test.part.27+0x103/0x410 [ 369.986326] ? __schedule+0x464/0xfa0 [ 369.986330] ? __pfx_cryptomgr_test+0x10/0x10 [ 369.986333] cryptomgr_test+0x20/0x40 [ 369.986336] kthread+0xda/0x110 [ 369.986344] ? __pfx_kthread+0x10/0x10 [ 369.986346] ret_from_fork+0x2d/0x40 [ 369.986355] ? __pfx_kthread+0x10/0x10 [ 369.986358] ret_from_fork_asm+0x1a/0x30 [ 369.986365] </TASK> This happens because the only async polling without interrupts that iaa_crypto currently implements is with the 'sync' mode. With 'async', iaa_crypto calls to compress/decompress submit the descriptor and return -EINPROGRESS, without any mechanism in the driver to poll for completions. Hence callers such as test_acomp() in crypto/testmgr.c or zswap, that wrap the calls to crypto_acomp_compress() and crypto_acomp_decompress() in synchronous wrappers, will block indefinitely. Even before zswap can notice this problem, the crypto testmgr.c's test_acomp() will fail and prevent registration of "deflate-iaa" as a valid crypto acomp algorithm, thereby disallowing the use of "deflate-iaa" as a zswap compress (zswap will fall-back to the default compressor in this case). To fix this issue, this patch modifies the iaa_crypto sync_mode set function to treat 'async' equivalent to 'sync', so that the correct and only supported driver async polling without interrupts implementation is enabled, and zswap can use 'deflate-iaa' as the compressor. Hence, with this patch, this is what will happen: echo async > /sys/bus/dsa/drivers/crypto/sync_mode cat /sys/bus/dsa/drivers/crypto/sync_mode sync There are no crypto/testmgr.c test_acomp() errors, no call traces and zswap can use 'deflate-iaa' without any errors. The iaa_crypto documentation has also been updated to mention this caveat with 'async' and what to expect with this fix. True iaa_crypto async polling without interrupts is enabled in patch "crypto: iaa - Implement batch_compress(), batch_decompress() API in iaa_crypto." [1] which is under review as part of the "zswap IAA compress batching" patch-series [2]. Until this is merged, we would appreciate it if this current patch can be considered for a hotfix. [1]: https://patchwork.kernel.org/project/linux-mm/patch/[email protected]/ [2]: https://patchwork.kernel.org/project/linux-mm/list/?series=920084 Fixes: 09646c98d ("crypto: iaa - Add irq support for the crypto async interface") Signed-off-by: Kanchana P Sridhar <[email protected]> Signed-off-by: Herbert Xu <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Joe Hattori <[email protected]> Date: Sun Dec 15 16:27:20 2024 +0900 crypto: ixp4xx - fix OF node reference leaks in init_ixp_crypto() [ Upstream commit 472a989029aac2b78ef2f0b18b27c568bf76d104 ] init_ixp_crypto() calls of_parse_phandle_with_fixed_args() multiple times, but does not release all the obtained refcounts. Fix it by adding of_node_put() calls. This bug was found by an experimental static analysis tool that I am developing. Fixes: 76f24b4f46b8 ("crypto: ixp4xx - Add device tree support") Signed-off-by: Joe Hattori <[email protected]> Signed-off-by: Herbert Xu <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Chen Ridong <[email protected]> Date: Mon Nov 11 01:28:27 2024 +0000 crypto: tegra - do not transfer req when tegra init fails [ Upstream commit 15589bda46830695a3261518bb7627afac61f519 ] The tegra_cmac_init or tegra_sha_init function may return an error when memory is exhausted. It should not transfer the request when they return an error. Fixes: 0880bb3b00c8 ("crypto: tegra - Add Tegra Security Engine driver") Signed-off-by: Chen Ridong <[email protected]> Acked-by: Akhil R <[email protected]> Acked-by: Thierry Reding <[email protected]> Signed-off-by: Herbert Xu <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Kuniyuki Iwashima <[email protected]> Date: Wed Jan 15 18:55:43 2025 +0900 dev: Acquire netdev_rename_lock before restoring dev->name in dev_change_name(). [ Upstream commit e361560a7912958ba3059f51e7dd21612d119169 ] The cited commit forgot to add netdev_rename_lock in one of the error paths in dev_change_name(). Let's hold netdev_rename_lock before restoring the old dev->name. Fixes: 0840556e5a3a ("net: Protect dev->name by seqlock.") Signed-off-by: Kuniyuki Iwashima <[email protected]> Reviewed-by: Eric Dumazet <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Alexander Aring <[email protected]> Date: Tue Nov 19 15:56:44 2024 -0500 dlm: fix removal of rsb struct that is master and dir record [ Upstream commit 134129520beaf3339482c557361ea0bde709cf36 ] An rsb struct was not being removed in the case where it was both the master and the dir record. This case (master and dir node) was missed in the condition for doing add_scan() from deactivate_rsb(). Fixing this triggers a related WARN_ON that needs to be fixed, and requires adjusting where two del_scan() calls are made. Fixes: c217adfc8caa ("dlm: fix add_scan and del_scan usage") Signed-off-by: Alexander Aring <[email protected]> Signed-off-by: David Teigland <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Alexander Aring <[email protected]> Date: Mon Dec 2 10:26:37 2024 -0500 dlm: fix srcu_read_lock() return type to int [ Upstream commit 57cdd1a1cf1464199678f9338049b63fb5d5b41c ] The return type of srcu_read_lock() is int and not bool. Whereas we using the ret variable only to evaluate a bool type of dlm_lowcomms_con_has_addr() to check if an address is already being set. Fixes: 6f0b0b5d7ae7 ("fs: dlm: remove dlm_node_addrs lookup list") Signed-off-by: Alexander Aring <[email protected]> Signed-off-by: David Teigland <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Joe Hattori <[email protected]> Date: Thu Dec 19 11:05:07 2024 +0900 dmaengine: ti: edma: fix OF node reference leaks in edma_driver [ Upstream commit e883c64778e5a9905fce955681f8ee38c7197e0f ] The .probe() of edma_driver calls of_parse_phandle_with_fixed_args() but does not release the obtained OF nodes. Thus add a of_node_put() call. This bug was found by an experimental verification tool that I am developing. Fixes: 1be5336bc7ba ("dmaengine: edma: New device tree binding") Signed-off-by: Joe Hattori <[email protected]> Reviewed-by: Dan Carpenter <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Vinod Koul <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Zijun Hu <[email protected]> Date: Sun Jan 5 16:34:02 2025 +0800 driver core: class: Fix wild pointer dereferences in API class_dev_iter_next() [ Upstream commit e128f82f7006991c99a58114f70ef61e937b1ac1 ] There are a potential wild pointer dereferences issue regarding APIs class_dev_iter_(init|next|exit)(), as explained by below typical usage: // All members of @iter are wild pointers. struct class_dev_iter iter; // class_dev_iter_init(@iter, @class, ...) checks parameter @class for // potential class_to_subsys() error, and it returns void type and does // not initialize its output parameter @iter, so caller can not detect // the error and continues to invoke class_dev_iter_next(@iter) even if // @iter still contains wild pointers. class_dev_iter_init(&iter, ...); // Dereference these wild pointers in @iter here once suffer the error. while (dev = class_dev_iter_next(&iter)) { ... }; // Also dereference these wild pointers here. class_dev_iter_exit(&iter); Actually, all callers of these APIs have such usage pattern in kernel tree. Fix by: - Initialize output parameter @iter by memset() in class_dev_iter_init() and give callers prompt by pr_crit() for the error. - Check if @iter is valid in class_dev_iter_next(). Fixes: 7b884b7f24b4 ("driver core: class.c: convert to only use class_to_subsys") Reviewed-by: Jonathan Cameron <[email protected]> Signed-off-by: Zijun Hu <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Sean Rhodes <[email protected]> Date: Tue Nov 19 08:58:15 2024 +0000 drivers/card_reader/rtsx_usb: Restore interrupt based detection commit 235b630eda072d7e7b102ab346d6b8a2c028a772 upstream. This commit reintroduces interrupt-based card detection previously used in the rts5139 driver. This functionality was removed in commit 00d8521dcd23 ("staging: remove rts5139 driver code"). Reintroducing this mechanism fixes presence detection for certain card readers, which with the current driver, will taken approximately 20 seconds to enter S3 as `mmc_rescan` has to be frozen. Fixes: 00d8521dcd23 ("staging: remove rts5139 driver code") Cc: [email protected] Cc: Arnd Bergmann <[email protected]> Cc: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sean Rhodes <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Aric Cyr <[email protected]> Date: Thu Jan 9 15:03:48 2025 -0500 drm/amd/display: Add hubp cache reset when powergating commit 01130f5260e5868fb6b15ab8c00dbc894139f48e upstream. [Why] When HUBP is power gated, the SW state can get out of sync with the hardware state causing cursor to not be programmed correctly. [How] Similar to DPP, add a HUBP reset function which is called wherever HUBP is initialized or powergated. This function will clear the cursor position and attribute cache allowing for proper programming when the HUBP is brought back up. Cc: Mario Limonciello <[email protected]> Cc: Alex Deucher <[email protected]> Cc: [email protected] Reviewed-by: Sung Lee <[email protected]> Signed-off-by: Aric Cyr <[email protected]> Signed-off-by: Wayne Lin <[email protected]> Tested-by: Daniel Wheeler <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Melissa Wen <[email protected]> Date: Mon Jan 27 21:41:10 2025 -0300 drm/amd/display: restore invalid MSA timing check for freesync commit 7f2b5237e313e39008a85b33ca94ab503a8fdff9 upstream. This restores the original behavior that gets min/max freq from EDID and only set DP/eDP connector as freesync capable if "sink device is capable of rendering incoming video stream without MSA timing parameters", i.e., `allow_invalid_MSA_timing_params` is true. The condition was mistakenly removed by 0159f88a99c9 ("drm/amd/display: remove redundant freesync parser for DP"). CC: Mario Limonciello <[email protected]> CC: Alex Hung <[email protected]> Link: https://gitlab.freedesktop.org/drm/amd/-/issues/3915 Fixes: 0159f88a99c9 ("drm/amd/display: remove redundant freesync parser for DP") Reviewed-by: Harry Wentland <[email protected]> Signed-off-by: Melissa Wen <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Cc: [email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Christophe JAILLET <[email protected]> Date: Tue Nov 19 21:23:18 2024 +0100 drm/amd/pm: Fix an error handling path in vega10_enable_se_edc_force_stall_config() [ Upstream commit a3300782d5375e280ba7040f323d01960bfe3396 ] In case of error after a amdgpu_gfx_rlc_enter_safe_mode() call, it is not balanced by a corresponding amdgpu_gfx_rlc_exit_safe_mode() call. Add the missing call. Fixes: 9b7b8154cdb8 ("drm/amd/powerplay: added didt support for vega10") Signed-off-by: Christophe JAILLET <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Bokun Zhang <[email protected]> Date: Wed Dec 11 15:42:56 2024 -0600 drm/amdgpu/vcn: reset fw_shared under SRIOV [ Upstream commit 3676f37a88432132bcff55a17dc48911239b6d98 ] - The previous patch only considered the case for baremetal and is not applicable for SRIOV code path. We also need to init fw_share for SRIOV VF Fixes: 928cd772e18f ("drm/amdgpu/vcn: reset fw_shared when VCPU buffers corrupted on vcn v4.0.3") Acked-by: Alex Deucher <[email protected]> Signed-off-by: Bokun Zhang <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Jonathan Kim <[email protected]> Date: Wed Jan 8 14:39:58 2025 -0500 drm/amdgpu: fix gpu recovery disable with per queue reset [ Upstream commit 86bde64cb7957be393f84e5d35fb8dfc91e4ae7e ] Per queue reset should be bypassed when gpu recovery is disabled with module parameter. Fixes: ee0a469cf917 ("drm/amdkfd: support per-queue reset on gfx9") Signed-off-by: Jonathan Kim <[email protected]> Reviewed-by: Alex Deucher <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Karol Przybylski <[email protected]> Date: Sun Dec 15 13:28:57 2024 +0100 drm/amdgpu: Fix potential integer overflow in scheduler mask calculations [ Upstream commit 34c4eb7d4e0cd443399a0f114d467d2b3ff05419 ] The use of 1 << i in scheduler mask calculations can result in an unintentional integer overflow due to the expression being evaluated as a 32-bit signed integer. This patch replaces 1 << i with 1ULL << i to ensure the operation is performed as a 64-bit unsigned integer, preventing overflow Discovered in coverity scan, CID 1636393, 1636175, 1636007, 1635853 Fixes: c5c63d9cb5d3 ("drm/amdgpu: add amdgpu_gfx_sched_mask and amdgpu_compute_sched_mask debugfs") Signed-off-by: Karol Przybylski <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Ivan Stepchenko <[email protected]> Date: Mon Dec 2 11:00:43 2024 +0300 drm/amdgpu: Fix potential NULL pointer dereference in atomctrl_get_smc_sclk_range_table [ Upstream commit 357445e28ff004d7f10967aa93ddb4bffa5c3688 ] The function atomctrl_get_smc_sclk_range_table() does not check the return value of smu_atom_get_data_table(). If smu_atom_get_data_table() fails to retrieve SMU_Info table, it returns NULL which is later dereferenced. Found by Linux Verification Center (linuxtesting.org) with SVACE. In practice this should never happen as this code only gets called on polaris chips and the vbios data table will always be present on those chips. Fixes: a23eefa2f461 ("drm/amd/powerplay: enable dpm for baffin.") Signed-off-by: Ivan Stepchenko <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Dan Carpenter <[email protected]> Date: Wed Jan 8 12:41:28 2025 +0300 drm/amdgpu: Fix shift type in amdgpu_debugfs_sdma_sched_mask_set() [ Upstream commit 6ec6cd9acbaa844391a1f75a824a3a9d18978fcb ] The "mask" and "val" variables are type u64. The problem is that the BIT() macros are type unsigned long which is just 32 bits on 32bit systems. It's unlikely that people will be using this driver on 32bit kernels and even if they did we only use the lower AMDGPU_MAX_SDMA_INSTANCES (16) bits. So this bug does not affect anything in real life. Still, for correctness sake, u64 bit masks should use BIT_ULL(). Fixes: d2e3961ae371 ("drm/amdgpu: add amdgpu_sdma_sched_mask debugfs") Signed-off-by: Dan Carpenter <[email protected]> Reviewed-by: Mario Limonciello <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mario Limonciello <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Jiang Liu <[email protected]> Date: Mon Dec 23 00:27:21 2024 +0800 drm/amdgpu: tear down ttm range manager for doorbell in amdgpu_ttm_fini() [ Upstream commit 60a2c0c12b644450e420ffc42291d1eb248bacb7 ] Tear down ttm range manager for doorbell in function amdgpu_ttm_fini(), to avoid memory leakage. Fixes: 792b84fb9038 ("drm/amdgpu: initialize ttm for doorbells") Signed-off-by: Jiang Liu <[email protected]> Signed-off-by: Kent Russell <[email protected]> Reviewed-by: Alex Deucher <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Hermes Wu <[email protected]> Date: Mon Dec 30 18:51:19 2024 +0800 drm/bridge: it6505: Change definition of AUX_FIFO_MAX_SIZE [ Upstream commit c14870218c14532b0f0a7805b96a4d3c92d06fb2 ] The hardware AUX FIFO is 16 bytes Change definition of AUX_FIFO_MAX_SIZE to 16 Fixes: b5c84a9edcd4 ("drm/bridge: add it6505 driver") Reviewed-by: Dmitry Baryshkov <[email protected]> Signed-off-by: Hermes Wu <[email protected]> Reviewed-by: AngeloGioacchino Del Regno <[email protected]> Signed-off-by: Dmitry Baryshkov <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/20241230-v7-upstream-v7-1-e0fdd4844703@ite.corp-partner.google.com Signed-off-by: Sasha Levin <[email protected]>
Author: Derek Foreman <[email protected]> Date: Mon Dec 2 12:19:39 2024 -0600 drm/connector: Allow clearing HDMI infoframes [ Upstream commit d34357743b360c99903b5a59daab08f55b2f41a1 ] Our infoframe setting code currently lacks the ability to clear infoframes. For some of the infoframes, we only need to replace them, so if an error occurred when generating a new infoframe we would leave a stale frame instead of clearing the frame. However, the Dynamic Range and Mastering (DRM) infoframe should only be present when displaying HDR content (ie: the HDR_OUTPUT_METADATA blob is set). If we can't clear infoframes, the stale DRM infoframe will remain and we can never set the display back to SDR mode. With this change, we clear infoframes when they can not, or should not, be generated. This fixes switching to an SDR mode from an HDR one. Fixes: f378b77227bc ("drm/connector: hdmi: Add Infoframes generation") Signed-off-by: Derek Foreman <[email protected]> Reviewed-by: AngeloGioacchino Del Regno <[email protected]> Reviewed-by: Dmitry Baryshkov <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Maxime Ripard <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Sui Jingfeng <[email protected]> Date: Mon Nov 4 08:41:56 2024 +0800 drm/etnaviv: Fix page property being used for non writecombine buffers [ Upstream commit 834f304192834d6f0941954f3277ae0ba11a9a86 ] In the etnaviv_gem_vmap_impl() function, the driver vmap whatever buffers with write combine(WC) page property, this is incorrect. Cached buffers should be mapped with the cached page property and uncached buffers should be mapped with the uncached page property. Fixes: a0a5ab3e99b8 ("drm/etnaviv: call correct function when trying to vmap a DMABUF") Signed-off-by: Sui Jingfeng <[email protected]> Signed-off-by: Lucas Stach <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Ville Syrjälä <[email protected]> Date: Thu Nov 7 18:11:14 2024 +0200 drm/i915: Grab intel_display from the encoder to avoid potential oopsies [ Upstream commit dc3806d9eb66d0105f8d55d462d4ef681d9eac59 ] Grab the intel_display from 'encoder' rather than 'state' in the encoder hooks to avoid the massive footgun that is intel_sanitize_encoder(), which passes NULL as the 'state' argument to encoder .disable() and .post_disable(). TODO: figure out how to actually fix intel_sanitize_encoder()... Fixes: 40eb34c3f491 ("drm/i915/crt: convert to struct intel_display") Fixes: ab0b0eb5c85c ("drm/i915/tv: convert to struct intel_display") Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Jani Nikula <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Abhinav Kumar <[email protected]> Date: Thu Dec 5 20:31:33 2024 -0800 drm/msm/dp: disable the opp table request even for dp_ctrl_off_link() [ Upstream commit a3dd01375a6a21ed3e5dbc58f7004d48561f0977 ] dp_ctrl_off_link() was created to handle a case where we received a cable connect and then get a cable disconnect without the corresponding dp_display_enable(). For such cases the pixel clock will be off but the link clock will still be on. dp_ctrl_off_link() handles this case by turning off the link clock only. However, the vote removal to the opp table for this case was missed. Remove the opp table vote in dp_ctrl_off_link(). Fixes: 375a126090b9 ("drm/msm/dp: tear down main link at unplug handle immediately") Reviewed-by: Dmitry Baryshkov <[email protected]> Patchwork: https://patchwork.freedesktop.org/patch/627487/ Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Abhinav Kumar <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Abhinav Kumar <[email protected]> Date: Mon Dec 2 12:41:59 2024 -0800 drm/msm/dp: do not touch the MMSS_DP_INTF_CONFIG for tpg [ Upstream commit 9ffbf5ef0e8d6e1b76440a6d77311d0c5d6e3979 ] MMSS_DP_INTF_CONFIG has already been setup by the main datapath for DP to account for widebus to be used/unused etc. In current implementation, TPG only switches the DP controller to use the main datapath stream OR use the test pattern but expects the rest of the controller to be already setup. Keeping the same behavior intact, drop the clearing of MMSS_DP_INTF_CONFIG from the msm_dp_catalog_panel_tpg_enable() API. Fixes: 757a2f36ab09 ("drm/msm/dp: enable widebus feature for display port") Reviewed-by: Dmitry Baryshkov <[email protected]> Patchwork: https://patchwork.freedesktop.org/patch/626888/ Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Abhinav Kumar <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Abhinav Kumar <[email protected]> Date: Thu Dec 5 20:31:32 2024 -0800 drm/msm/dp: dont call dp_catalog_ctrl_mainlink_ctrl in dp_ctrl_configure_source_params() [ Upstream commit 50e608d166ba68faacf81a5ce17c09b0c697eefd ] Once the link has already been setup there is no need to call dp_catalog_ctrl_mainlink_ctrl() as this does a reset on the mainlink thereby tearing down the link briefly. Fixes: c943b4948b58 ("drm/msm/dp: add displayPort driver support") Reviewed-by: Dmitry Baryshkov <[email protected]> Patchwork: https://patchwork.freedesktop.org/patch/627479/ Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Abhinav Kumar <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Dmitry Baryshkov <[email protected]> Date: Mon Dec 2 12:06:32 2024 +0200 drm/msm/dp: fix msm_dp_utils_pack_sdp_header interface [ Upstream commit b047cbe5e54b632042941b90b808223e63742690 ] The msm_dp_utils_pack_sdp_header() accepts an unlimited-size u32 pointer for the header output, while it expects a two-element array. It performs a sizeof check which is always true on 64-bit platforms (since sizeof(u32*) is 8) and is always false on 32-bit platforms. It returns an error code which nobody actually checks. Fix the function interface to accept u32[2] and return void, skipping all the checks. Fixes: 55fb8ffc1802 ("drm/msm/dp: add VSC SDP support for YUV420 over DP") Signed-off-by: Dmitry Baryshkov <[email protected]> Reviewed-by: Abhinav Kumar <[email protected]> Patchwork: https://patchwork.freedesktop.org/patch/626806/ Link: https://lore.kernel.org/r/[email protected] [[email protected]: minor fix in the commit message] Signed-off-by: Abhinav Kumar <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Dmitry Baryshkov <[email protected]> Date: Mon Dec 2 12:06:31 2024 +0200 drm/msm/dp: set safe_to_exit_level before printing it [ Upstream commit 7dee35d79bb046bfd425aa9e58a82414f67c1cec ] Rather than printing random garbage from stack and pretending that it is the default safe_to_exit_level, set the variable beforehand. Fixes: d13e36d7d222 ("drm/msm/dp: add audio support for Display Port on MSM") Reported-by: kernel test robot <[email protected]> Closes: https://lore.kernel.org/oe-kbuild-all/[email protected]/ Signed-off-by: Dmitry Baryshkov <[email protected]> Reviewed-by: Abhinav Kumar <[email protected]> Patchwork: https://patchwork.freedesktop.org/patch/626804/ Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Abhinav Kumar <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Abhinav Kumar <[email protected]> Date: Wed Dec 11 11:50:26 2024 -0800 drm/msm/dpu: check dpu_plane_atomic_print_state() for valid sspp [ Upstream commit 789384eb1437aed94155dc0eac8a8a6ba1baf578 ] Similar to the r_pipe sspp protect, add a check to protect the pipe state prints to avoid NULL ptr dereference for cases when the state is dumped without a corresponding atomic_check() where the pipe->sspp is assigned. Fixes: 31f7148fd370 ("drm/msm/dpu: move pstate->pipe initialization to dpu_plane_atomic_check") Reported-by: Stephen Boyd <[email protected]> Closes: https://gitlab.freedesktop.org/drm/msm/-/issues/67 Reviewed-by: Dmitry Baryshkov <[email protected]> Tested-by: Douglas Anderson <[email protected]> Tested-by: Stephen Boyd <[email protected]> # sc7180-trogdor Patchwork: https://patchwork.freedesktop.org/patch/628404/ Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Abhinav Kumar <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Dmitry Baryshkov <[email protected]> Date: Fri Dec 20 03:28:31 2024 +0200 drm/msm/dpu: link DSPP_2/_3 blocks on SC8180X [ Upstream commit 0986163245df6bece47113e506143a7e87b0097d ] Link DSPP_2 to the LM_2 and DSPP_3 to the LM_3 mixer blocks. This allows using colour transformation matrix (aka night mode) with more outputs at the same time. Fixes: f5abecfe339e ("drm/msm/dpu: enable DSPP and DSC on sc8180x") Reviewed-by: Abhinav Kumar <[email protected]> Signed-off-by: Dmitry Baryshkov <[email protected]> Patchwork: https://patchwork.freedesktop.org/patch/629954/ Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Dmitry Baryshkov <[email protected]> Date: Fri Dec 20 03:28:30 2024 +0200 drm/msm/dpu: link DSPP_2/_3 blocks on SM8150 [ Upstream commit ac440a31e523805939215b24d2f0c451b48d5891 ] Link DSPP_2 to the LM_2 and DSPP_3 to the LM_3 mixer blocks. This allows using colour transformation matrix (aka night mode) with more outputs at the same time. Fixes: 05ae91d960fd ("drm/msm/dpu: enable DSPP support on SM8[12]50") Reviewed-by: Abhinav Kumar <[email protected]> Signed-off-by: Dmitry Baryshkov <[email protected]> Patchwork: https://patchwork.freedesktop.org/patch/629952/ Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Dmitry Baryshkov <[email protected]> Date: Fri Dec 20 03:28:32 2024 +0200 drm/msm/dpu: link DSPP_2/_3 blocks on SM8250 [ Upstream commit 8252028092f86d413b3a83e5e76a9615073a0c7f ] Link DSPP_2 to the LM_2 and DSPP_3 to the LM_3 mixer blocks. This allows using colour transformation matrix (aka night mode) with more outputs at the same time. Fixes: 05ae91d960fd ("drm/msm/dpu: enable DSPP support on SM8[12]50") Reviewed-by: Abhinav Kumar <[email protected]> Signed-off-by: Dmitry Baryshkov <[email protected]> Patchwork: https://patchwork.freedesktop.org/patch/629956/ Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Dmitry Baryshkov <[email protected]> Date: Fri Dec 20 03:28:33 2024 +0200 drm/msm/dpu: link DSPP_2/_3 blocks on SM8350 [ Upstream commit 42323d3c9e04c725d27606c31663b80a7cc30218 ] Link DSPP_2 to the LM_2 and DSPP_3 to the LM_3 mixer blocks. This allows using colour transformation matrix (aka night mode) with more outputs at the same time. Fixes: 0e91bcbb0016 ("drm/msm/dpu: Add SM8350 to hw catalog") Reviewed-by: Abhinav Kumar <[email protected]> Signed-off-by: Dmitry Baryshkov <[email protected]> Patchwork: https://patchwork.freedesktop.org/patch/629959/ Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Dmitry Baryshkov <[email protected]> Date: Fri Dec 20 03:28:34 2024 +0200 drm/msm/dpu: link DSPP_2/_3 blocks on SM8550 [ Upstream commit e21f9d85b05361bc343b11ecf84ac12c9cccbc3e ] Link DSPP_2 to the LM_2 and DSPP_3 to the LM_3 mixer blocks. This allows using colour transformation matrix (aka night mode) with more outputs at the same time. Fixes: efcd0107727c ("drm/msm/dpu: add support for SM8550") Reviewed-by: Abhinav Kumar <[email protected]> Signed-off-by: Dmitry Baryshkov <[email protected]> Patchwork: https://patchwork.freedesktop.org/patch/629961/ Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Dmitry Baryshkov <[email protected]> Date: Fri Dec 20 03:28:35 2024 +0200 drm/msm/dpu: link DSPP_2/_3 blocks on SM8650 [ Upstream commit 3d3ca0915aa3692a837f7235ca9d12db26f09911 ] Link DSPP_2 to the LM_2 and DSPP_3 to the LM_3 mixer blocks. This allows using colour transformation matrix (aka night mode) with more outputs at the same time. Fixes: b94747f7d8c7 ("drm/msm/dpu: add support for SM8650 DPU") Reviewed-by: Abhinav Kumar <[email protected]> Signed-off-by: Dmitry Baryshkov <[email protected]> Patchwork: https://patchwork.freedesktop.org/patch/629962/ Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Dmitry Baryshkov <[email protected]> Date: Fri Dec 20 03:28:36 2024 +0200 drm/msm/dpu: link DSPP_2/_3 blocks on X1E80100 [ Upstream commit 3a7a4bebe0dbe22686da7de573f183e0c842883a ] Link DSPP_2 to the LM_2 and DSPP_3 to the LM_3 mixer blocks. This allows using colour transformation matrix (aka night mode) with more outputs at the same time. Fixes: e3b1f369db5a ("drm/msm/dpu: Add X1E80100 support") Reviewed-by: Abhinav Kumar <[email protected]> Signed-off-by: Dmitry Baryshkov <[email protected]> Patchwork: https://patchwork.freedesktop.org/patch/629966/ Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Dmitry Baryshkov <[email protected]> Date: Fri Dec 20 03:28:29 2024 +0200 drm/msm/dpu: provide DSPP and correct LM config for SDM670 [ Upstream commit 9a20f33495bfd45ca6712213f30697f686d0b6fd ] On SDM670 the DPU has two DSPP blocks compared to 4 DSPP blocks on SDM845. Currently SDM670 just reuses LMs and DSPPs from SDM845. Define platform-specific configuration for those blocks. Fixes: e140b7e496b7 ("drm/msm/dpu: Add hw revision 4.1 (SDM670)") Reviewed-by: Abhinav Kumar <[email protected]> Signed-off-by: Dmitry Baryshkov <[email protected]> Patchwork: https://patchwork.freedesktop.org/patch/629951/ Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Rex Nie <[email protected]> Date: Tue Nov 12 15:41:00 2024 +0800 drm/msm/hdmi: simplify code in pll_get_integloop_gain [ Upstream commit c1beb6f75d5e60e4e57a837c665a52eb79eb19ba ] In pll_get_integloop_gain(), digclk_divsel=1 or 2, base=63 or 196ULL, so the base may be 63, 126, 196, 392. The condition base <= 2046 always true. Fixes: caedbf17c48d ("drm/msm: add msm8998 hdmi phy/pll support") Signed-off-by: Rex Nie <[email protected]> Reviewed-by: Dmitry Baryshkov <[email protected]> Reviewed-by: Abhinav Kumar <[email protected]> Patchwork: https://patchwork.freedesktop.org/patch/624153/ Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Abhinav Kumar <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Dmitry Baryshkov <[email protected]> Date: Sat Apr 20 05:33:03 2024 +0300 drm/msm/mdp4: correct LCDC regulator name [ Upstream commit 8aa337cbe7a61a5a98a4d3f446fc968b3bac914a ] Correct c&p error from the conversion of LCDC regulators to the bulk API. Fixes: 54f1fbcb47d4 ("drm/msm/mdp4: use bulk regulators API for LCDC encoder") Signed-off-by: Dmitry Baryshkov <[email protected]> Reviewed-by: Abhinav Kumar <[email protected]> Patchwork: https://patchwork.freedesktop.org/patch/590412/ Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Sui Jingfeng <[email protected]> Date: Mon Nov 4 17:07:38 2024 +0800 drm/msm: Check return value of of_dma_configure() [ Upstream commit b34a7401ffaee45354e81b38a4d072794079cfd6 ] Because the of_dma_configure() will returns '-EPROBE_DEFER' if the probe procedure of the specific platform IOMMU driver is not finished yet. It can also return other error code for various reasons. Stop pretending that it will always suceess, quit if it fail. Signed-off-by: Sui Jingfeng <[email protected]> Reviewed-by: Konrad Dybcio <[email protected]> Fixes: 29ac8979cdf7 ("drm/msm/a6xx: use msm_gem for GMU memory objects") Fixes: 5a903a44a984 ("drm/msm/a6xx: Introduce GMU wrapper support") Reviewed-by: Dmitry Baryshkov <[email protected]> Patchwork: https://patchwork.freedesktop.org/patch/622782/ Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Dmitry Baryshkov <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Dmitry Baryshkov <[email protected]> Date: Sat Apr 20 05:33:01 2024 +0300 drm/msm: don't clean up priv->kms prematurely [ Upstream commit ebc0deda3c2948d40419677d388b4e6081688a06 ] MSM display drivers provide kms structure allocated during probe(). Don't clean up priv->kms field in case of an error. Otherwise probe functions might fail after KMS probe deferral. Fixes: a2ab5d5bb6b1 ("drm/msm: allow passing struct msm_kms to msm_drv_probe()") Signed-off-by: Dmitry Baryshkov <[email protected]> Reviewed-by: Abhinav Kumar <[email protected]> Fixes: 506efcba3129 ("drm/msm: carve out KMS code from msm_drv.c") Patchwork: https://patchwork.freedesktop.org/patch/590411/ Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Boris Brezillon <[email protected]> Date: Wed Dec 11 08:54:15 2024 +0100 drm/panthor: Preserve the result returned by panthor_fw_resume() [ Upstream commit 4bd56ca8226dda6115bca385b166ef87e867d807 ] WARN() will return true if the condition is true, false otherwise. If we store the return of drm_WARN_ON() in ret, we lose the actual error code. v3: - Add R-b v2: - Add R-b Fixes: 5fe909cae118 ("drm/panthor: Add the device logical block") Signed-off-by: Boris Brezillon <[email protected]> Reviewed-by: Steven Price <[email protected]> Reviewed-by: Adrian Larumbe <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Andy Yan <[email protected]> Date: Sat Dec 14 16:17:05 2024 +0800 drm/rockchip: vop2: Add check for 32 bpp format for rk3588 [ Upstream commit 7e8a56c703c67bfa8d3f71a0c1c297bb1252b897 ] RK3588 only support DRM_FORMAT_XRGB2101010/XBGR2101010 in afbc mode. Fixes: 5a028e8f062f ("drm/rockchip: vop2: Add support for rk3588") Signed-off-by: Andy Yan <[email protected]> Signed-off-by: Heiko Stuebner <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Andy Yan <[email protected]> Date: Sat Dec 14 16:17:04 2024 +0800 drm/rockchip: vop2: Check linear format for Cluster windows on rk3566/8 [ Upstream commit df063c0b8ffbdca486ab2f802e716973985d8f86 ] The Cluster windows on rk3566/8 only support afbc mode. Fixes: 604be85547ce ("drm/rockchip: Add VOP2 driver") Signed-off-by: Andy Yan <[email protected]> Signed-off-by: Heiko Stuebner <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Andy Yan <[email protected]> Date: Mon Dec 9 20:29:15 2024 +0800 drm/rockchip: vop2: Fix cluster windows alpha ctrl regsiters offset [ Upstream commit 17b4b10a0df1a1421d5fbdc03bad0bd3799bc966 ] The phy_id of cluster windws are not increase one for each window. Fixes: 604be85547ce ("drm/rockchip: Add VOP2 driver") Tested-by: Derek Foreman <[email protected]> Signed-off-by: Andy Yan <[email protected]> Signed-off-by: Heiko Stuebner <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Heiko Stuebner <[email protected]> Date: Fri Nov 15 16:11:31 2024 +0100 drm/rockchip: vop2: fix rk3588 dp+dsi maxclk verification [ Upstream commit 5807f4ee6d32a4cce9a4df36f0d455c64c861947 ] The clock is in Hz while the value checked against is in kHz, so actual frequencies will never be able to be below to max value. Fix this by specifying the max-value in Hz too. Fixes: 5a028e8f062f ("drm/rockchip: vop2: Add support for rk3588") Signed-off-by: Heiko Stuebner <[email protected]> Reviewed-by: Quentin Schulz <[email protected]> Acked-by: Andy Yan <[email protected]> Reviewed-by: Sebastian Reichel <[email protected]> Tested-by: Sebastian Reichel <[email protected]> Signed-off-by: Heiko Stuebner <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Andy Yan <[email protected]> Date: Mon Dec 9 20:29:16 2024 +0800 drm/rockchip: vop2: Fix the mixer alpha setup for layer 0 [ Upstream commit 6b4dfdcde3573a12b72d2869dabd4ca37ad7e9c7 ] The alpha setup should start from the second layer, the current calculation starts incorrectly from the first layer, a negative offset will be obtained in the following formula: offset = (mixer_id + zpos - 1) * 0x10 Fixes: 604be85547ce ("drm/rockchip: Add VOP2 driver") Tested-by: Derek Foreman <[email protected]> Signed-off-by: Andy Yan <[email protected]> Signed-off-by: Heiko Stuebner <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Andy Yan <[email protected]> Date: Sat Dec 14 16:17:01 2024 +0800 drm/rockchip: vop2: Fix the windows switch between different layers [ Upstream commit 0ca953ac226eaffbe1a795f5e517095a8d494921 ] Every layer of vop2 should bind a window, and we also need to make sure that this window is not used by other layer. 0x5 is a reserved layer sel value on rk3568, but it will select Cluster3 on rk3588, configure unused layers to 0x5 will lead alpha blending error on rk3588. When we bind a window from layerM to layerN, we move the old window on layerN to layerM. Fixes: 604be85547ce ("drm/rockchip: Add VOP2 driver") Tested-by: Derek Foreman <[email protected]> Signed-off-by: Andy Yan <[email protected]> Signed-off-by: Heiko Stuebner <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Min-Hua Chen <[email protected]> Date: Sat Dec 14 16:17:06 2024 +0800 drm/rockchip: vop2: include rockchip_drm_drv.h [ Upstream commit 77b1ccb2a27c7b3b118a03bf1730def92070d31b ] Move rockchip_drm_drv.h in rockchip_drm_vop2.h to fix the follow sparse warning: ARCH=arm64 LLVM=1 make C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' mrproper defconfig all -j12 drivers/gpu/drm/rockchip/rockchip_vop2_reg.c:502:24: sparse: warning: symbol 'vop2_platform_driver' was not declared. Should it be static? It is also beneficial for the upcoming support for rk3576. Fixes: 604be85547ce ("drm/rockchip: Add VOP2 driver") Signed-off-by: Min-Hua Chen <[email protected]> Signed-off-by: Andy Yan <[email protected]> Reviewed-by: Min-Hua Chen <[email protected]> Tested-by: Detlev Casanova <[email protected]> Tested-by: Michael Riesch <[email protected]> # on RK3568 Signed-off-by: Heiko Stuebner <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Andy Yan <[email protected]> Date: Sat Dec 14 16:17:02 2024 +0800 drm/rockchip: vop2: Set AXI id for rk3588 [ Upstream commit 7b256880fdb2d7f23393b87bb557090f049e686a ] There are two AXI bus in vop2, windows attached on the same bus must have a unique channel YUV and RGB channel ID. The default IDs will conflict with each other on the rk3588, so they need to be reassigned. Fixes: 5a028e8f062f ("drm/rockchip: vop2: Add support for rk3588") Signed-off-by: Andy Yan <[email protected]> Tested-by: Derek Foreman <[email protected]> Tested-by: Detlev Casanova <[email protected]> Signed-off-by: Heiko Stuebner <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Andy Yan <[email protected]> Date: Sat Dec 14 16:17:03 2024 +0800 drm/rockchip: vop2: Setup delay cycle for Esmart2/3 [ Upstream commit c766998ba6df126ab6934d32ff2ff080316ec630 ] Each layer needs to set the correct delay cycle to display properly without unexpected offset on screen. Fixes: 5a028e8f062f ("drm/rockchip: vop2: Add support for rk3588") Signed-off-by: Andy Yan <[email protected]> Tested-by: Derek Foreman <[email protected]> Tested-by: Detlev Casanova <[email protected]> Signed-off-by: Heiko Stuebner <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Maíra Canal <[email protected]> Date: Wed Nov 6 09:16:51 2024 -0300 drm/v3d: Fix performance counter source settings on V3D 7.x [ Upstream commit e987e22e9229d70c2083a91cc61269b2c4924955 ] When the new register addresses were introduced for V3D 7.x, we added new masks for performance counter sources on V3D 7.x. Nevertheless, we never apply these new masks when setting the sources. Fix the performance counter source settings on V3D 7.x by introducing a new macro, `V3D_SET_FIELD_VER`, which allows fields setting to vary by version. Using this macro, we can provide different values for source mask based on the V3D version, ensuring that sources are correctly configure on V3D 7.x. Fixes: 0ad5bc1ce463 ("drm/v3d: fix up register addresses for V3D 7.x") Signed-off-by: Maíra Canal <[email protected]> Reviewed-by: Iago Toral Quiroga <[email protected]> Reviewed-by: Christian Gmeiner <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Shengjiu Wang <[email protected]> Date: Tue Nov 19 09:58:03 2024 +0800 dt-bindings: clock: imx93: Add SPDIF IPG clk [ Upstream commit 32e9dea2645fa10dfa08b4e333918affaf1e4de5 ] Add SPDIF IPG clk. The SPDIF IPG clock and root clock share same clock gate. Fixes: 1c4a4f7362fd ("arm64: dts: imx93: Add audio device nodes") Signed-off-by: Shengjiu Wang <[email protected]> Reviewed-by: Frank Li <[email protected]> Acked-by: Krzysztof Kozlowski <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Abel Vesa <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Dmitry Baryshkov <[email protected]> Date: Tue Nov 12 05:21:24 2024 +0200 dt-bindings: display/msm: qcom,sa8775p-mdss: fix the example [ Upstream commit 3b08796f2a7ca0c27b16543603df85bb45a640ff ] Add p1 region to the list of DP registers in the SA8775p example. This fixes the following warning: Documentation/devicetree/bindings/display/msm/qcom,sa8775p-mdss.example.dtb: displayport-controller@af54000: reg: [[183844864, 260], [183845376, 192], [183848960, 1904], [183853056, 156]] is too short Fixes: 409685915f00 ("dt-bindings: display/msm: Document MDSS on SA8775P") Reported-by: Rob Herring <[email protected]> Closes: https://lore.kernel.org/dri-devel/CAL_JsqJ0zoyaZAgZtyJ8xMsPY+YzrbF-YG1vPN6tFoFXQaW09w@mail.gmail.com/ Signed-off-by: Dmitry Baryshkov <[email protected]> Reviewed-by: Abhinav Kumar <[email protected]> Acked-by: Rob Herring (Arm) <[email protected]> Patchwork: https://patchwork.freedesktop.org/patch/624068/ Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Abhinav Kumar <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Geert Uytterhoeven <[email protected]> Date: Thu Nov 14 13:44:29 2024 +0100 dt-bindings: leds: class-multicolor: Fix path to color definitions [ Upstream commit 609bc99a4452ffbce82d10f024a85d911c42e6cd ] The LED color definitions have always been in include/dt-bindings/leds/common.h in upstream. Fixes: 5c7f8ffe741daae7 ("dt: bindings: Add multicolor class dt bindings documention") Signed-off-by: Geert Uytterhoeven <[email protected]> Acked-by: Conor Dooley <[email protected]> Link: https://lore.kernel.org/r/a3c7ea92e90b77032f2e480d46418b087709286d.1731588129.git.geert+renesas@glider.be Signed-off-by: Lee Jones <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Matti Vaittinen <[email protected]> Date: Tue Nov 12 19:01:06 2024 +0200 dt-bindings: mfd: bd71815: Fix rsense and typos [ Upstream commit 6856edf7ead8c54803216a38a7b227bcb3dadff7 ] The sense resistor used for measuring currents is typically some tens of milli Ohms. It has accidentally been documented to be tens of mega Ohms. Fix the size of this resistor and a few copy-paste errors while at it. Drop the unsuitable 'rohm,charger-sense-resistor-ohms' property (which can't represent resistors smaller than one Ohm), and introduce a new 'rohm,charger-sense-resistor-micro-ohms' property with appropriate minimum, maximum and default values instead. Fixes: 4238dc1e6490 ("dt_bindings: mfd: Add ROHM BD71815 PMIC") Signed-off-by: Matti Vaittinen <[email protected]> Acked-by: Conor Dooley <[email protected]> Link: https://lore.kernel.org/r/0efd8e9de0ae8d62ee4c6b78cc565b04007a245d.1731430700.git.mazziesaccount@gmail.com Signed-off-by: Lee Jones <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Neil Armstrong <[email protected]> Date: Thu Nov 28 16:16:41 2024 +0100 dt-bindings: mmc: controller: clarify the address-cells description [ Upstream commit b2b8e93ec00b8110cb37cbde5400d5abfdaed6a7 ] The term "slot ID" has nothing to do with the SDIO function number which is specified in the reg property of the subnodes, rephrase the description to be more accurate. Fixes: f9b7989859dd ("dt-bindings: mmc: Add YAML schemas for the generic MMC options") Signed-off-by: Neil Armstrong <[email protected]> Acked-by: Rob Herring (Arm) <[email protected]> Message-ID: <20241128-topic-amlogic-arm32-upstream-bindings-fixes-convert-meson-mx-sdio-v4-1-11d9f9200a59@linaro.org> Signed-off-by: Ulf Hansson <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Jason-JH.Lin <[email protected]> Date: Fri Dec 20 02:15:30 2024 +0800 dts: arm64: mediatek: mt8188: Update OVL compatible from MT8183 to MT8195 [ Upstream commit 2a1a08590d371fc6327efc8b60d8bc1831f23fb4 ] The OVL hardware capabilities have changed starting from MT8195, making the MT8183 compatible no longer applicable. Therefore, it is necessary to update the OVL compatible from MT8183 to MT8195. Reviewed-by: AngeloGioacchino Del Regno <[email protected]> Signed-off-by: Jason-JH.Lin <[email protected]> Fixes: 7075b21d1a8e ("arm64: dts: mediatek: mt8188: Add display nodes for vdosys0") Link: https://lore.kernel.org/r/[email protected] Signed-off-by: AngeloGioacchino Del Regno <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Jason-JH.Lin <[email protected]> Date: Fri Dec 20 02:15:31 2024 +0800 dts: arm64: mediatek: mt8195: Remove MT8183 compatible for OVL [ Upstream commit ce3dbc46d7e30a84b8e99c730e3172dd5efbf094 ] The OVL hardware capabilities have changed starting from MT8195, making the MT8183 compatible no longer applicable. Therefore, it is necessary to remove the MT8183 compatible for OVL. Reviewed-by: AngeloGioacchino Del Regno <[email protected]> Signed-off-by: Jason-JH.Lin <[email protected]> Fixes: b852ee68fd72 ("arm64: dts: mt8195: Add display node for vdosys0") Link: https://lore.kernel.org/r/[email protected] Signed-off-by: AngeloGioacchino Del Regno <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Randy Dunlap <[email protected]> Date: Tue Jan 7 15:53:09 2025 -0800 efi: sysfb_efi: fix W=1 warnings when EFI is not set [ Upstream commit 19fdc68aa7b90b1d3d600e873a3e050a39e7663d ] A build with W=1 fails because there are code and data that are not needed or used when CONFIG_EFI is not set. Move the "#ifdef CONFIG_EFI" block to earlier in the source file so that the unused code/data are not built. drivers/firmware/efi/sysfb_efi.c:345:39: warning: ‘efifb_fwnode_ops’ defined but not used [-Wunused-const-variable=] 345 | static const struct fwnode_operations efifb_fwnode_ops = { | ^~~~~~~~~~~~~~~~ drivers/firmware/efi/sysfb_efi.c:238:35: warning: ‘efifb_dmi_swap_width_height’ defined but not used [-Wunused-const-variable=] 238 | static const struct dmi_system_id efifb_dmi_swap_width_height[] __initconst = { | ^~~~~~~~~~~~~~~~~~~~~~~~~~~ drivers/firmware/efi/sysfb_efi.c:188:35: warning: ‘efifb_dmi_system_table’ defined but not used [-Wunused-const-variable=] 188 | static const struct dmi_system_id efifb_dmi_system_table[] __initconst = { | ^~~~~~~~~~~~~~~~~~~~~~ Fixes: 15d27b15de96 ("efi: sysfb_efi: fix build when EFI is not set") Signed-off-by: Randy Dunlap <[email protected]> Reported-by: kernel test robot <[email protected]> Closes: https://lore.kernel.org/oe-kbuild-all/[email protected]/ Cc: David Rheinsberg <[email protected]> Cc: Hans de Goede <[email protected]> Cc: Javier Martinez Canillas <[email protected]> Cc: Peter Jones <[email protected]> Cc: Simona Vetter <[email protected]> Cc: [email protected] Cc: Ard Biesheuvel <[email protected]> Cc: [email protected] Reviewed-by: Thomas Zimmermann <[email protected]> Reviewed-by: Javier Martinez Canillas <[email protected]> Signed-off-by: Ard Biesheuvel <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Gao Xiang <[email protected]> Date: Tue Jan 14 12:00:58 2025 +0800 erofs: fix potential return value overflow of z_erofs_shrink_scan() [ Upstream commit db902986dee453bfb5835cbc8efa67154ab34caf ] z_erofs_shrink_scan() could return small numbers due to the mistyped `freed`. Although I don't think it has any visible impact. Fixes: 3883a79abd02 ("staging: erofs: introduce VLE decompression support") Reviewed-by: Chao Yu <[email protected]> Signed-off-by: Gao Xiang <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Gal Pressman <[email protected]> Date: Sun Jan 26 21:18:45 2025 +0200 ethtool: Fix set RXNFC command with symmetric RSS hash [ Upstream commit 4f5a52adeb1ad675ca33f1e1eacd9c0bbaf393d4 ] The sanity check that both source and destination are set when symmetric RSS hash is requested is only relevant for ETHTOOL_SRXFH (rx-flow-hash), it should not be performed on any other commands (e.g. ETHTOOL_SRXCLSRLINS/ETHTOOL_SRXCLSRLDEL). This resolves accessing uninitialized 'info.data' field, and fixes false errors in rule insertion: # ethtool --config-ntuple eth2 flow-type ip4 dst-ip 255.255.255.255 action -1 loc 0 rmgr: Cannot insert RX class rule: Invalid argument Cannot insert classification rule Fixes: 13e59344fb9d ("net: ethtool: add support for symmetric-xor RSS hash") Cc: Ahmed Zaki <[email protected]> Reviewed-by: Tariq Toukan <[email protected]> Signed-off-by: Gal Pressman <[email protected]> Reviewed-by: Michal Swiatkowski <[email protected]> Reviewed-by: Edward Cree <[email protected]> Reviewed-by: Ahmed Zaki <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Paolo Abeni <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Daniel Lee <[email protected]> Date: Fri Dec 20 15:41:31 2024 -0800 f2fs: Introduce linear search for dentries commit 91b587ba79e1b68bb718d12b0758dbcdab4e9cb7 upstream. This patch addresses an issue where some files in case-insensitive directories become inaccessible due to changes in how the kernel function, utf8_casefold(), generates case-folded strings from the commit 5c26d2f1d3f5 ("unicode: Don't special case ignorable code points"). F2FS uses these case-folded names to calculate hash values for locating dentries and stores them on disk. Since utf8_casefold() can produce different output across kernel versions, stored hash values and newly calculated hash values may differ. This results in affected files no longer being found via the hash-based lookup. To resolve this, the patch introduces a linear search fallback. If the initial hash-based search fails, F2FS will sequentially scan the directory entries. Fixes: 5c26d2f1d3f5 ("unicode: Don't special case ignorable code points") Link: https://bugzilla.kernel.org/show_bug.cgi?id=219586 Signed-off-by: Daniel Lee <[email protected]> Reviewed-by: Chao Yu <[email protected]> Signed-off-by: Jaegeuk Kim <[email protected]> Cc: Daniel Rosenberg <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Joe Hattori <[email protected]> Date: Wed Jan 8 10:15:37 2025 +0900 fbdev: omapfb: Fix an OF node leak in dss_of_port_get_parent_device() [ Upstream commit de124b61e179e690277116e6be512e4f422b5dd8 ] dss_of_port_get_parent_device() leaks an OF node reference when i >= 2 and struct device_node *np is present. Since of_get_next_parent() obtains a reference of the returned OF node, call of_node_put() before returning NULL. This was found by an experimental verifier that I am developing, and no runtime test was able to be performed due to that lack of actual devices. Fixes: f76ee892a99e ("omapfb: copy omapdss & displays for omapfb") Signed-off-by: Joe Hattori <[email protected]> Reviewed-by: Laurent Pinchart <[email protected]> Signed-off-by: Helge Deller <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Charles Han <[email protected]> Date: Fri Jan 10 16:42:37 2025 +0800 firewire: test: Fix potential null dereference in firewire kunit test [ Upstream commit 352fafe97784e81a10a7c74bd508f71a19b53c2a ] kunit_kzalloc() may return a NULL pointer, dereferencing it without NULL check may lead to NULL dereference. Add a NULL check for test_state. Fixes: 1c8506d62624 ("firewire: test: add test of device attributes for simple AV/C device") Signed-off-by: Charles Han <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Takashi Sakamoto <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Krzysztof Kozlowski <[email protected]> Date: Mon Dec 9 15:27:57 2024 +0100 firmware: qcom: scm: Cleanup global '__scm' on probe failures [ Upstream commit 1e76b546e6fca7eb568161f408133904ca6bcf4f ] If SCM driver fails the probe, it should not leave global '__scm' variable assigned, because external users of this driver will assume the probe finished successfully. For example TZMEM parts ('__scm->mempool') are initialized later in the probe, but users of it (__scm_smc_call()) rely on the '__scm' variable. This fixes theoretical NULL pointer exception, triggered via introducing probe deferral in SCM driver with call trace: qcom_tzmem_alloc+0x70/0x1ac (P) qcom_tzmem_alloc+0x64/0x1ac (L) qcom_scm_assign_mem+0x78/0x194 qcom_rmtfs_mem_probe+0x2d4/0x38c platform_probe+0x68/0xc8 Fixes: 40289e35ca52 ("firmware: qcom: scm: enable the TZ mem allocator") Signed-off-by: Krzysztof Kozlowski <[email protected]> Link: https://lore.kernel.org/r/20241209-qcom-scm-missing-barriers-and-all-sort-of-srap-v2-4-9061013c8d92@linaro.org Signed-off-by: Bjorn Andersson <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Jinliang Zheng <[email protected]> Date: Sun Nov 24 11:46:36 2024 +0800 fs: fix proc_handler for sysctl_nr_open [ Upstream commit d727935cad9f6f52c8d184968f9720fdc966c669 ] Use proc_douintvec_minmax() instead of proc_dointvec_minmax() to handle sysctl_nr_open, because its data type is unsigned int, not int. Fixes: 9b80a184eaad ("fs/file: more unsigned file descriptors") Signed-off-by: Jinliang Zheng <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Christian Brauner <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Thomas Gleixner <[email protected]> Date: Tue Dec 10 11:20:43 2024 +0100 genirq: Make handle_enforce_irqctx() unconditionally available [ Upstream commit 8d187a77f04c14fb459a5301d69f733a5a1396bc ] Commit 1b57d91b969c ("irqchip/gic-v2, v3: Prevent SW resends entirely") sett the flag which enforces interrupt handling in interrupt context and prevents software base resends for ARM GIC v2/v3. But it missed that the helper function which checks the flag was hidden behind CONFIG_GENERIC_PENDING_IRQ, which is not set by ARM[64]. Make the helper unconditionally available so that the enforcement actually works. Fixes: 1b57d91b969c ("irqchip/gic-v2, v3: Prevent SW resends entirely") Signed-off-by: Thomas Gleixner <[email protected]> Link: https://lore.kernel.org/all/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Masahiro Yamada <[email protected]> Date: Fri Jan 3 16:30:38 2025 +0900 genksyms: fix memory leak when the same symbol is added from source [ Upstream commit 45c9c4101d3d2fdfa00852274bbebba65fcc3cf2 ] When a symbol that is already registered is added again, __add_symbol() returns without freeing the symbol definition, making it unreachable. The following test cases demonstrate different memory leak points. [Test Case 1] Forward declaration with exactly the same definition $ cat foo.c #include <linux/export.h> void foo(void); void foo(void) {} EXPORT_SYMBOL(foo); [Test Case 2] Forward declaration with a different definition (e.g. attribute) $ cat foo.c #include <linux/export.h> void foo(void); __attribute__((__section__(".ref.text"))) void foo(void) {} EXPORT_SYMBOL(foo); [Test Case 3] Preserving an overridden symbol (compile with KBUILD_PRESERVE=1) $ cat foo.c #include <linux/export.h> void foo(void); void foo(void) { } EXPORT_SYMBOL(foo); $ cat foo.symref override foo void foo ( int ) The memory leaks in Test Case 1 and 2 have existed since the introduction of genksyms into the kernel tree. [1] The memory leak in Test Case 3 was introduced by commit 5dae9a550a74 ("genksyms: allow to ignore symbol checksum changes"). When multiple init_declarators are reduced to an init_declarator_list, the decl_spec must be duplicated. Otherwise, the following Test Case 4 would result in a double-free bug. [Test Case 4] $ cat foo.c #include <linux/export.h> extern int foo, bar; int foo, bar; EXPORT_SYMBOL(foo); In this case, 'foo' and 'bar' share the same decl_spec, 'int'. It must be unshared before being passed to add_symbol(). [1]: https://git.kernel.org/pub/scm/linux/kernel/git/history/history.git/commit/?id=46bd1da672d66ccd8a639d3c1f8a166048cca608 Fixes: 5dae9a550a74 ("genksyms: allow to ignore symbol checksum changes") Signed-off-by: Masahiro Yamada <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Masahiro Yamada <[email protected]> Date: Fri Jan 3 16:30:39 2025 +0900 genksyms: fix memory leak when the same symbol is read from *.symref file [ Upstream commit be2fa44b5180a1f021efb40c55fdf63c249c3209 ] When a symbol that is already registered is read again from *.symref file, __add_symbol() removes the previous one from the hash table without freeing it. [Test Case] $ cat foo.c #include <linux/export.h> void foo(void); void foo(void) {} EXPORT_SYMBOL(foo); $ cat foo.symref foo void foo ( void ) foo void foo ( void ) When a symbol is removed from the hash table, it must be freed along with its ->name and ->defn members. However, sym->name cannot be freed because it is sometimes shared with node->string, but not always. If sym->name and node->string share the same memory, free(sym->name) could lead to a double-free bug. To resolve this issue, always assign a strdup'ed string to sym->name. Fixes: 64e6c1e12372 ("genksyms: track symbol checksum changes") Signed-off-by: Masahiro Yamada <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Ahmad Fatoum <[email protected]> Date: Mon Jan 13 23:19:11 2025 +0100 gpio: mxc: remove dead code after switch to DT-only [ Upstream commit b049e7abe9001a780d58e78e3833dcceee22f396 ] struct platform_device::id was only set by board code, but since i.MX became a devicetree-only platform, this will always be -1 (PLATFORM_DEVID_NONE). Note: of_alias_get_id() returns a negative number on error and base treats all negative errors the same, so we need not add any additional error handling. Fixes: 0f2c7af45d7e ("gpio: mxc: Convert the driver to DT-only") Signed-off-by: Ahmad Fatoum <[email protected]> Reviewed-by: Andy Shevchenko <[email protected]> Link: https://lore.kernel.org/r/20250113-b4-imx-gpio-base-warning-v1-3-0a28731a5cf6@pengutronix.de Signed-off-by: Bartosz Golaszewski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Luca Ceresoli <[email protected]> Date: Thu Dec 19 10:39:46 2024 +0100 gpio: pca953x: log an error when failing to get the reset GPIO [ Upstream commit 7cef813a91c468253c80633891393478b9f2c966 ] When the dirver fails getting this GPIO, it fails silently. Log an error message to make debugging a lot easier by just reading dmesg. Signed-off-by: Luca Ceresoli <[email protected]> Fixes: 054ccdef8b28 ("gpio: pca953x: Add optional reset gpio control") Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bartosz Golaszewski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Lin Yujun <[email protected]> Date: Mon May 22 02:56:08 2023 +0000 hexagon: Fix unbalanced spinlock in die() [ Upstream commit 03410e87563a122075c3721acc7d5510e41d8332 ] die executes holding the spinlock of &die.lock and unlock it after printing the oops message. However in the code if the notify_die() returns NOTIFY_STOP , die() exit with returning 1 but never unlocked the spinlock. Fix this by adding spin_unlock_irq(&die.lock) before returning. Fixes: cf9750bae262 ("Hexagon: Provide basic debugging and system trap support.") Signed-off-by: Lin Yujun <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Brian Cain <[email protected]> Signed-off-by: Brian Cain <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Willem de Bruijn <[email protected]> Date: Tue Dec 3 17:17:34 2024 -0500 hexagon: fix using plain integer as NULL pointer warning in cmpxchg [ Upstream commit 8a20030038742b9915c6d811a4e6c14b126cafb4 ] Sparse reports net/ipv4/inet_diag.c:1511:17: sparse: sparse: Using plain integer as NULL pointer Due to this code calling cmpxchg on a non-integer type struct inet_diag_handler * return !cmpxchg((const struct inet_diag_handler**)&inet_diag_table[type], NULL, h) ? 0 : -EEXIST; While hexagon's cmpxchg assigns an integer value to a variable of this type. __typeof__(*(ptr)) __oldval = 0; Update this assignment to cast 0 to the correct type. The original issue is easily reproduced at head with the below block, and is absent after this change. make LLVM=1 ARCH=hexagon defconfig make C=1 LLVM=1 ARCH=hexagon net/ipv4/inet_diag.o Fixes: 99a70aa051d2 ("Hexagon: Add processor and system headers") Reported-by: kernel test robot <[email protected]> Closes: https://lore.kernel.org/oe-kbuild-all/[email protected]/ Signed-off-by: Willem de Bruijn <[email protected]> Tested-by: Christian Gmeiner <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Brian Cain <[email protected]> Signed-off-by: Brian Cain <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Alan Stern <[email protected]> Date: Tue Dec 31 14:23:12 2024 -0500 HID: core: Fix assumption that Resolution Multipliers must be in Logical Collections commit 64f2657b579343cf923aa933f08074e6258eb07b upstream. A report in 2019 by the syzbot fuzzer was found to be connected to two errors in the HID core associated with Resolution Multipliers. One of the errors was fixed by commit ea427a222d8b ("HID: core: Fix deadloop in hid_apply_multiplier."), but the other has not been fixed. This error arises because hid_apply_multipler() assumes that every Resolution Multiplier control is contained in a Logical Collection, i.e., there's no way the routine can ever set multiplier_collection to NULL. This is in spite of the fact that the function starts with a big comment saying: * "The Resolution Multiplier control must be contained in the same * Logical Collection as the control(s) to which it is to be applied. ... * If no Logical Collection is * defined, the Resolution Multiplier is associated with all * controls in the report." * HID Usage Table, v1.12, Section 4.3.1, p30 * * Thus, search from the current collection upwards until we find a * logical collection... The comment and the code overlook the possibility that none of the collections found may be a Logical Collection. The fix is to set the multiplier_collection pointer to NULL if the collection found isn't a Logical Collection. Reported-by: [email protected] Closes: https://lore.kernel.org/all/[email protected]/ Signed-off-by: Alan Stern <[email protected]> Cc: Peter Hutterer <[email protected]> Fixes: 5a4abb36f312 ("HID: core: process the Resolution Multiplier") Cc: [email protected] Signed-off-by: Jiri Kosina <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Terry Tritton <[email protected]> Date: Fri Dec 20 19:23:18 2024 +0000 HID: fix generic desktop D-Pad controls [ Upstream commit 80818fdc068eaab729bb793d790ae9fd053f7053 ] The addition of the "System Do Not Disturb" event code caused the Generic Desktop D-Pad configuration to be skipped. This commit allows both to be configured without conflicting with each other. Fixes: 22d6d060ac77 ("input: Add support for "Do Not Disturb"") Signed-off-by: Terry Tritton <[email protected]> Reviewed-by: Aseda Aboagye <[email protected]> Reviewed-by: Carlos Llamas <[email protected]> Signed-off-by: Jiri Kosina <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Karol Przybylski <[email protected]> Date: Thu Dec 5 23:22:21 2024 +0100 HID: hid-thrustmaster: Fix warning in thrustmaster_probe by adding endpoint check [ Upstream commit 50420d7c79c37a3efe4010ff9b1bb14bc61ebccf ] syzbot has found a type mismatch between a USB pipe and the transfer endpoint, which is triggered by the hid-thrustmaster driver[1]. There is a number of similar, already fixed issues [2]. In this case as in others, implementing check for endpoint type fixes the issue. [1] https://syzkaller.appspot.com/bug?extid=040e8b3db6a96908d470 [2] https://syzkaller.appspot.com/bug?extid=348331f63b034f89b622 Fixes: c49c33637802 ("HID: support for initialization of some Thrustmaster wheels") Reported-by: [email protected] Tested-by: [email protected] Signed-off-by: Karol Przybylski <[email protected]> Signed-off-by: Jiri Kosina <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Jiri Kosina <[email protected]> Date: Thu Dec 12 10:19:32 2024 +0100 HID: multitouch: fix support for Goodix PID 0x01e9 [ Upstream commit 8ade5e05bd094485ce370fad66a6a3fb6f50bfbc ] Commit c8000deb68365b ("HID: multitouch: Add support for GT7868Q") added support for 0x01e8 and 0x01e9, but the mt_device[] entries were added twice for 0x01e8 and there was none added for 0x01e9. Fix that. Fixes: c8000deb68365b ("HID: multitouch: Add support for GT7868Q") Reported-by: He Lugang <[email protected]> Reported-by: WangYuli <[email protected]> Reported-by: Ulrich Müller <[email protected]> Signed-off-by: Jiri Kosina <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Al Viro <[email protected]> Date: Sat Jan 11 01:37:44 2025 -0500 hostfs: fix string handling in __dentry_name() [ Upstream commit 60a6002432448bb3f291d80768ae98d62efc9c77 ] strcpy() should not be used with destination potentially overlapping the source; what's more, strscpy() in there is pointless - we already know the amount we want to copy; might as well use memcpy(). Fixes: c278e81b8a02 "hostfs: Remove open coded strcpy()" Signed-off-by: Al Viro <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Uwe Kleine-König <[email protected]> Date: Tue Dec 3 18:31:49 2024 +0100 hwmon: (nct6775): Actually make use of the HWMON_NCT6775 symbol namespace [ Upstream commit 2505f87eb3af55f3dd7f57d7cb7783b94b52a2d9 ] DEFAULT_SYMBOL_NAMESPACE must already be defined when <linux/export.h> is included. So move the define above the include block. Fixes: c3963bc0a0cf ("hwmon: (nct6775) Split core and platform driver") Signed-off-by: Uwe Kleine-König <[email protected]> Signed-off-by: Guenter Roeck <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Joel Stanley <[email protected]> Date: Fri Jan 10 22:17:36 2025 +1030 hwmon: Fix help text for aspeed-g6-pwm-tach [ Upstream commit c8571eab11131cce6dcce76b3345c1524e074071 ] The help text has the wrong module name mentioned, and the capitalisation of the title is inconsistent. Fixes: 7e1449cd15d1 ("hwmon: (aspeed-g6-pwm-tacho): Support for ASPEED g6 PWM/Fan tach") Signed-off-by: Joel Stanley <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Guenter Roeck <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Uwe Kleine-König <[email protected]> Date: Mon Dec 30 16:59:49 2024 +0100 i2c: designware: Actually make use of the I2C_DW_COMMON and I2C_DW symbol namespaces [ Upstream commit f0a4e9fa656ceb3b2e4c296cf6226798d804fa22 ] DEFAULT_SYMBOL_NAMESPACE must already be defined when <linux/export.h> is included. So move the define above the include block. Fixes: fd57a3325a77 ("i2c: designware: Move exports to I2C_DW namespaces") Signed-off-by: Uwe Kleine-König <[email protected]> Acked-by: Jarkko Nikula <[email protected]> Acked-by: Andy Shevchenko <[email protected]> Signed-off-by: Wolfram Sang <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Pei Xiao <[email protected]> Date: Wed Nov 27 18:35:11 2024 +0800 i3c: dw: Fix use-after-free in dw_i3c_master driver due to race condition [ Upstream commit b75439c945b94dd8a2b645355bdb56f948052601 ] In dw_i3c_common_probe, &master->hj_work is bound with dw_i3c_hj_work. And dw_i3c_master_irq_handler can call dw_i3c_master_irq_handle_ibis function to start the work. If we remove the module which will call dw_i3c_common_remove to make cleanup, it will free master->base through i3c_master_unregister while the work mentioned above will be used. The sequence of operations that may lead to a UAF bug is as follows: CPU0 CPU1 | dw_i3c_hj_work dw_i3c_common_remove | i3c_master_unregister(&master->base) | device_unregister(&master->dev) | device_release | //free master->base | | i3c_master_do_daa(&master->base) | //use master->base Fix it by ensuring that the work is canceled before proceeding with the cleanup in dw_i3c_common_remove. Fixes: 1dd728f5d4d4 ("i3c: master: Add driver for Synopsys DesignWare IP") Signed-off-by: Pei Xiao <[email protected]> Acked-by: Mukesh Kumar Savaliya <[email protected]> Link: https://lore.kernel.org/r/bfc49c9527be5b513e7ceafeba314ca40a5be4bc.1732703537.git.xiaopei01@kylinos.cn Signed-off-by: Alexandre Belloni <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Michal Swiatkowski <[email protected]> Date: Thu Sep 5 11:14:10 2024 +0200 iavf: allow changing VLAN state without calling PF [ Upstream commit ee7d79433d783346430ee32f28c9df44a88b3bb6 ] First case: > ip l a l $VF name vlanx type vlan id 100 > ip l d vlanx > ip l a l $VF name vlanx type vlan id 100 As workqueue can be execute after sometime, there is a window to have call trace like that: - iavf_del_vlan - iavf_add_vlan - iavf_del_vlans (wq) It means that our VLAN 100 will change the state from IAVF_VLAN_ACTIVE to IAVF_VLAN_REMOVE (iavf_del_vlan). After that in iavf_add_vlan state won't be changed because VLAN 100 is on the filter list. The final result is that the VLAN 100 filter isn't added in hardware (no iavf_add_vlans call). To fix that change the state if the filter wasn't removed yet directly to active. It is save as IAVF_VLAN_REMOVE means that virtchnl message wasn't sent yet. Second case: > ip l a l $VF name vlanx type vlan id 100 Any type of VF reset ex. change trust > ip l s $PF vf $VF_NUM trust on > ip l d vlanx > ip l a l $VF name vlanx type vlan id 100 In case of reset iavf driver is responsible for readding all filters that are being used. To do that all VLAN filters state are changed to IAVF_VLAN_ADD. Here is even longer window for changing VLAN state from kernel side, as workqueue isn't called immediately. We can have call trace like that: - changing to IAVF_VLAN_ADD (after reset) - iavf_del_vlan (called from kernel ops) - iavf_del_vlans (wq) Not exsisitng VLAN filters will be removed from hardware. It isn't a bug, ice driver will handle it fine. However, we can have call trace like that: - changing to IAVF_VLAN_ADD (after reset) - iavf_del_vlan (called from kernel ops) - iavf_add_vlan (called from kernel ops) - iavf_del_vlans (wq) With fix for previous case we end up with no VLAN filters in hardware. We have to remove VLAN filters if the state is IAVF_VLAN_ADD and delete VLAN was called. It is save as IAVF_VLAN_ADD means that virtchnl message wasn't sent yet. Fixes: 0c0da0e95105 ("iavf: refactor VLAN filter states") Signed-off-by: Michal Swiatkowski <[email protected]> Reviewed-by: Przemek Kitszel <[email protected]> Tested-by: Rafal Romanowski <[email protected]> Signed-off-by: Tony Nguyen <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Przemek Kitszel <[email protected]> Date: Thu Dec 19 12:55:16 2024 +0100 ice: fix ice_parser_rt::bst_key array size [ Upstream commit 18625e26fefced78f2ae28b25e80a07079821e04 ] Fix &ice_parser_rt::bst_key size. It was wrongly set to 10 instead of 20 in the initial impl commit (see Fixes tag). All usage code assumed it was of size 20. That was also the initial size present up to v2 of the intro series [2], but halved by v3 [3] refactor described as "Replace magic hardcoded values with macros." The introducing series was so big that some ugliness was unnoticed, same for bugs :/ ICE_BST_KEY_TCAM_SIZE and ICE_BST_TCAM_KEY_SIZE were differing by one. There was tmp variable @j in the scope of edited function, but was not used in all places. This ugliness is now gone. I'm moving ice_parser_rt::pg_prio a few positions up, to fill up one of the holes in order to compensate for the added 10 bytes to the ::bst_key, resulting in the same size of the whole as prior to the fix, and minimal changes in the offsets of the fields. Extend also the debug dump print of the key to cover all bytes. To not have string with 20 "%02x" and 20 params, switch to ice_debug_array_w_prefix(). This fix obsoletes Ahmed's attempt at [1]. [1] https://lore.kernel.org/intel-wired-lan/[email protected] [2] https://lore.kernel.org/intel-wired-lan/[email protected] [3] https://lore.kernel.org/intel-wired-lan/[email protected] Reported-by: Dan Carpenter <[email protected]> Closes: https://lore.kernel.org/intel-wired-lan/[email protected] Fixes: 9a4c07aaa0f5 ("ice: add parser execution main loop") CC: Ahmed Zaki <[email protected]> Reviewed-by: Larysa Zaremba <[email protected]> Signed-off-by: Przemek Kitszel <[email protected]> Reviewed-by: Simon Horman <[email protected]> Tested-by: Rafal Romanowski <[email protected]> Signed-off-by: Tony Nguyen <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Mateusz Polchlopek <[email protected]> Date: Tue Dec 31 10:50:44 2024 +0100 ice: remove invalid parameter of equalizer [ Upstream commit c5cc2a27e04f2fcd77c74ada9aef76a758a24697 ] It occurred that in the commit 70838938e89c ("ice: Implement driver functionality to dump serdes equalizer values") the invalid DRATE parameter for reading has been added. The output of the command: $ ethtool -d <ethX> returns the garbage value in the place where DRATE value should be stored. Remove mentioned parameter to prevent return of corrupted data to userspace. Fixes: 70838938e89c ("ice: Implement driver functionality to dump serdes equalizer values") Signed-off-by: Mateusz Polchlopek <[email protected]> Reviewed-by: Michal Swiatkowski <[email protected]> Tested-by: Rinitha S <[email protected]> (A Contingent worker at Intel) Signed-off-by: Tony Nguyen <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Manoj Vishwanathan <[email protected]> Date: Mon Dec 16 16:27:33 2024 +0000 idpf: Acquire the lock before accessing the xn->salt [ Upstream commit d15fe4edd7decdf14d8ad2b78df100ea23302065 ] The transaction salt was being accessed before acquiring the idpf_vc_xn_lock when idpf has to forward the virtchnl reply. Fixes: 34c21fa894a1 ("idpf: implement virtchnl transaction manager") Signed-off-by: Manoj Vishwanathan <[email protected]> Signed-off-by: David Decotigny <[email protected]> Signed-off-by: Brian Vazquez <[email protected]> Reviewed-by: Jacob Keller <[email protected]> Reviewed-by: Pavan Kumar Linga <[email protected]> Tested-by: Krishneil Singh <[email protected]> Signed-off-by: Tony Nguyen <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Emil Tantilov <[email protected]> Date: Thu Nov 21 20:40:59 2024 -0800 idpf: add read memory barrier when checking descriptor done bit [ Upstream commit 396f0165672c6a74d7379027d344b83b5f05948c ] Add read memory barrier to ensure the order of operations when accessing control queue descriptors. Specifically, we want to avoid cases where loads can be reordered: 1. Load #1 is dispatched to read descriptor flags. 2. Load #2 is dispatched to read some other field from the descriptor. 3. Load #2 completes, accessing memory/cache at a point in time when the DD flag is zero. 4. NIC DMA overwrites the descriptor, now the DD flag is one. 5. Any fields loaded before step 4 are now inconsistent with the actual descriptor state. Add read memory barrier between steps 1 and 2, so that load #2 is not executed until load #1 has completed. Fixes: 8077c727561a ("idpf: add controlq init and reset checks") Reviewed-by: Przemek Kitszel <[email protected]> Reviewed-by: Sridhar Samudrala <[email protected]> Suggested-by: Lance Richardson <[email protected]> Signed-off-by: Emil Tantilov <[email protected]> Tested-by: Krishneil Singh <[email protected]> Signed-off-by: Tony Nguyen <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Marco Leogrande <[email protected]> Date: Mon Dec 16 16:27:34 2024 +0000 idpf: convert workqueues to unbound [ Upstream commit 9a5b021cb8186f1854bac2812bd4f396bb1e881c ] When a workqueue is created with `WQ_UNBOUND`, its work items are served by special worker-pools, whose host workers are not bound to any specific CPU. In the default configuration (i.e. when `queue_delayed_work` and friends do not specify which CPU to run the work item on), `WQ_UNBOUND` allows the work item to be executed on any CPU in the same node of the CPU it was enqueued on. While this solution potentially sacrifices locality, it avoids contention with other processes that might dominate the CPU time of the processor the work item was scheduled on. This is not just a theoretical problem: in a particular scenario misconfigured process was hogging most of the time from CPU0, leaving less than 0.5% of its CPU time to the kworker. The IDPF workqueues that were using the kworker on CPU0 suffered large completion delays as a result, causing performance degradation, timeouts and eventual system crash. Tested: * I have also run a manual test to gauge the performance improvement. The test consists of an antagonist process (`./stress --cpu 2`) consuming as much of CPU 0 as possible. This process is run under `taskset 01` to bind it to CPU0, and its priority is changed with `chrt -pQ 9900 10000 ${pid}` and `renice -n -20 ${pid}` after start. Then, the IDPF driver is forced to prefer CPU0 by editing all calls to `queue_delayed_work`, `mod_delayed_work`, etc... to use CPU 0. Finally, `ktraces` for the workqueue events are collected. Without the current patch, the antagonist process can force arbitrary delays between `workqueue_queue_work` and `workqueue_execute_start`, that in my tests were as high as `30ms`. With the current patch applied, the workqueue can be migrated to another unloaded CPU in the same node, and, keeping everything else equal, the maximum delay I could see was `6us`. Fixes: 0fe45467a104 ("idpf: add create vport and netdev configuration") Signed-off-by: Marco Leogrande <[email protected]> Signed-off-by: Manoj Vishwanathan <[email protected]> Signed-off-by: Brian Vazquez <[email protected]> Reviewed-by: Jacob Keller <[email protected]> Reviewed-by: Pavan Kumar Linga <[email protected]> Tested-by: Krishneil Singh <[email protected]> Signed-off-by: Tony Nguyen <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Emil Tantilov <[email protected]> Date: Thu Dec 19 18:09:32 2024 -0800 idpf: fix transaction timeouts on reset [ Upstream commit 137da75ba72593598898a4e79da34f4b2da5d151 ] Restore the call to idpf_vc_xn_shutdown() at the beginning of idpf_vc_core_deinit() provided the function is not called on remove. In the reset path the mailbox is destroyed, leading to all transactions timing out. Fixes: 09d0fb5cb30e ("idpf: deinit virtchnl transaction manager after vport and vectors") Reviewed-by: Larysa Zaremba <[email protected]> Signed-off-by: Emil Tantilov <[email protected]> Reviewed-by: Simon Horman <[email protected]> Tested-by: Krishneil Singh <[email protected]> Signed-off-by: Tony Nguyen <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Eric Dumazet <[email protected]> Date: Tue Jan 14 22:10:49 2025 +0000 inet: ipmr: fix data-races [ Upstream commit 3440fa34ad99d471f1085bc2f4dedeaebc310261 ] Following fields of 'struct mr_mfc' can be updated concurrently (no lock protection) from ip_mr_forward() and ip6_mr_forward() - bytes - pkt - wrong_if - lastuse They also can be read from other functions. Convert bytes, pkt and wrong_if to atomic_long_t, and use READ_ONCE()/WRITE_ONCE() for lastuse. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Eric Dumazet <[email protected]> Reviewed-by: David Ahern <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Eric Dumazet <[email protected]> Date: Sun Dec 15 17:56:29 2024 +0000 inetpeer: do not get a refcount in inet_getpeer() [ Upstream commit a853c609504e2d1d83e71285e3622fda1f1451d8 ] All inet_getpeer() callers except ip4_frag_init() don't need to acquire a permanent refcount on the inetpeer. They can switch to full RCU protection. Move the refcount_inc_not_zero() into ip4_frag_init(), so that all the other callers no longer have to perform a pair of expensive atomic operations on a possibly contended cache line. inet_putpeer() no longer needs to be exported. After this patch, my DUT can receive 8,400,000 UDP packets per second targeting closed ports, using 50% less cpu cycles than before. Also change two calls to l3mdev_master_ifindex() by l3mdev_master_ifindex_rcu() (Ido ideas) Fixes: 8c2bd38b95f7 ("icmp: change the order of rate limits") Signed-off-by: Eric Dumazet <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Eric Dumazet <[email protected]> Date: Sun Dec 15 17:56:27 2024 +0000 inetpeer: remove create argument of inet_getpeer() [ Upstream commit 7a596a50c4a4eab946aec149171c72321b4934aa ] All callers of inet_getpeer() want to create an inetpeer. Signed-off-by: Eric Dumazet <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Stable-dep-of: a853c609504e ("inetpeer: do not get a refcount in inet_getpeer()") Signed-off-by: Sasha Levin <[email protected]>
Author: Eric Dumazet <[email protected]> Date: Sun Dec 15 17:56:26 2024 +0000 inetpeer: remove create argument of inet_getpeer_v[46]() [ Upstream commit 661cd8fc8e9039819ca0c22e0add52b632240a9e ] All callers of inet_getpeer_v4() and inet_getpeer_v6() want to create an inetpeer. Signed-off-by: Eric Dumazet <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Stable-dep-of: a853c609504e ("inetpeer: do not get a refcount in inet_getpeer()") Signed-off-by: Sasha Levin <[email protected]>
Author: Eric Dumazet <[email protected]> Date: Sun Dec 15 17:56:28 2024 +0000 inetpeer: update inetpeer timestamp in inet_getpeer() [ Upstream commit 50b362f21d6c10b0f7939c1482c6a1b43da82f1a ] inet_putpeer() will be removed in the following patch, because we will no longer use refcounts. Update inetpeer timestamp (p->dtime) at lookup time. Signed-off-by: Eric Dumazet <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Stable-dep-of: a853c609504e ("inetpeer: do not get a refcount in inet_getpeer()") Signed-off-by: Sasha Levin <[email protected]>
Author: Jens Axboe <[email protected]> Date: Wed Jan 22 17:03:28 2025 -0700 io_uring/msg_ring: don't leave potentially dangling ->tctx pointer [ Upstream commit 69a62e03f896a7382671877b6ad6aab87c53e9c3 ] For remote posting of messages, req->tctx is assigned even though it is never used. Rather than leave a dangling pointer, just clear it to NULL and use the previous check for a valid submitter_task to gate on whether or not the request should be terminated. Reported-by: Jann Horn <[email protected]> Fixes: b6f58a3f4aa8 ("io_uring: move struct io_kiocb from task_struct to io_uring_task") Signed-off-by: Jens Axboe <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Jens Axboe <[email protected]> Date: Fri Jan 24 14:32:25 2025 -0700 io_uring/register: use atomic_read/write for sq_flags migration [ Upstream commit a23ad06bfee5e51cd9e51aebf11401e7b4b5d00a ] A previous commit changed all of the migration from the old to the new ring for resizing to use READ/WRITE_ONCE. However, ->sq_flags is an atomic_t, and while most archs won't complain on this, some will indeed flag this: io_uring/register.c:554:9: sparse: sparse: cast to non-scalar io_uring/register.c:554:9: sparse: sparse: cast from non-scalar Just use atomic_set/atomic_read for handling this case. Reported-by: kernel test robot <[email protected]> Closes: https://lore.kernel.org/oe-kbuild-all/[email protected]/ Fixes: 2c5aae129f42 ("io_uring/register: document io_register_resize_rings() shared mem usage") Signed-off-by: Jens Axboe <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Jens Axboe <[email protected]> Date: Wed Jan 22 17:29:31 2025 -0700 io_uring/uring_cmd: use cached cmd_op in io_uring_cmd_sock() [ Upstream commit d58d82bd0efd6c8edd452fc2f6c6dd052ec57cb2 ] io_uring_cmd_sock() does a normal read of cmd->sqe->cmd_op, where it really should be using a READ_ONCE() as ->sqe may still be pointing to the original SQE. Since the prep side already does this READ_ONCE() and stores it locally, use that value rather than re-read it. Fixes: 8e9fad0e70b7b ("io_uring: Add io_uring command support for sockets") Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jens Axboe <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Pavel Begunkov <[email protected]> Date: Sun Dec 8 21:43:22 2024 +0000 io_uring: prevent reg-wait speculations [ Upstream commit 29b95ac917927ce9f95bf38797e16333ecb489b1 ] With *ENTER_EXT_ARG_REG instead of passing a user pointer with arguments for the waiting loop the user can specify an offset into a pre-mapped region of memory, in which case the [offset, offset + sizeof(io_uring_reg_wait)) will be intepreted as the argument. As we address a kernel array using a user given index, it'd be a subject to speculation type of exploits. Use array_index_nospec() to prevent that. Make sure to pass not the full region size but truncate by the maximum offset allowed considering the structure size. Fixes: d617b3147d54c ("io_uring: restore back registered wait arguments") Fixes: aa00f67adc2c0 ("io_uring: add support for fixed wait regions") Signed-off-by: Pavel Begunkov <[email protected]> Link: https://lore.kernel.org/r/1e3d9da7c43d619de7bcf41d1cd277ab2688c443.1733694126.git.asml.silence@gmail.com Signed-off-by: Jens Axboe <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Jason Gunthorpe <[email protected]> Date: Fri Jan 10 12:35:03 2025 -0400 iommu/amd: Change amd_iommu_pgtable to use enum protection_domain_mode [ Upstream commit 13b4ec749163710e3d188d2fed7405308b1b1e73 ] Currently it uses enum io_pgtable_fmt which is from the io pagetable code and most of the enum values are invalid. protection_domain_mode is internal the driver and has the only two valid values. Fix some signatures and variables to use the right type as well. Reviewed-by: Vasant Hegde <[email protected]> Signed-off-by: Jason Gunthorpe <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Joerg Roedel <[email protected]> Stable-dep-of: 082f1bcae8d1 ("iommu/amd: Fully decode all combinations of alloc_paging_flags") Signed-off-by: Sasha Levin <[email protected]>
Author: Jason Gunthorpe <[email protected]> Date: Fri Jan 10 12:35:05 2025 -0400 iommu/amd: Fully decode all combinations of alloc_paging_flags [ Upstream commit 082f1bcae8d1b5f76e92e369091176b8d61120ec ] Currently AMD does not support IOMMU_HWPT_ALLOC_PASID | IOMMU_HWPT_ALLOC_DIRTY_TRACKING It should be rejected. Instead it creates a V1 domain without dirty tracking support. Use a switch to fully decode the flags. Fixes: ce2cd175469f ("iommu/amd: Enhance amd_iommu_domain_alloc_user()") Reviewed-by: Vasant Hegde <[email protected]> Signed-off-by: Jason Gunthorpe <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Joerg Roedel <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Jason Gunthorpe <[email protected]> Date: Fri Jan 10 12:35:01 2025 -0400 iommu/amd: Remove dev == NULL checks [ Upstream commit 02bcd1a8b991c6fc29271fa02250bea1b61fb742 ] This is no longer possible, amd_iommu_domain_alloc_paging_flags() is never called with dev = NULL from the core code. Similarly get_amd_iommu_from_dev() can never be NULL either. Reviewed-by: Vasant Hegde <[email protected]> Signed-off-by: Jason Gunthorpe <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Joerg Roedel <[email protected]> Stable-dep-of: 082f1bcae8d1 ("iommu/amd: Fully decode all combinations of alloc_paging_flags") Signed-off-by: Sasha Levin <[email protected]>
Author: Jason Gunthorpe <[email protected]> Date: Fri Jan 10 12:35:00 2025 -0400 iommu/amd: Remove domain_alloc() [ Upstream commit f9b80f941e0e68c3347c5d22a17a0f636a064e2c ] IOMMU drivers should not be sensitive to the domain type, a paging domain should be created based only on the flags passed in, the same for all callers. AMD was using the domain_alloc() path to force VFIO into a v1 domain type, because v1 gives higher performance. However now that IOMMU_HWPT_ALLOC_PASID is present, and a NULL device is not possible, domain_alloc_paging_flags() will do the right thing for VFIO. When invoked from VFIO flags will be 0 and the amd_iommu_pgtable type of domain will be selected. This is v1 by default unless the kernel command line has overridden it to v2. If the admin is forcing v2 assume they know what they are doing so force it everywhere, including for VFIO. Reviewed-by: Vasant Hegde <[email protected]> Signed-off-by: Jason Gunthorpe <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Joerg Roedel <[email protected]> Stable-dep-of: 082f1bcae8d1 ("iommu/amd: Fully decode all combinations of alloc_paging_flags") Signed-off-by: Sasha Levin <[email protected]>
Author: Jason Gunthorpe <[email protected]> Date: Fri Jan 10 12:35:02 2025 -0400 iommu/amd: Remove type argument from do_iommu_domain_alloc() and related [ Upstream commit 55b237dd7f7ec2ee9c7986e0fc28c5867bf63282 ] do_iommu_domain_alloc() is only called from amd_iommu_domain_alloc_paging_flags() so type is always IOMMU_DOMAIN_UNMANAGED. Remove type and all the dead conditionals checking it. IOMMU_DOMAIN_IDENTITY checks are similarly obsolete as the conversion to the global static identity domain removed those call paths. The caller of protection_domain_alloc() should set the type, fix the miss in the SVA code. Reviewed-by: Vasant Hegde <[email protected]> Signed-off-by: Jason Gunthorpe <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Joerg Roedel <[email protected]> Stable-dep-of: 082f1bcae8d1 ("iommu/amd: Fully decode all combinations of alloc_paging_flags") Signed-off-by: Sasha Levin <[email protected]>
Author: Alejandro Jimenez <[email protected]> Date: Fri Jan 10 12:34:59 2025 -0400 iommu/amd: Remove unused amd_iommu_domain_update() [ Upstream commit 1a684b099fac9a37e6fe2f0e594adbb1eff5181a ] All the callers have been removed by the below commit, remove the implementation and prototypes. Fixes: 322d889ae7d3 ("iommu/amd: Remove amd_iommu_domain_update() from page table freeing") Reviewed-by: Vasant Hegde <[email protected]> Signed-off-by: Alejandro Jimenez <[email protected]> Signed-off-by: Jason Gunthorpe <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Joerg Roedel <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Jason Gunthorpe <[email protected]> Date: Thu Dec 5 11:40:15 2024 -0400 iommu/arm-smmuv3: Update comments about ATS and bypass [ Upstream commit 9b640ae7fbba13d45a8b9712dff2911a0c2b5ff4 ] The SMMUv3 spec has a note that BYPASS and ATS don't work together under the STE EATS field definition. However there is another section "13.6.4 Full ATS skipping stage 1" that explains under certain conditions BYPASS and ATS do work together if the STE is using S1DSS to select BYPASS and the CD table has the possibility for a substream. When these comments were written the understanding was that all forms of BYPASS just didn't work and this was to be a future problem to solve. It turns out that ATS and IDENTITY will always work just fine: - If STE.Config = BYPASS then the PCI ATS is disabled - If a PASID domain is attached then S1DSS = BYPASS and ATS will be enabled. This meets the requirements of 13.6.4 to automatically generate 1:1 ATS replies on the RID. Update the comments to reflect this. Fixes: 7497f4211f4f ("iommu/arm-smmu-v3: Make changing domains be hitless for ATS") Signed-off-by: Jason Gunthorpe <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Will Deacon <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Guo Ren <[email protected]> Date: Thu Jan 2 21:46:16 2025 -0500 iommu/riscv: Fixup compile warning [ Upstream commit 10c62c38b073ecea775b7e23fa7c7a3995a84ff3 ] When __BITS_PER_LONG == 32, size_t is defined as unsigned int rather than unsigned long. Therefore, we should use size_t to avoid type-checking errors. Fixes: 488ffbf18171 ("iommu/riscv: Paging domain support") Signed-off-by: Guo Ren <[email protected]> Signed-off-by: Guo Ren <[email protected]> Cc: Tomasz Jeznach <[email protected]> Reviewed-by: Charlie Jenkins <[email protected]> Reviewed-by: Tomasz Jeznach <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Joerg Roedel <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Lu Baolu <[email protected]> Date: Tue Jan 7 10:17:45 2025 +0800 iommu/vt-d: Draining PRQ in sva unbind path when FPD bit set [ Upstream commit cf08ca81d08a04b3b304e8fb4e052f323a09783d ] When a device uses a PASID for SVA (Shared Virtual Address), it's possible that the PASID entry is marked as non-present and FPD bit set before the device flushes all ongoing DMA requests and removes the SVA domain. This can occur when an exception happens and the process terminates before the device driver stops DMA and calls the iommu driver to unbind the PASID. There's no need to drain the PRQ in the mm release path. Instead, the PRQ will be drained in the SVA unbind path. But in such case, intel_pasid_tear_down_entry() only checks the presence of the pasid entry and returns directly. Add the code to clear the FPD bit and drain the PRQ. Fixes: c43e1ccdebf2 ("iommu/vt-d: Drain PRQs when domain removed from RID") Suggested-by: Kevin Tian <[email protected]> Signed-off-by: Lu Baolu <[email protected]> Reviewed-by: Kevin Tian <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Joerg Roedel <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Suraj Sonawane <[email protected]> Date: Sun Nov 24 01:29:00 2024 +0530 iommu: iommufd: fix WARNING in iommufd_device_unbind [ Upstream commit d9df72c6acd683adf6dd23c061f3a414ec00b1f8 ] Fix an issue detected by syzbot: WARNING in iommufd_device_unbind iommufd: Time out waiting for iommufd object to become free Resolve a warning in iommufd_device_unbind caused by a timeout while waiting for the shortterm_users reference count to reach zero. The existing 10-second timeout is insufficient in some scenarios, resulting in failures the above warning. Increase the timeout in iommufd_object_dec_wait_shortterm from 10 seconds to 60 seconds to allow sufficient time for the reference count to drop to zero. This change prevents premature timeouts and reduces the likelihood of warnings during iommufd_device_unbind. Fixes: 6f9c4d8c468c ("iommufd: Do not UAF during iommufd_put_object()") Link: https://patch.msgid.link/r/[email protected] Reported-by: [email protected] Closes: https://syzkaller.appspot.com/bug?extid=c92878e123785b1fa2db Tested-by: [email protected] Signed-off-by: Suraj Sonawane <[email protected]> Signed-off-by: Jason Gunthorpe <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Qasim Ijaz <[email protected]> Date: Mon Jan 13 22:38:20 2025 +0000 iommufd/iova_bitmap: Fix shift-out-of-bounds in iova_bitmap_offset_to_index() [ Upstream commit e24c1551059268b37f6f40639883eafb281b8b9c ] Resolve a UBSAN shift-out-of-bounds issue in iova_bitmap_offset_to_index() where shifting the constant "1" (of type int) by bitmap->mapped.pgshift (an unsigned long value) could result in undefined behavior. The constant "1" defaults to a 32-bit "int", and when "pgshift" exceeds 31 (e.g., pgshift = 63) the shift operation overflows, as the result cannot be represented in a 32-bit type. To resolve this, the constant is updated to "1UL", promoting it to an unsigned long type to match the operand's type. Fixes: 58ccf0190d19 ("vfio: Add an IOVA bitmap support") Link: https://patch.msgid.link/r/[email protected] Reported-by: syzbot <[email protected]> Closes: https://syzkaller.appspot.com/bug?extid=85992ace37d5b7b51635 Signed-off-by: Qasim Ijaz <[email protected]> Reviewed-by: Joao Martins <[email protected]> Signed-off-by: Jason Gunthorpe <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Charles Han <[email protected]> Date: Thu Sep 26 17:44:19 2024 +0800 ipmi: ipmb: Add check devm_kasprintf() returned value [ Upstream commit 2378bd0b264ad3a1f76bd957caf33ee0c7945351 ] devm_kasprintf() can return a NULL pointer on failure but this returned value is not checked. Fixes: 51bd6f291583 ("Add support for IPMB driver") Signed-off-by: Charles Han <[email protected]> Message-ID: <[email protected]> Signed-off-by: Corey Minyard <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Quan Nguyen <[email protected]> Date: Tue Jan 7 10:47:34 2025 +0700 ipmi: ssif_bmc: Fix new request loss when bmc ready for a response [ Upstream commit 83d8c79aa958e37724ed9c14dc7d0f66a48ad864 ] Cosmo found that when there is a new request comes in while BMC is ready for a response, the complete_response(), which is called to complete the pending response, would accidentally clear out that new request and force ssif_bmc to move back to abort state again. This commit is to address that issue. Fixes: dd2bc5cc9e25 ("ipmi: ssif_bmc: Add SSIF BMC driver") Reported-by: Cosmo Chou <[email protected]> Closes: https://lore.kernel.org/lkml/[email protected]/ Signed-off-by: Quan Nguyen <[email protected]> Message-ID: <[email protected]> Signed-off-by: Corey Minyard <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Eric Dumazet <[email protected]> Date: Tue Jan 21 18:12:41 2025 +0000 ipmr: do not call mr_mfc_uses_dev() for unres entries [ Upstream commit 15a901361ec3fb1c393f91880e1cbf24ec0a88bd ] syzbot found that calling mr_mfc_uses_dev() for unres entries would crash [1], because c->mfc_un.res.minvif / c->mfc_un.res.maxvif alias to "struct sk_buff_head unresolved", which contain two pointers. This code never worked, lets remove it. [1] Unable to handle kernel paging request at virtual address ffff5fff2d536613 KASAN: maybe wild-memory-access in range [0xfffefff96a9b3098-0xfffefff96a9b309f] Modules linked in: CPU: 1 UID: 0 PID: 7321 Comm: syz.0.16 Not tainted 6.13.0-rc7-syzkaller-g1950a0af2d55 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : mr_mfc_uses_dev net/ipv4/ipmr_base.c:290 [inline] pc : mr_table_dump+0x5a4/0x8b0 net/ipv4/ipmr_base.c:334 lr : mr_mfc_uses_dev net/ipv4/ipmr_base.c:289 [inline] lr : mr_table_dump+0x694/0x8b0 net/ipv4/ipmr_base.c:334 Call trace: mr_mfc_uses_dev net/ipv4/ipmr_base.c:290 [inline] (P) mr_table_dump+0x5a4/0x8b0 net/ipv4/ipmr_base.c:334 (P) mr_rtm_dumproute+0x254/0x454 net/ipv4/ipmr_base.c:382 ipmr_rtm_dumproute+0x248/0x4b4 net/ipv4/ipmr.c:2648 rtnl_dump_all+0x2e4/0x4e8 net/core/rtnetlink.c:4327 rtnl_dumpit+0x98/0x1d0 net/core/rtnetlink.c:6791 netlink_dump+0x4f0/0xbc0 net/netlink/af_netlink.c:2317 netlink_recvmsg+0x56c/0xe64 net/netlink/af_netlink.c:1973 sock_recvmsg_nosec net/socket.c:1033 [inline] sock_recvmsg net/socket.c:1055 [inline] sock_read_iter+0x2d8/0x40c net/socket.c:1125 new_sync_read fs/read_write.c:484 [inline] vfs_read+0x740/0x970 fs/read_write.c:565 ksys_read+0x15c/0x26c fs/read_write.c:708 Fixes: cb167893f41e ("net: Plumb support for filtering ipv4 and ipv6 multicast route dumps") Reported-by: [email protected] Closes: https://lore.kernel.org/netdev/[email protected]/T/#u Signed-off-by: Eric Dumazet <[email protected]> Reviewed-by: David Ahern <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Masahiro Yamada <[email protected]> Date: Fri Jan 31 23:04:01 2025 +0900 kbuild: fix Clang LTO with CONFIG_OBJTOOL=n [ Upstream commit 695ed93bb30e03e9f826ee70abdd83f970741a37 ] Since commit bede169618c6 ("kbuild: enable objtool for *.mod.o and additional kernel objects"), Clang LTO builds do not perform any optimizations when CONFIG_OBJTOOL is disabled (e.g., for ARCH=arm64). This is because every LLVM bitcode file is immediately converted to ELF format before the object files are linked together. This commit fixes the breakage. Fixes: bede169618c6 ("kbuild: enable objtool for *.mod.o and additional kernel objects") Reported-by: Yonghong Song <[email protected]> Signed-off-by: Masahiro Yamada <[email protected]> Tested-by: Yonghong Song <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Torsten Hilbrich <[email protected]> Date: Mon Jan 13 07:01:29 2025 +0100 kbuild: Fix signing issue for external modules [ Upstream commit 25ff08aa43e373a61c3e36fc7d7cae88ed0fc2d7 ] When running the sign script the kernel is within the source directory of external modules. This caused issues when the kernel uses relative paths, like: make[5]: Entering directory '/build/client/devel/kernel/work/linux-2.6' make[6]: Entering directory '/build/client/devel/addmodules/vtx/work/vtx' INSTALL /build/client/devel/addmodules/vtx/_/lib/modules/6.13.0-devel+/extra/vtx.ko SIGN /build/client/devel/addmodules/vtx/_/lib/modules/6.13.0-devel+/extra/vtx.ko /bin/sh: 1: scripts/sign-file: not found DEPMOD /build/client/devel/addmodules/vtx/_/lib/modules/6.13.0-devel+ Working around it by using absolute pathes here. Fixes: 13b25489b6f8 ("kbuild: change working directory to external module directory with M=") Signed-off-by: Torsten Hilbrich <[email protected]> Signed-off-by: Masahiro Yamada <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Masahiro Yamada <[email protected]> Date: Mon Jan 20 16:59:14 2025 +0900 kconfig: fix file name in warnings when loading KCONFIG_DEFCONFIG_LIST [ Upstream commit a314f52a0210730d0d556de76bb7388e76d4597d ] Most 'make *config' commands use .config as the base configuration file. When .config does not exist, Kconfig tries to load a file listed in KCONFIG_DEFCONFIG_LIST instead. However, since commit b75b0a819af9 ("kconfig: change defconfig_list option to environment variable"), warning messages have displayed an incorrect file name in such cases. Below is a demonstration using Debian Trixie. While loading /boot/config-6.12.9-amd64, the warning messages incorrectly show .config as the file name. With this commit, the correct file name is displayed in warnings. [Before] $ rm -f .config $ make config # # using defaults found in /boot/config-6.12.9-amd64 # .config:6804:warning: symbol value 'm' invalid for FB_BACKLIGHT .config:9895:warning: symbol value 'm' invalid for ANDROID_BINDER_IPC [After] $ rm -f .config $ make config # # using defaults found in /boot/config-6.12.9-amd64 # /boot/config-6.12.9-amd64:6804:warning: symbol value 'm' invalid for FB_BACKLIGHT /boot/config-6.12.9-amd64:9895:warning: symbol value 'm' invalid for ANDROID_BINDER_IPC Fixes: b75b0a819af9 ("kconfig: change defconfig_list option to environment variable") Signed-off-by: Masahiro Yamada <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Masahiro Yamada <[email protected]> Date: Mon Jan 20 17:10:31 2025 +0900 kconfig: fix memory leak in sym_warn_unmet_dep() [ Upstream commit a409fc1463d664002ea9bf700ae4674df03de111 ] The string allocated in sym_warn_unmet_dep() is never freed, leading to a memory leak when an unmet dependency is detected. Fixes: f8f69dc0b4e0 ("kconfig: make unmet dependency warnings readable") Signed-off-by: Masahiro Yamada <[email protected]> Reviewed-by: Petr Vorel <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Liam R. Howlett <[email protected]> Date: Mon Jan 27 12:02:21 2025 -0500 kernel: be more careful about dup_mmap() failures and uprobe registering [ Upstream commit 64c37e134b120fb462fb4a80694bfb8e7be77b14 ] If a memory allocation fails during dup_mmap(), the maple tree can be left in an unsafe state for other iterators besides the exit path. All the locks are dropped before the exit_mmap() call (in mm/mmap.c), but the incomplete mm_struct can be reached through (at least) the rmap finding the vmas which have a pointer back to the mm_struct. Up to this point, there have been no issues with being able to find an mm_struct that was only partially initialised. Syzbot was able to make the incomplete mm_struct fail with recent forking changes, so it has been proven unsafe to use the mm_struct that hasn't been initialised, as referenced in the link below. Although 8ac662f5da19f ("fork: avoid inappropriate uprobe access to invalid mm") fixed the uprobe access, it does not completely remove the race. This patch sets the MMF_OOM_SKIP to avoid the iteration of the vmas on the oom side (even though this is extremely unlikely to be selected as an oom victim in the race window), and sets MMF_UNSTABLE to avoid other potential users from using a partially initialised mm_struct. When registering vmas for uprobe, skip the vmas in an mm that is marked unstable. Modifying a vma in an unstable mm may cause issues if the mm isn't fully initialised. Link: https://lore.kernel.org/all/[email protected]/ Link: https://lkml.kernel.org/r/[email protected] Fixes: d24062914837 ("fork: use __mt_dup() to duplicate maple tree in dup_mmap()") Signed-off-by: Liam R. Howlett <[email protected]> Reviewed-by: Lorenzo Stoakes <[email protected]> Cc: Oleg Nesterov <[email protected]> Cc: Masami Hiramatsu <[email protected]> Cc: Jann Horn <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Michal Hocko <[email protected]> Cc: Peng Zhang <[email protected]> Cc: Matthew Wilcox <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Ricardo B. Marliere <[email protected]> Date: Thu Dec 5 17:50:35 2024 -0300 ktest.pl: Check kernelrelease return in get_version commit a4e17a8f239a545c463f8ec27db4ed6e74b31841 upstream. In the case of a test that uses the special option ${KERNEL_VERSION} in one of its settings but has no configuration available in ${OUTPUT_DIR}, for example if it's a new empty directory, then the `make kernelrelease` call will fail and the subroutine will chomp an empty string, silently. Fix that by adding an empty configuration and retrying. Cc: [email protected] Cc: John Hawley <[email protected]> Fixes: 5f9b6ced04a4e ("ktest: Bisecting, install modules, add logging") Link: https://lore.kernel.org/[email protected] Signed-off-by: Ricardo B. Marliere <[email protected]> Signed-off-by: Steven Rostedt <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Ba Jing <[email protected]> Date: Mon Sep 2 21:07:35 2024 +0800 ktest.pl: Remove unused declarations in run_bisect_test function [ Upstream commit 776735b954f49f85fd19e1198efa421fae2ad77c ] Since $output and $ret are not used in the subsequent code, the declarations should be removed. Fixes: a75fececff3c ("ktest: Added sample.conf, new %default option format") Link: https://lore.kernel.org/[email protected] Signed-off-by: Ba Jing <[email protected]> Signed-off-by: Steven Rostedt <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Sean Christopherson <[email protected]> Date: Wed Nov 27 16:00:09 2024 -0800 KVM: x86: Plumb in the vCPU to kvm_x86_ops.hwapic_isr_update() commit 76bce9f10162cd4b36ac0b7889649b22baf70ebd upstream. Pass the target vCPU to the hwapic_isr_update() vendor hook so that VMX can defer the update until after nested VM-Exit if an EOI for L1's vAPIC occurs while L2 is active. Note, commit d39850f57d21 ("KVM: x86: Drop @vcpu parameter from kvm_x86_ops.hwapic_isr_update()") removed the parameter with the justification that doing so "allows for a decent amount of (future) cleanup in the APIC code", but it's not at all clear what cleanup was intended, or if it was ever realized. No functional change intended. Cc: [email protected] Reviewed-by: Chao Gao <[email protected]> Tested-by: Chao Gao <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sean Christopherson <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Mickaël Salaün <[email protected]> Date: Fri Jan 10 16:39:13 2025 +0100 landlock: Handle weird files [ Upstream commit 49440290a0935f428a1e43a5ac8dc275a647ff80 ] A corrupted filesystem (e.g. bcachefs) might return weird files. Instead of throwing a warning and allowing access to such file, treat them as regular files. Cc: Dave Chinner <[email protected]> Cc: Kent Overstreet <[email protected]> Cc: Paul Moore <[email protected]> Reported-by: [email protected] Closes: https://lore.kernel.org/r/[email protected] Reported-by: [email protected] Closes: https://lore.kernel.org/r/[email protected] Reported-by: Ubisectech Sirius <[email protected]> Closes: https://lore.kernel.org/r/[email protected] Fixes: cb2c7d1a1776 ("landlock: Support filesystem access-control") Reviewed-by: Günther Noack <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mickaël Salaün <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Joe Hattori <[email protected]> Date: Fri Dec 20 17:53:46 2024 +0900 leds: cht-wcove: Use devm_led_classdev_register() to avoid memory leak [ Upstream commit 417cad5dc782096350e6a967ee5dd3417a19a24e ] cht_wc_leds_probe() leaks memory when the second led_classdev_register() call in the for-loop fails as it does not call the cleanup function led_classdev_unregister() on the first device. Avoid this leak by calling devm_led_classdev_register(). Fixes: 047da762b9a9 ("leds: Add Intel Cherry Trail Whiskey Cove PMIC LED driver") Signed-off-by: Joe Hattori <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Lee Jones <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Joe Hattori <[email protected]> Date: Mon Dec 16 16:49:23 2024 +0900 leds: netxbig: Fix an OF node reference leak in netxbig_leds_get_of_pdata() [ Upstream commit 0508316be63bb735f59bdc8fe4527cadb62210ca ] netxbig_leds_get_of_pdata() does not release the OF node obtained by of_parse_phandle() when of_find_device_by_node() fails. Add an of_node_put() call to fix the leak. This bug was found by an experimental static analysis tool that I am developing. Fixes: 9af512e81964 ("leds: netxbig: Convert to use GPIO descriptors") Signed-off-by: Joe Hattori <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Lee Jones <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Andrii Nakryiko <[email protected]> Date: Thu Nov 21 14:45:58 2024 -0800 libbpf: don't adjust USDT semaphore address if .stapsdt.base addr is missing [ Upstream commit 98ebe5ef6f5c4517ba92fb3e56f95827ebea83fd ] USDT ELF note optionally can record an offset of .stapsdt.base, which is used to make adjustments to USDT target attach address. Currently, libbpf will do this address adjustment unconditionally if it finds .stapsdt.base ELF section in target binary. But there is a corner case where .stapsdt.base ELF section is present, but specific USDT note doesn't reference it. In such case, libbpf will basically just add base address and end up with absolutely incorrect USDT target address. This adjustment has to be done only if both .stapsdt.sema section is present and USDT note is recording a reference to it. Fixes: 74cc6311cec9 ("libbpf: Add USDT notes parsing and resolution logic") Signed-off-by: Andrii Nakryiko <[email protected]> Acked-by: Jiri Olsa <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Alexei Starovoitov <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Pu Lehui <[email protected]> Date: Wed Jan 15 10:02:40 2025 +0000 libbpf: Fix incorrect traversal end type ID when marking BTF_IS_EMBEDDED [ Upstream commit 5ca681a86ef93369685cb63f71994f4cf7303e7c ] When redirecting the split BTF to the vmlinux base BTF, we need to mark the distilled base struct/union members of split BTF structs/unions in id_map with BTF_IS_EMBEDDED. This indicates that these types must match both name and size later. Therefore, we need to traverse the entire split BTF, which involves traversing type IDs from nr_dist_base_types to nr_types. However, the current implementation uses an incorrect traversal end type ID, so let's correct it. Fixes: 19e00c897d50 ("libbpf: Split BTF relocation") Signed-off-by: Pu Lehui <[email protected]> Signed-off-by: Andrii Nakryiko <[email protected]> Link: https://lore.kernel.org/bpf/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Pu Lehui <[email protected]> Date: Wed Jan 15 10:02:39 2025 +0000 libbpf: Fix return zero when elf_begin failed [ Upstream commit 5436a54332c19df0acbef2b87cbf9f7cba56f2dd ] The error number of elf_begin is omitted when encapsulating the btf_find_elf_sections function. Fixes: c86f180ffc99 ("libbpf: Make btf_parse_elf process .BTF.base transparently") Signed-off-by: Pu Lehui <[email protected]> Signed-off-by: Andrii Nakryiko <[email protected]> Link: https://lore.kernel.org/bpf/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Quentin Monnet <[email protected]> Date: Thu Dec 5 13:59:42 2024 +0000 libbpf: Fix segfault due to libelf functions not setting errno [ Upstream commit e10500b69c3f3378f3dcfc8c2fe4cdb74fc844f5 ] Libelf functions do not set errno on failure. Instead, it relies on its internal _elf_errno value, that can be retrieved via elf_errno (or the corresponding message via elf_errmsg()). From "man libelf": If a libelf function encounters an error it will set an internal error code that can be retrieved with elf_errno. Each thread maintains its own separate error code. The meaning of each error code can be determined with elf_errmsg, which returns a string describing the error. As a consequence, libbpf should not return -errno when a function from libelf fails, because an empty value will not be interpreted as an error and won't prevent the program to stop. This is visible in bpf_linker__add_file(), for example, where we call a succession of functions that rely on libelf: err = err ?: linker_load_obj_file(linker, filename, opts, &obj); err = err ?: linker_append_sec_data(linker, &obj); err = err ?: linker_append_elf_syms(linker, &obj); err = err ?: linker_append_elf_relos(linker, &obj); err = err ?: linker_append_btf(linker, &obj); err = err ?: linker_append_btf_ext(linker, &obj); If the object file that we try to process is not, in fact, a correct object file, linker_load_obj_file() may fail with errno not being set, and return 0. In this case we attempt to run linker_append_elf_sysms() and may segfault. This can happen (and was discovered) with bpftool: $ bpftool gen object output.o sample_ret0.bpf.c libbpf: failed to get ELF header for sample_ret0.bpf.c: invalid `Elf' handle zsh: segmentation fault (core dumped) bpftool gen object output.o sample_ret0.bpf.c Fix the issue by returning a non-null error code (-EINVAL) when libelf functions fail. Fixes: faf6ed321cf6 ("libbpf: Add BPF static linker APIs") Signed-off-by: Quentin Monnet <[email protected]> Signed-off-by: Andrii Nakryiko <[email protected]> Link: https://lore.kernel.org/bpf/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Greg Kroah-Hartman <[email protected]> Date: Sat Feb 8 10:02:27 2025 +0100 Linux 6.13.2 Link: https://lore.kernel.org/r/[email protected] Tested-by: Ronald Warsow <[email protected]> Tested-by: Pavel Machek (CIP) <[email protected]> Tested-by: Florian Fainelli <[email protected]> Tested-by: Peter Schneider <[email protected]> Tested-by: Justin M. Forbes <[email protected]> Tested-by: Hardik Garg <[email protected]> Tested-by: Ron Economos <[email protected]> Tested-by: Luna Jernberg <[email protected]> Tested-by: Mark Brown <[email protected]> Tested-by: Christian Heusel <[email protected]> Link: https://lore.kernel.org/r/[email protected] Tested-by: Ronald Warsow <[email protected]> Tested-by: Luna Jernberg <[email protected]> Tested-by: Florian Fainelli <[email protected]> Tested-by: Jiri Slaby <[email protected]> Tested-by: Jon Hunter <[email protected]> Tested-by: Salvatore Bonaccorso <[email protected]> Tested-by: Linux Kernel Functional Testing <[email protected]> Tested-by: Mark Brown <[email protected]> Tested-by: Pavel Machek (CIP) <[email protected]> Tested-By: Achill Gilgenast <[email protected]> Tested-by: Hardik Garg <[email protected]> Tested-by: Takeshi Ogasawara <[email protected]> Tested-by: Peter Schneider <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Tiezhu Yang <[email protected]> Date: Sun Jan 26 21:49:59 2025 +0800 LoongArch: Change 8 to 14 for LOONGARCH_MAX_{BRP,WRP} commit f502ea618bf16d615d7dc6138c8988d3118fe750 upstream. The maximum number of load/store watchpoints and fetch instruction watchpoints is 14 each according to LoongArch Reference Manual, so change 8 to 14 for the related code. Link: https://loongson.github.io/LoongArch-Documentation/LoongArch-Vol1-EN.html#control-and-status-registers-related-to-watchpoints Cc: [email protected] Fixes: edffa33c7bb5 ("LoongArch: Add hardware breakpoints/watchpoints support") Reviewed-by: WANG Xuerui <[email protected]> Signed-off-by: Tiezhu Yang <[email protected]> Signed-off-by: Huacai Chen <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Huacai Chen <[email protected]> Date: Sun Jan 26 21:49:59 2025 +0800 LoongArch: Fix warnings during S3 suspend [ Upstream commit 26c0a2d93af55d30a46d5f45d3e9c42cde730168 ] The enable_gpe_wakeup() function calls acpi_enable_all_wakeup_gpes(), and the later one may call the preempt_schedule_common() function, resulting in a thread switch and causing the CPU to be in an interrupt enabled state after the enable_gpe_wakeup() function returns, leading to the warnings as follow. [ C0] WARNING: ... at kernel/time/timekeeping.c:845 ktime_get+0xbc/0xc8 [ C0] ... [ C0] Call Trace: [ C0] [<90000000002243b4>] show_stack+0x64/0x188 [ C0] [<900000000164673c>] dump_stack_lvl+0x60/0x88 [ C0] [<90000000002687e4>] __warn+0x8c/0x148 [ C0] [<90000000015e9978>] report_bug+0x1c0/0x2b0 [ C0] [<90000000016478e4>] do_bp+0x204/0x3b8 [ C0] [<90000000025b1924>] exception_handlers+0x1924/0x10000 [ C0] [<9000000000343bbc>] ktime_get+0xbc/0xc8 [ C0] [<9000000000354c08>] tick_sched_timer+0x30/0xb0 [ C0] [<90000000003408e0>] __hrtimer_run_queues+0x160/0x378 [ C0] [<9000000000341f14>] hrtimer_interrupt+0x144/0x388 [ C0] [<9000000000228348>] constant_timer_interrupt+0x38/0x48 [ C0] [<90000000002feba4>] __handle_irq_event_percpu+0x64/0x1e8 [ C0] [<90000000002fed48>] handle_irq_event_percpu+0x20/0x80 [ C0] [<9000000000306b9c>] handle_percpu_irq+0x5c/0x98 [ C0] [<90000000002fd4a0>] generic_handle_domain_irq+0x30/0x48 [ C0] [<9000000000d0c7b0>] handle_cpu_irq+0x70/0xa8 [ C0] [<9000000001646b30>] handle_loongarch_irq+0x30/0x48 [ C0] [<9000000001646bc8>] do_vint+0x80/0xe0 [ C0] [<90000000002aea1c>] finish_task_switch.isra.0+0x8c/0x2a8 [ C0] [<900000000164e34c>] __schedule+0x314/0xa48 [ C0] [<900000000164ead8>] schedule+0x58/0xf0 [ C0] [<9000000000294a2c>] worker_thread+0x224/0x498 [ C0] [<900000000029d2f0>] kthread+0xf8/0x108 [ C0] [<9000000000221f28>] ret_from_kernel_thread+0xc/0xa4 [ C0] [ C0] ---[ end trace 0000000000000000 ]--- The root cause is acpi_enable_all_wakeup_gpes() uses a mutex to protect acpi_hw_enable_all_wakeup_gpes(), and acpi_ut_acquire_mutex() may cause a thread switch. Since there is no longer concurrent execution during loongarch_acpi_suspend(), we can call acpi_hw_enable_all_wakeup_gpes() directly in enable_gpe_wakeup(). The solution is similar to commit 22db06337f590d01 ("ACPI: sleep: Avoid breaking S3 wakeup due to might_sleep()"). Fixes: 366bb35a8e48 ("LoongArch: Add suspend (ACPI S3) support") Signed-off-by: Qunqin Zhao <[email protected]> Signed-off-by: Huacai Chen <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Dan Carpenter <[email protected]> Date: Sat Nov 30 13:07:23 2024 +0300 mailbox: mpfs: fix copy and paste bug in probe [ Upstream commit f055feb49c1c4333abb80ce1e9d93841cf74ea84 ] This code accidentally checks ->ctrl_base instead of ->mbox_base so the error handling can never be triggered. Fixes: a4123ffab9ec ("mailbox: mpfs: support new, syscon based, devicetree configuration") Signed-off-by: Dan Carpenter <[email protected]> Reviewed-by: Conor Dooley <[email protected]> Signed-off-by: Jassi Brar <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Dan Carpenter <[email protected]> Date: Sat Nov 30 13:07:39 2024 +0300 mailbox: th1520: Fix a NULL vs IS_ERR() bug [ Upstream commit d0f98e14c010bcf27898b635a54c1994ac4110a8 ] The devm_ioremap() function doesn't return error pointers, it returns NULL. Update the error checking to match. Fixes: 5d4d263e1c6b ("mailbox: Introduce support for T-head TH1520 Mailbox driver") Signed-off-by: Dan Carpenter <[email protected]> Reviewed-by: Michal Wilczynski <[email protected]> Signed-off-by: Jassi Brar <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Michal Wilczynski <[email protected]> Date: Mon Dec 2 11:05:35 2024 +0100 mailbox: th1520: Fix memory corruption due to incorrect array size [ Upstream commit db049866943a38bf46a34fa120d526663339d7a5 ] The functions th1520_mbox_suspend_noirq and th1520_mbox_resume_noirq are intended to save and restore the interrupt mask registers in the MBOX ICU0. However, the array used to store these registers was incorrectly sized, leading to memory corruption when accessing all four registers. This commit corrects the array size to accommodate all four interrupt mask registers, preventing memory corruption during suspend and resume operations. Fixes: 5d4d263e1c6b ("mailbox: Introduce support for T-head TH1520 Mailbox driver") Reported-by: Dan Carpenter <[email protected]> Closes: https://lore.kernel.org/all/[email protected]/ Signed-off-by: Michal Wilczynski <[email protected]> Signed-off-by: Jassi Brar <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Yu Kuai <[email protected]> Date: Thu Jan 9 09:51:41 2025 +0800 md/md-bitmap: factor behind write counters out from bitmap_{start/end}write() commit 08c50142a128dcb2d7060aa3b4c5db8837f7a46a upstream. behind_write is only used in raid1, prepare to refactor bitmap_{start/end}write(), there are no functional changes. Signed-off-by: Yu Kuai <[email protected]> Reviewed-by: Xiao Ni <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Song Liu <[email protected]> Signed-off-by: Yu Kuai <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Yu Kuai <[email protected]> Date: Thu Jan 9 09:51:45 2025 +0800 md/md-bitmap: move bitmap_{start, end}write to md upper layer commit cd5fc653381811f1e0ba65f5d169918cab61476f upstream. There are two BUG reports that raid5 will hang at bitmap_startwrite([1],[2]), root cause is that bitmap start write and end write is unbalanced, it's not quite clear where, and while reviewing raid5 code, it's found that bitmap operations can be optimized. For example, for a 4 disks raid5, with chunksize=8k, if user issue a IO (0 + 48k) to the array: ┌────────────────────────────────────────────────────────────┐ │chunk 0 │ │ ┌────────────┬─────────────┬─────────────┬────────────┼ │ sh0 │A0: 0 + 4k │A1: 8k + 4k │A2: 16k + 4k │A3: P │ │ ┼────────────┼─────────────┼─────────────┼────────────┼ │ sh1 │B0: 4k + 4k │B1: 12k + 4k │B2: 20k + 4k │B3: P │ ┼──────┴────────────┴─────────────┴─────────────┴────────────┼ │chunk 1 │ │ ┌────────────┬─────────────┬─────────────┬────────────┤ │ sh2 │C0: 24k + 4k│C1: 32k + 4k │C2: P │C3: 40k + 4k│ │ ┼────────────┼─────────────┼─────────────┼────────────┼ │ sh3 │D0: 28k + 4k│D1: 36k + 4k │D2: P │D3: 44k + 4k│ └──────┴────────────┴─────────────┴─────────────┴────────────┘ Before this patch, 4 stripe head will be used, and each sh will attach bio for 3 disks, and each attached bio will trigger bitmap_startwrite() once, which means total 12 times. - 3 times (0 + 4k), for (A0, A1 and A2) - 3 times (4 + 4k), for (B0, B1 and B2) - 3 times (8 + 4k), for (C0, C1 and C3) - 3 times (12 + 4k), for (D0, D1 and D3) After this patch, md upper layer will calculate that IO range (0 + 48k) is corresponding to the bitmap (0 + 16k), and call bitmap_startwrite() just once. Noted that this patch will align bitmap ranges to the chunks, for example, if user issue a IO (0 + 4k) to array: - Before this patch, 1 time (0 + 4k), for A0; - After this patch, 1 time (0 + 8k) for chunk 0; Usually, one bitmap bit will represent more than one disk chunk, and this doesn't have any difference. And even if user really created a array that one chunk contain multiple bits, the overhead is that more data will be recovered after power failure. Also remove STRIPE_BITMAP_PENDING since it's not used anymore. [1] https://lore.kernel.org/all/CAJpMwyjmHQLvm6zg1cmQErttNNQPDAAXPKM3xgTjMhbfts986Q@mail.gmail.com/ [2] https://lore.kernel.org/all/[email protected]/ Signed-off-by: Yu Kuai <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Song Liu <[email protected]> Signed-off-by: Yu Kuai <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Yu Kuai <[email protected]> Date: Thu Jan 9 09:51:42 2025 +0800 md/md-bitmap: remove the last parameter for bimtap_ops->endwrite() commit 4f0e7d0e03b7b80af84759a9e7cfb0f81ac4adae upstream. For the case that IO failed for one rdev, the bit will be mark as NEEDED in following cases: 1) If badblocks is set and rdev is not faulty; 2) If rdev is faulty; Case 1) is useless because synchronize data to badblocks make no sense. Case 2) can be replaced with mddev->degraded. Also remove R1BIO_Degraded, R10BIO_Degraded and STRIPE_DEGRADED since case 2) no longer use them. Signed-off-by: Yu Kuai <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Song Liu <[email protected]> Signed-off-by: Yu Kuai <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Yu Kuai <[email protected]> Date: Fri Jan 24 17:20:55 2025 +0800 md/md-bitmap: Synchronize bitmap_get_stats() with bitmap lifetime commit 8d28d0ddb986f56920ac97ae704cc3340a699a30 upstream. After commit ec6bb299c7c3 ("md/md-bitmap: add 'sync_size' into struct md_bitmap_stats"), following panic is reported: Oops: general protection fault, probably for non-canonical address RIP: 0010:bitmap_get_stats+0x2b/0xa0 Call Trace: <TASK> md_seq_show+0x2d2/0x5b0 seq_read_iter+0x2b9/0x470 seq_read+0x12f/0x180 proc_reg_read+0x57/0xb0 vfs_read+0xf6/0x380 ksys_read+0x6c/0xf0 do_syscall_64+0x82/0x170 entry_SYSCALL_64_after_hwframe+0x76/0x7e Root cause is that bitmap_get_stats() can be called at anytime if mddev is still there, even if bitmap is destroyed, or not fully initialized. Deferenceing bitmap in this case can crash the kernel. Meanwhile, the above commit start to deferencing bitmap->storage, make the problem easier to trigger. Fix the problem by protecting bitmap_get_stats() with bitmap_info.mutex. Cc: [email protected] # v6.12+ Fixes: 32a7627cf3a3 ("[PATCH] md: optimised resync using Bitmap based intent logging") Reported-and-tested-by: Harshit Mogalapalli <[email protected]> Closes: https://lore.kernel.org/linux-raid/[email protected]/T/#m6e5086c95201135e4941fe38f9efa76daf9666c5 Signed-off-by: Yu Kuai <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Song Liu <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Yu Kuai <[email protected]> Date: Thu Jan 9 09:51:44 2025 +0800 md/raid5: implement pers->bitmap_sector() commit 9c89f604476cf15c31fbbdb043cff7fbf1dbe0cb upstream. Bitmap is used for the whole array for raid1/raid10, hence IO for the array can be used directly for bitmap. However, bitmap is used for underlying disks for raid5, hence IO for the array can't be used directly for bitmap. Implement pers->bitmap_sector() for raid5 to convert IO ranges from the array to the underlying disks. Signed-off-by: Yu Kuai <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Song Liu <[email protected]> Signed-off-by: Yu Kuai <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Yu Kuai <[email protected]> Date: Thu Jan 9 09:51:43 2025 +0800 md: add a new callback pers->bitmap_sector() commit 0c984a283a3ea3f10bebecd6c57c1d41b2e4f518 upstream. This callback will be used in raid5 to convert io ranges from array to bitmap. Signed-off-by: Yu Kuai <[email protected]> Reviewed-by: Xiao Ni <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Song Liu <[email protected]> Signed-off-by: Yu Kuai <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Jiasheng Jiang <[email protected]> Date: Mon Nov 25 19:18:17 2024 +0000 media: camif-core: Add check for clk_enable() [ Upstream commit 77ed2470ac09c2b0a33cf3f98cc51d18ba9ed976 ] Add check for the return value of clk_enable() to gurantee the success. Fixes: babde1c243b2 ("[media] V4L: Add driver for S3C24XX/S3C64XX SoC series camera interface") Signed-off-by: Jiasheng Jiang <[email protected]> Reviewed-by: Krzysztof Kozlowski <[email protected]> Signed-off-by: Sakari Ailus <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Desnes Nunes <[email protected]> Date: Thu Sep 19 14:27:55 2024 -0300 media: dvb-usb-v2: af9035: fix ISO C90 compilation error on af9035_i2c_master_xfer [ Upstream commit c36b9ad1a8add3c114e25fe167efa217a813b0c7 ] This fixes a 'ISO C90 forbids mixed declarations and code' compilation error on af9035_i2c_master_xfer, which is caused by the sanity check added on user controlled msg[i], before declaring the demodulator register. Fixes: 7bf744f2de0a ("media: dvb-usb-v2: af9035: Fix null-ptr-deref in af9035_i2c_master_xfer") Signed-off-by: Desnes Nunes <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mauro Carvalho Chehab <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Dave Stevenson <[email protected]> Date: Wed Nov 20 19:17:04 2024 +0000 media: i2c: imx290: Register 0x3011 varies between imx327 and imx290 [ Upstream commit f2055c1d62d6dfd25a31d1d1923883f21305aea5 ] Reviewing the datasheets, register 0x3011 is meant to be 0x02 on imx327 and 0x00 on imx290. Move it out of the common registers, and set it appropriately in the sensor specific sections. (Included for imx290 to be explicit, rather than relying on the default value). Fixes: 2d41947ec2c0 ("media: i2c: imx290: Add support for imx327 variant") Signed-off-by: Dave Stevenson <[email protected]> Reviewed-by: Laurent Pinchart <[email protected]> Signed-off-by: Sakari Ailus <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Luca Weiss <[email protected]> Date: Mon Nov 18 22:45:46 2024 +0100 media: i2c: imx412: Add missing newline to prints [ Upstream commit 33f4a7fba7229232e294f4794503283e44cd03f2 ] Add trailing \n to dev_dbg and dev_err prints where missing. Signed-off-by: Luca Weiss <[email protected]> Fixes: 9214e86c0cc1 ("media: i2c: Add imx412 camera sensor driver") Signed-off-by: Sakari Ailus <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Dave Stevenson <[email protected]> Date: Mon Dec 9 14:55:45 2024 +0000 media: i2c: ov9282: Correct the exposure offset [ Upstream commit feaf4154d69657af2bf96e6e66cca794f88b1a61 ] The datasheet lists that "Maximum exposure time is frame length -25 row periods, where frame length is set by registers {0x380E, 0x380F}". However this driver had OV9282_EXPOSURE_OFFSET set to 12 which allowed that restriction to be violated, and would result in very under-exposed images. Correct the offset. Fixes: 14ea315bbeb7 ("media: i2c: Add ov9282 camera sensor driver") Signed-off-by: Dave Stevenson <[email protected]> Reviewed-by: Kieran Bingham <[email protected]> Signed-off-by: Sakari Ailus <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Dan Carpenter <[email protected]> Date: Thu Oct 17 23:34:16 2024 +0300 media: imx-jpeg: Fix potential error pointer dereference in detach_pm() commit 1378ffec30367233152b7dbf4fa6a25ee98585d1 upstream. The proble is on the first line: if (jpeg->pd_dev[i] && !pm_runtime_suspended(jpeg->pd_dev[i])) If jpeg->pd_dev[i] is an error pointer, then passing it to pm_runtime_suspended() will lead to an Oops. The other conditions check for both error pointers and NULL, but it would be more clear to use the IS_ERR_OR_NULL() check for that. Fixes: fd0af4cd35da ("media: imx-jpeg: Ensure power suppliers be suspended before detach them") Cc: <[email protected]> Signed-off-by: Dan Carpenter <[email protected]> Reviewed-by: Ming Qian <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Chen Ni <[email protected]> Date: Tue May 21 17:10:42 2024 +0800 media: lmedm04: Handle errors for lme2510_int_read [ Upstream commit a2836d3fe220220ff8c495ca9722f89cea8a67e7 ] Add check for the return value of usb_pipe_endpoint() and usb_submit_urb() in order to catch the errors. Fixes: 15e1ce33182d ("[media] lmedm04: Fix usb_submit_urb BOGUS urb xfer, pipe 1 != type 3 in interrupt urb") Signed-off-by: Chen Ni <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mauro Carvalho Chehab <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Jiasheng Jiang <[email protected]> Date: Tue Dec 3 21:29:02 2024 +0000 media: marvell: Add check for clk_enable() [ Upstream commit 11f68d2ba2e1521a608af773bf788e8cfa260f68 ] Add check for the return value of clk_enable() to guarantee the success. Fixes: 81a409bfd551 ("media: marvell-ccic: provide a clock for the sensor") Signed-off-by: Jiasheng Jiang <[email protected]> [Sakari Ailus: Fix spelling in commit message.] Signed-off-by: Sakari Ailus <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Jiasheng Jiang <[email protected]> Date: Mon Nov 25 19:18:18 2024 +0000 media: mipi-csis: Add check for clk_enable() [ Upstream commit 125ad1aeec77eb55273b420be6894b284a01e4b6 ] Add check for the return value of clk_enable() to gurantee the success. Fixes: b5f1220d587d ("[media] v4l: Add v4l2 subdev driver for S5P/EXYNOS4 MIPI-CSI receivers") Signed-off-by: Jiasheng Jiang <[email protected]> Reviewed-by: Krzysztof Kozlowski <[email protected]> Signed-off-by: Sakari Ailus <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Laurentiu Palcu <[email protected]> Date: Tue Sep 24 13:33:04 2024 +0300 media: nxp: imx8-isi: fix v4l2-compliance test errors [ Upstream commit 7b12ab055edef2f51733d155617a401a05237bcc ] Running the v4l2-compliance (1.27.0-5208, SHA: af114250d48d) on the m2m device fails on the MMAP streaming tests, with the following messages: fail: v4l2-test-buffers.cpp(240): g_field() == V4L2_FIELD_ANY fail: v4l2-test-buffers.cpp(1508): buf.qbuf(node) Apparently, the driver does not properly set the field member of vb2_v4l2_buffer struct, returning the default V4L2_FIELD_ANY value which is against the guidelines. Fixes: cf21f328fcaf ("media: nxp: Add i.MX8 ISI driver") Signed-off-by: Laurentiu Palcu <[email protected]> Reviewed-by: Laurent Pinchart <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Laurent Pinchart <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Oliver Neukum <[email protected]> Date: Tue Nov 26 14:17:22 2024 +0100 media: rc: iguanair: handle timeouts [ Upstream commit b98d5000c50544f14bacb248c34e5219fbe81287 ] In case of a timeout the IO must be cancelled or the next IO using the URB will fail and/or overwrite an operational URB. The automatic bisection fails because it arrives at a commit that correctly lets the test case run without an error. Signed-off-by: Oliver Neukum <[email protected]> Fixes: e99a7cfe93fd ("[media] iguanair: reuse existing urb callback for command responses") Reported-by: [email protected] Closes: https://lore.kernel.org/all/[email protected]/ Tested-by: [email protected] Signed-off-by: Sean Young <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Ricardo Ribalda <[email protected]> Date: Tue Oct 22 08:30:30 2024 +0000 media: uvcvideo: Fix deadlock during uvc_probe [ Upstream commit a67f75c2b5ecf534eab416ce16c11fe780c4f8f6 ] If uvc_probe() fails, it can end up calling uvc_status_unregister() before uvc_status_init() is called. Fix this by checking if dev->status is NULL or not in uvc_status_unregister(). Reported-by: [email protected] Closes: https://lore.kernel.org/linux-media/[email protected]/T/#m506744621d72a2ace5dd2ab64055be9898112dbd Fixes: c5fe3ed618f9 ("media: uvcvideo: Avoid race condition during unregister") Signed-off-by: Ricardo Ribalda <[email protected]> Reviewed-by: Laurent Pinchart <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Laurent Pinchart <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Laurent Pinchart <[email protected]> Date: Fri Nov 8 01:51:30 2024 +0200 media: uvcvideo: Fix double free in error path commit c6ef3a7fa97ec823a1e1af9085cf13db9f7b3bac upstream. If the uvc_status_init() function fails to allocate the int_urb, it will free the dev->status pointer but doesn't reset the pointer to NULL. This results in the kfree() call in uvc_status_cleanup() trying to double-free the memory. Fix it by resetting the dev->status pointer to NULL after freeing it. Fixes: a31a4055473b ("V4L/DVB:usbvideo:don't use part of buffer for USB transfer #4") Cc: [email protected] Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Laurent Pinchart <[email protected]> Reviewed by: Ricardo Ribalda <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Ricardo Ribalda <[email protected]> Date: Wed Dec 18 21:39:08 2024 +0000 media: uvcvideo: Propagate buf->error to userspace [ Upstream commit 87ce177654e388451850905a1d376658aebe8699 ] Now we return VB2_BUF_STATE_DONE for valid and invalid frames. Propagate the correct value, so the user can know if the frame is valid or not via struct v4l2_buffer->flags. Reported-by: Hans de Goede <[email protected]> Closes: https://lore.kernel.org/linux-media/[email protected] Fixes: 6998b6fb4b1c ("[media] uvcvideo: Use videobuf2-vmalloc") Signed-off-by: Ricardo Ribalda <[email protected]> Reviewed-by: Laurent Pinchart <[email protected]> Reviewed-by: Hans de Goede <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Laurent Pinchart <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Chen Ridong <[email protected]> Date: Tue Dec 24 02:52:38 2024 +0000 memcg: fix soft lockup in the OOM process commit ade81479c7dda1ce3eedb215c78bc615bbd04f06 upstream. A soft lockup issue was found in the product with about 56,000 tasks were in the OOM cgroup, it was traversing them when the soft lockup was triggered. watchdog: BUG: soft lockup - CPU#2 stuck for 23s! [VM Thread:1503066] CPU: 2 PID: 1503066 Comm: VM Thread Kdump: loaded Tainted: G Hardware name: Huawei Cloud OpenStack Nova, BIOS RIP: 0010:console_unlock+0x343/0x540 RSP: 0000:ffffb751447db9a0 EFLAGS: 00000247 ORIG_RAX: ffffffffffffff13 RAX: 0000000000000001 RBX: 0000000000000000 RCX: 00000000ffffffff RDX: 0000000000000000 RSI: 0000000000000004 RDI: 0000000000000247 RBP: ffffffffafc71f90 R08: 0000000000000000 R09: 0000000000000040 R10: 0000000000000080 R11: 0000000000000000 R12: ffffffffafc74bd0 R13: ffffffffaf60a220 R14: 0000000000000247 R15: 0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f2fe6ad91f0 CR3: 00000004b2076003 CR4: 0000000000360ee0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: vprintk_emit+0x193/0x280 printk+0x52/0x6e dump_task+0x114/0x130 mem_cgroup_scan_tasks+0x76/0x100 dump_header+0x1fe/0x210 oom_kill_process+0xd1/0x100 out_of_memory+0x125/0x570 mem_cgroup_out_of_memory+0xb5/0xd0 try_charge+0x720/0x770 mem_cgroup_try_charge+0x86/0x180 mem_cgroup_try_charge_delay+0x1c/0x40 do_anonymous_page+0xb5/0x390 handle_mm_fault+0xc4/0x1f0 This is because thousands of processes are in the OOM cgroup, it takes a long time to traverse all of them. As a result, this lead to soft lockup in the OOM process. To fix this issue, call 'cond_resched' in the 'mem_cgroup_scan_tasks' function per 1000 iterations. For global OOM, call 'touch_softlockup_watchdog' per 1000 iterations to avoid this issue. Link: https://lkml.kernel.org/r/[email protected] Fixes: 9cbb78bb3143 ("mm, memcg: introduce own oom handler to iterate only over its own threads") Signed-off-by: Chen Ridong <[email protected]> Acked-by: Michal Hocko <[email protected]> Cc: Roman Gushchin <[email protected]> Cc: Johannes Weiner <[email protected]> Cc: Shakeel Butt <[email protected]> Cc: Muchun Song <[email protected]> Cc: Michal Koutný <[email protected]> Cc: <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Joe Hattori <[email protected]> Date: Tue Dec 17 18:14:34 2024 +0900 memory: tegra20-emc: fix an OF node reference bug in tegra_emc_find_node_by_ram_code() [ Upstream commit b9784e5cde1f9fb83661a70e580e381ae1264d12 ] As of_find_node_by_name() release the reference of the argument device node, tegra_emc_find_node_by_ram_code() releases some device nodes while still in use, resulting in possible UAFs. According to the bindings and the in-tree DTS files, the "emc-tables" node is always device's child node with the property "nvidia,use-ram-code", and the "lpddr2" node is a child of the "emc-tables" node. Thus utilize the for_each_child_of_node() macro and of_get_child_by_name() instead of of_find_node_by_name() to simplify the code. This bug was found by an experimental verification tool that I am developing. Fixes: 96e5da7c8424 ("memory: tegra: Introduce Tegra20 EMC driver") Signed-off-by: Joe Hattori <[email protected]> Link: https://lore.kernel.org/r/[email protected] Link: https://lore.kernel.org/r/[email protected] [krzysztof: applied v1, adjust the commit msg to incorporate v2 parts] Signed-off-by: Krzysztof Kozlowski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Rob Herring (Arm) <[email protected]> Date: Tue Dec 17 12:11:40 2024 -0600 mfd: syscon: Fix race in device_node_get_regmap() [ Upstream commit 805f7aaf7fee14a57b56af01d270edf6c10765e8 ] It is possible for multiple, simultaneous callers calling device_node_get_regmap() with the same node to fail to find an entry in the syscon_list. There is a period of time while the first caller is calling of_syscon_register() that subsequent callers also fail to find an entry in the syscon_list and then call of_syscon_register() a second time. Fix this by keeping the lock held until after of_syscon_register() completes and adds the node to syscon_list. Convert the spinlock to a mutex as many of the functions called in of_syscon_register() such as kzalloc() and of_clk_get() may sleep. Fixes: bdb0066df96e ("mfd: syscon: Decouple syscon interface from platform devices") Signed-off-by: Rob Herring (Arm) <[email protected]> Reviewed-by: Krzysztof Kozlowski <[email protected]> Tested-by: Krzysztof Kozlowski <[email protected]> Tested-by: Will McVicker <[email protected]> Tested-by: Pankaj Dubey <[email protected]> Reviewed-by: Pankaj Dubey <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Lee Jones <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Christophe Leroy <[email protected]> Date: Thu Dec 5 20:46:16 2024 +0100 module: Don't fail module loading when setting ro_after_init section RO failed [ Upstream commit 110b1e070f1d50f5217bd2c758db094998bb7b77 ] Once module init has succeded it is too late to cancel loading. If setting ro_after_init data section to read-only fails, all we can do is to inform the user through a warning. Reported-by: Thomas Gleixner <[email protected]> Closes: https://lore.kernel.org/all/[email protected]/ Fixes: d1909c022173 ("module: Don't ignore errors from set_memory_XX()") Signed-off-by: Christophe Leroy <[email protected]> Reviewed-by: Luis Chamberlain <[email protected]> Link: https://lore.kernel.org/r/d6c81f38da76092de8aacc8c93c4c65cb0fe48b8.1733427536.git.christophe.leroy@csgroup.eu Signed-off-by: Petr Pavlu <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Sebastian Andrzej Siewior <[email protected]> Date: Wed Jan 8 10:04:30 2025 +0100 module: Extend the preempt disabled section in dereference_symbol_descriptor(). [ Upstream commit a145c848d69f9c6f32008d8319edaa133360dd74 ] dereference_symbol_descriptor() needs to obtain the module pointer belonging to pointer in order to resolve that pointer. The returned mod pointer is obtained under RCU-sched/ preempt_disable() guarantees and needs to be used within this section to ensure that the module is not removed in the meantime. Extend the preempt_disable() section to also cover dereference_module_function_descriptor(). Fixes: 04b8eb7a4ccd9 ("symbol lookup: introduce dereference_symbol_descriptor()") Cc: James E.J. Bottomley <[email protected]> Cc: Christophe Leroy <[email protected]> Cc: Helge Deller <[email protected]> Cc: Madhavan Srinivasan <[email protected]> Cc: Michael Ellerman <[email protected]> Cc: Naveen N Rao <[email protected]> Cc: Nicholas Piggin <[email protected]> Cc: Sergey Senozhatsky <[email protected]> Cc: [email protected] Cc: [email protected] Reviewed-by: Sergey Senozhatsky <[email protected]> Acked-by: Peter Zijlstra (Intel) <[email protected]> Signed-off-by: Sebastian Andrzej Siewior <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Petr Pavlu <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Matthieu Baerts (NGI0) <[email protected]> Date: Wed Jan 29 13:24:32 2025 +0100 mptcp: blackhole only if 1st SYN retrans w/o MPC is accepted commit e598d8981fd34470b78a1ae777dbf131b15d5bf2 upstream. The Fixes commit mentioned this: > An MPTCP firewall blackhole can be detected if the following SYN > retransmission after a fallback to "plain" TCP is accepted. But in fact, this blackhole was detected if any following SYN retransmissions after a fallback to TCP was accepted. That's because 'mptcp_subflow_early_fallback()' will set 'request_mptcp' to 0, and 'mpc_drop' will never be reset to 0 after. This is an issue, because some not so unusual situations might cause the kernel to detect a false-positive blackhole, e.g. a client trying to connect to a server while the network is not ready yet, causing a few SYN retransmissions, before reaching the end server. Fixes: 27069e7cb3d1 ("mptcp: disable active MPTCP in case of blackhole") Cc: [email protected] Reviewed-by: Mat Martineau <[email protected]> Signed-off-by: Matthieu Baerts (NGI0) <[email protected]> Signed-off-by: Paolo Abeni <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Paolo Abeni <[email protected]> Date: Thu Jan 23 19:05:54 2025 +0100 mptcp: consolidate suboption status commit c86b000782daba926c627d2fa00c3f60a75e7472 upstream. MPTCP maintains the received sub-options status is the bitmask carrying the received suboptions and in several bitfields carrying per suboption additional info. Zeroing the bitmask before parsing is not enough to ensure a consistent status, and the MPTCP code has to additionally clear some bitfiled depending on the actually parsed suboption. The above schema is fragile, and syzbot managed to trigger a path where a relevant bitfield is not cleared/initialized: BUG: KMSAN: uninit-value in __mptcp_expand_seq net/mptcp/options.c:1030 [inline] BUG: KMSAN: uninit-value in mptcp_expand_seq net/mptcp/protocol.h:864 [inline] BUG: KMSAN: uninit-value in ack_update_msk net/mptcp/options.c:1060 [inline] BUG: KMSAN: uninit-value in mptcp_incoming_options+0x2036/0x3d30 net/mptcp/options.c:1209 __mptcp_expand_seq net/mptcp/options.c:1030 [inline] mptcp_expand_seq net/mptcp/protocol.h:864 [inline] ack_update_msk net/mptcp/options.c:1060 [inline] mptcp_incoming_options+0x2036/0x3d30 net/mptcp/options.c:1209 tcp_data_queue+0xb4/0x7be0 net/ipv4/tcp_input.c:5233 tcp_rcv_established+0x1061/0x2510 net/ipv4/tcp_input.c:6264 tcp_v4_do_rcv+0x7f3/0x11a0 net/ipv4/tcp_ipv4.c:1916 tcp_v4_rcv+0x51df/0x5750 net/ipv4/tcp_ipv4.c:2351 ip_protocol_deliver_rcu+0x2a3/0x13d0 net/ipv4/ip_input.c:205 ip_local_deliver_finish+0x336/0x500 net/ipv4/ip_input.c:233 NF_HOOK include/linux/netfilter.h:314 [inline] ip_local_deliver+0x21f/0x490 net/ipv4/ip_input.c:254 dst_input include/net/dst.h:460 [inline] ip_rcv_finish+0x4a2/0x520 net/ipv4/ip_input.c:447 NF_HOOK include/linux/netfilter.h:314 [inline] ip_rcv+0xcd/0x380 net/ipv4/ip_input.c:567 __netif_receive_skb_one_core net/core/dev.c:5704 [inline] __netif_receive_skb+0x319/0xa00 net/core/dev.c:5817 process_backlog+0x4ad/0xa50 net/core/dev.c:6149 __napi_poll+0xe7/0x980 net/core/dev.c:6902 napi_poll net/core/dev.c:6971 [inline] net_rx_action+0xa5a/0x19b0 net/core/dev.c:7093 handle_softirqs+0x1a0/0x7c0 kernel/softirq.c:561 __do_softirq+0x14/0x1a kernel/softirq.c:595 do_softirq+0x9a/0x100 kernel/softirq.c:462 __local_bh_enable_ip+0x9f/0xb0 kernel/softirq.c:389 local_bh_enable include/linux/bottom_half.h:33 [inline] rcu_read_unlock_bh include/linux/rcupdate.h:919 [inline] __dev_queue_xmit+0x2758/0x57d0 net/core/dev.c:4493 dev_queue_xmit include/linux/netdevice.h:3168 [inline] neigh_hh_output include/net/neighbour.h:523 [inline] neigh_output include/net/neighbour.h:537 [inline] ip_finish_output2+0x187c/0x1b70 net/ipv4/ip_output.c:236 __ip_finish_output+0x287/0x810 ip_finish_output+0x4b/0x600 net/ipv4/ip_output.c:324 NF_HOOK_COND include/linux/netfilter.h:303 [inline] ip_output+0x15f/0x3f0 net/ipv4/ip_output.c:434 dst_output include/net/dst.h:450 [inline] ip_local_out net/ipv4/ip_output.c:130 [inline] __ip_queue_xmit+0x1f2a/0x20d0 net/ipv4/ip_output.c:536 ip_queue_xmit+0x60/0x80 net/ipv4/ip_output.c:550 __tcp_transmit_skb+0x3cea/0x4900 net/ipv4/tcp_output.c:1468 tcp_transmit_skb net/ipv4/tcp_output.c:1486 [inline] tcp_write_xmit+0x3b90/0x9070 net/ipv4/tcp_output.c:2829 __tcp_push_pending_frames+0xc4/0x380 net/ipv4/tcp_output.c:3012 tcp_send_fin+0x9f6/0xf50 net/ipv4/tcp_output.c:3618 __tcp_close+0x140c/0x1550 net/ipv4/tcp.c:3130 __mptcp_close_ssk+0x74e/0x16f0 net/mptcp/protocol.c:2496 mptcp_close_ssk+0x26b/0x2c0 net/mptcp/protocol.c:2550 mptcp_pm_nl_rm_addr_or_subflow+0x635/0xd10 net/mptcp/pm_netlink.c:889 mptcp_pm_nl_rm_subflow_received net/mptcp/pm_netlink.c:924 [inline] mptcp_pm_flush_addrs_and_subflows net/mptcp/pm_netlink.c:1688 [inline] mptcp_nl_flush_addrs_list net/mptcp/pm_netlink.c:1709 [inline] mptcp_pm_nl_flush_addrs_doit+0xe10/0x1630 net/mptcp/pm_netlink.c:1750 genl_family_rcv_msg_doit net/netlink/genetlink.c:1115 [inline] genl_family_rcv_msg net/netlink/genetlink.c:1195 [inline] genl_rcv_msg+0x1214/0x12c0 net/netlink/genetlink.c:1210 netlink_rcv_skb+0x375/0x650 net/netlink/af_netlink.c:2542 genl_rcv+0x40/0x60 net/netlink/genetlink.c:1219 netlink_unicast_kernel net/netlink/af_netlink.c:1321 [inline] netlink_unicast+0xf52/0x1260 net/netlink/af_netlink.c:1347 netlink_sendmsg+0x10da/0x11e0 net/netlink/af_netlink.c:1891 sock_sendmsg_nosec net/socket.c:711 [inline] __sock_sendmsg+0x30f/0x380 net/socket.c:726 ____sys_sendmsg+0x877/0xb60 net/socket.c:2583 ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2637 __sys_sendmsg net/socket.c:2669 [inline] __do_sys_sendmsg net/socket.c:2674 [inline] __se_sys_sendmsg net/socket.c:2672 [inline] __x64_sys_sendmsg+0x212/0x3c0 net/socket.c:2672 x64_sys_call+0x2ed6/0x3c30 arch/x86/include/generated/asm/syscalls_64.h:47 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f Uninit was stored to memory at: mptcp_get_options+0x2c0f/0x2f20 net/mptcp/options.c:397 mptcp_incoming_options+0x19a/0x3d30 net/mptcp/options.c:1150 tcp_data_queue+0xb4/0x7be0 net/ipv4/tcp_input.c:5233 tcp_rcv_established+0x1061/0x2510 net/ipv4/tcp_input.c:6264 tcp_v4_do_rcv+0x7f3/0x11a0 net/ipv4/tcp_ipv4.c:1916 tcp_v4_rcv+0x51df/0x5750 net/ipv4/tcp_ipv4.c:2351 ip_protocol_deliver_rcu+0x2a3/0x13d0 net/ipv4/ip_input.c:205 ip_local_deliver_finish+0x336/0x500 net/ipv4/ip_input.c:233 NF_HOOK include/linux/netfilter.h:314 [inline] ip_local_deliver+0x21f/0x490 net/ipv4/ip_input.c:254 dst_input include/net/dst.h:460 [inline] ip_rcv_finish+0x4a2/0x520 net/ipv4/ip_input.c:447 NF_HOOK include/linux/netfilter.h:314 [inline] ip_rcv+0xcd/0x380 net/ipv4/ip_input.c:567 __netif_receive_skb_one_core net/core/dev.c:5704 [inline] __netif_receive_skb+0x319/0xa00 net/core/dev.c:5817 process_backlog+0x4ad/0xa50 net/core/dev.c:6149 __napi_poll+0xe7/0x980 net/core/dev.c:6902 napi_poll net/core/dev.c:6971 [inline] net_rx_action+0xa5a/0x19b0 net/core/dev.c:7093 handle_softirqs+0x1a0/0x7c0 kernel/softirq.c:561 __do_softirq+0x14/0x1a kernel/softirq.c:595 Uninit was stored to memory at: put_unaligned_be32 include/linux/unaligned.h:68 [inline] mptcp_write_options+0x17f9/0x3100 net/mptcp/options.c:1417 mptcp_options_write net/ipv4/tcp_output.c:465 [inline] tcp_options_write+0x6d9/0xe90 net/ipv4/tcp_output.c:759 __tcp_transmit_skb+0x294b/0x4900 net/ipv4/tcp_output.c:1414 tcp_transmit_skb net/ipv4/tcp_output.c:1486 [inline] tcp_write_xmit+0x3b90/0x9070 net/ipv4/tcp_output.c:2829 __tcp_push_pending_frames+0xc4/0x380 net/ipv4/tcp_output.c:3012 tcp_send_fin+0x9f6/0xf50 net/ipv4/tcp_output.c:3618 __tcp_close+0x140c/0x1550 net/ipv4/tcp.c:3130 __mptcp_close_ssk+0x74e/0x16f0 net/mptcp/protocol.c:2496 mptcp_close_ssk+0x26b/0x2c0 net/mptcp/protocol.c:2550 mptcp_pm_nl_rm_addr_or_subflow+0x635/0xd10 net/mptcp/pm_netlink.c:889 mptcp_pm_nl_rm_subflow_received net/mptcp/pm_netlink.c:924 [inline] mptcp_pm_flush_addrs_and_subflows net/mptcp/pm_netlink.c:1688 [inline] mptcp_nl_flush_addrs_list net/mptcp/pm_netlink.c:1709 [inline] mptcp_pm_nl_flush_addrs_doit+0xe10/0x1630 net/mptcp/pm_netlink.c:1750 genl_family_rcv_msg_doit net/netlink/genetlink.c:1115 [inline] genl_family_rcv_msg net/netlink/genetlink.c:1195 [inline] genl_rcv_msg+0x1214/0x12c0 net/netlink/genetlink.c:1210 netlink_rcv_skb+0x375/0x650 net/netlink/af_netlink.c:2542 genl_rcv+0x40/0x60 net/netlink/genetlink.c:1219 netlink_unicast_kernel net/netlink/af_netlink.c:1321 [inline] netlink_unicast+0xf52/0x1260 net/netlink/af_netlink.c:1347 netlink_sendmsg+0x10da/0x11e0 net/netlink/af_netlink.c:1891 sock_sendmsg_nosec net/socket.c:711 [inline] __sock_sendmsg+0x30f/0x380 net/socket.c:726 ____sys_sendmsg+0x877/0xb60 net/socket.c:2583 ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2637 __sys_sendmsg net/socket.c:2669 [inline] __do_sys_sendmsg net/socket.c:2674 [inline] __se_sys_sendmsg net/socket.c:2672 [inline] __x64_sys_sendmsg+0x212/0x3c0 net/socket.c:2672 x64_sys_call+0x2ed6/0x3c30 arch/x86/include/generated/asm/syscalls_64.h:47 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f Uninit was stored to memory at: mptcp_pm_add_addr_signal+0x3d7/0x4c0 mptcp_established_options_add_addr net/mptcp/options.c:666 [inline] mptcp_established_options+0x1b9b/0x3a00 net/mptcp/options.c:884 tcp_established_options+0x2c4/0x7d0 net/ipv4/tcp_output.c:1012 __tcp_transmit_skb+0x5b7/0x4900 net/ipv4/tcp_output.c:1333 tcp_transmit_skb net/ipv4/tcp_output.c:1486 [inline] tcp_write_xmit+0x3b90/0x9070 net/ipv4/tcp_output.c:2829 __tcp_push_pending_frames+0xc4/0x380 net/ipv4/tcp_output.c:3012 tcp_send_fin+0x9f6/0xf50 net/ipv4/tcp_output.c:3618 __tcp_close+0x140c/0x1550 net/ipv4/tcp.c:3130 __mptcp_close_ssk+0x74e/0x16f0 net/mptcp/protocol.c:2496 mptcp_close_ssk+0x26b/0x2c0 net/mptcp/protocol.c:2550 mptcp_pm_nl_rm_addr_or_subflow+0x635/0xd10 net/mptcp/pm_netlink.c:889 mptcp_pm_nl_rm_subflow_received net/mptcp/pm_netlink.c:924 [inline] mptcp_pm_flush_addrs_and_subflows net/mptcp/pm_netlink.c:1688 [inline] mptcp_nl_flush_addrs_list net/mptcp/pm_netlink.c:1709 [inline] mptcp_pm_nl_flush_addrs_doit+0xe10/0x1630 net/mptcp/pm_netlink.c:1750 genl_family_rcv_msg_doit net/netlink/genetlink.c:1115 [inline] genl_family_rcv_msg net/netlink/genetlink.c:1195 [inline] genl_rcv_msg+0x1214/0x12c0 net/netlink/genetlink.c:1210 netlink_rcv_skb+0x375/0x650 net/netlink/af_netlink.c:2542 genl_rcv+0x40/0x60 net/netlink/genetlink.c:1219 netlink_unicast_kernel net/netlink/af_netlink.c:1321 [inline] netlink_unicast+0xf52/0x1260 net/netlink/af_netlink.c:1347 netlink_sendmsg+0x10da/0x11e0 net/netlink/af_netlink.c:1891 sock_sendmsg_nosec net/socket.c:711 [inline] __sock_sendmsg+0x30f/0x380 net/socket.c:726 ____sys_sendmsg+0x877/0xb60 net/socket.c:2583 ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2637 __sys_sendmsg net/socket.c:2669 [inline] __do_sys_sendmsg net/socket.c:2674 [inline] __se_sys_sendmsg net/socket.c:2672 [inline] __x64_sys_sendmsg+0x212/0x3c0 net/socket.c:2672 x64_sys_call+0x2ed6/0x3c30 arch/x86/include/generated/asm/syscalls_64.h:47 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f Uninit was stored to memory at: mptcp_pm_add_addr_received+0x95f/0xdd0 net/mptcp/pm.c:235 mptcp_incoming_options+0x2983/0x3d30 net/mptcp/options.c:1169 tcp_data_queue+0xb4/0x7be0 net/ipv4/tcp_input.c:5233 tcp_rcv_state_process+0x2a38/0x49d0 net/ipv4/tcp_input.c:6972 tcp_v4_do_rcv+0xbf9/0x11a0 net/ipv4/tcp_ipv4.c:1939 tcp_v4_rcv+0x51df/0x5750 net/ipv4/tcp_ipv4.c:2351 ip_protocol_deliver_rcu+0x2a3/0x13d0 net/ipv4/ip_input.c:205 ip_local_deliver_finish+0x336/0x500 net/ipv4/ip_input.c:233 NF_HOOK include/linux/netfilter.h:314 [inline] ip_local_deliver+0x21f/0x490 net/ipv4/ip_input.c:254 dst_input include/net/dst.h:460 [inline] ip_rcv_finish+0x4a2/0x520 net/ipv4/ip_input.c:447 NF_HOOK include/linux/netfilter.h:314 [inline] ip_rcv+0xcd/0x380 net/ipv4/ip_input.c:567 __netif_receive_skb_one_core net/core/dev.c:5704 [inline] __netif_receive_skb+0x319/0xa00 net/core/dev.c:5817 process_backlog+0x4ad/0xa50 net/core/dev.c:6149 __napi_poll+0xe7/0x980 net/core/dev.c:6902 napi_poll net/core/dev.c:6971 [inline] net_rx_action+0xa5a/0x19b0 net/core/dev.c:7093 handle_softirqs+0x1a0/0x7c0 kernel/softirq.c:561 __do_softirq+0x14/0x1a kernel/softirq.c:595 Local variable mp_opt created at: mptcp_incoming_options+0x119/0x3d30 net/mptcp/options.c:1127 tcp_data_queue+0xb4/0x7be0 net/ipv4/tcp_input.c:5233 The current schema is too fragile; address the issue grouping all the state-related data together and clearing the whole group instead of just the bitmask. This also cleans-up the code a bit, as there is no need to individually clear "random" bitfield in a couple of places any more. Fixes: 84dfe3677a6f ("mptcp: send out dedicated ADD_ADDR packet") Cc: [email protected] Reported-by: [email protected] Closes: https://lore.kernel.org/[email protected] Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/541 Signed-off-by: Paolo Abeni <[email protected]> Reviewed-by: Matthieu Baerts (NGI0) <[email protected]> Signed-off-by: Matthieu Baerts (NGI0) <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Paolo Abeni <[email protected]> Date: Thu Jan 23 19:05:56 2025 +0100 mptcp: handle fastopen disconnect correctly commit 619af16b3b57a3a4ee50b9a30add9ff155541e71 upstream. Syzbot was able to trigger a data stream corruption: WARNING: CPU: 0 PID: 9846 at net/mptcp/protocol.c:1024 __mptcp_clean_una+0xddb/0xff0 net/mptcp/protocol.c:1024 Modules linked in: CPU: 0 UID: 0 PID: 9846 Comm: syz-executor351 Not tainted 6.13.0-rc2-syzkaller-00059-g00a5acdbf398 #0 Hardware name: Google Compute Engine/Google Compute Engine, BIOS Google 11/25/2024 RIP: 0010:__mptcp_clean_una+0xddb/0xff0 net/mptcp/protocol.c:1024 Code: fa ff ff 48 8b 4c 24 18 80 e1 07 fe c1 38 c1 0f 8c 8e fa ff ff 48 8b 7c 24 18 e8 e0 db 54 f6 e9 7f fa ff ff e8 e6 80 ee f5 90 <0f> 0b 90 4c 8b 6c 24 40 4d 89 f4 e9 04 f5 ff ff 44 89 f1 80 e1 07 RSP: 0018:ffffc9000c0cf400 EFLAGS: 00010293 RAX: ffffffff8bb0dd5a RBX: ffff888033f5d230 RCX: ffff888059ce8000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: ffffc9000c0cf518 R08: ffffffff8bb0d1dd R09: 1ffff110170c8928 R10: dffffc0000000000 R11: ffffed10170c8929 R12: 0000000000000000 R13: ffff888033f5d220 R14: dffffc0000000000 R15: ffff8880592b8000 FS: 00007f6e866496c0(0000) GS:ffff8880b8600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f6e86f491a0 CR3: 00000000310e6000 CR4: 00000000003526f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> __mptcp_clean_una_wakeup+0x7f/0x2d0 net/mptcp/protocol.c:1074 mptcp_release_cb+0x7cb/0xb30 net/mptcp/protocol.c:3493 release_sock+0x1aa/0x1f0 net/core/sock.c:3640 inet_wait_for_connect net/ipv4/af_inet.c:609 [inline] __inet_stream_connect+0x8bd/0xf30 net/ipv4/af_inet.c:703 mptcp_sendmsg_fastopen+0x2a2/0x530 net/mptcp/protocol.c:1755 mptcp_sendmsg+0x1884/0x1b10 net/mptcp/protocol.c:1830 sock_sendmsg_nosec net/socket.c:711 [inline] __sock_sendmsg+0x1a6/0x270 net/socket.c:726 ____sys_sendmsg+0x52a/0x7e0 net/socket.c:2583 ___sys_sendmsg net/socket.c:2637 [inline] __sys_sendmsg+0x269/0x350 net/socket.c:2669 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f6e86ebfe69 Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 b1 1f 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f6e86649168 EFLAGS: 00000246 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 00007f6e86f491b8 RCX: 00007f6e86ebfe69 RDX: 0000000030004001 RSI: 0000000020000080 RDI: 0000000000000003 RBP: 00007f6e86f491b0 R08: 00007f6e866496c0 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 00007f6e86f491bc R13: 000000000000006e R14: 00007ffe445d9420 R15: 00007ffe445d9508 </TASK> The root cause is the bad handling of disconnect() generated internally by the MPTCP protocol in case of connect FASTOPEN errors. Address the issue increasing the socket disconnect counter even on such a case, to allow other threads waiting on the same socket lock to properly error out. Fixes: c2b2ae3925b6 ("mptcp: handle correctly disconnect() failures") Cc: [email protected] Reported-by: [email protected] Closes: https://lore.kernel.org/[email protected] Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/537 Tested-by: [email protected] Signed-off-by: Paolo Abeni <[email protected]> Reviewed-by: Matthieu Baerts (NGI0) <[email protected]> Signed-off-by: Matthieu Baerts (NGI0) <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Matthieu Baerts (NGI0) <[email protected]> Date: Thu Jan 23 19:05:55 2025 +0100 mptcp: pm: only set fullmesh for subflow endp commit 1bb0d1348546ad059f55c93def34e67cb2a034a6 upstream. With the in-kernel path-manager, it is possible to change the 'fullmesh' flag. The code in mptcp_pm_nl_fullmesh() expects to change it only on 'subflow' endpoints, to recreate more or less subflows using the linked address. Unfortunately, the set_flags() hook was a bit more permissive, and allowed 'implicit' endpoints to get the 'fullmesh' flag while it is not allowed before. That's what syzbot found, triggering the following warning: WARNING: CPU: 0 PID: 6499 at net/mptcp/pm_netlink.c:1496 __mark_subflow_endp_available net/mptcp/pm_netlink.c:1496 [inline] WARNING: CPU: 0 PID: 6499 at net/mptcp/pm_netlink.c:1496 mptcp_pm_nl_fullmesh net/mptcp/pm_netlink.c:1980 [inline] WARNING: CPU: 0 PID: 6499 at net/mptcp/pm_netlink.c:1496 mptcp_nl_set_flags net/mptcp/pm_netlink.c:2003 [inline] WARNING: CPU: 0 PID: 6499 at net/mptcp/pm_netlink.c:1496 mptcp_pm_nl_set_flags+0x974/0xdc0 net/mptcp/pm_netlink.c:2064 Modules linked in: CPU: 0 UID: 0 PID: 6499 Comm: syz.1.413 Not tainted 6.13.0-rc5-syzkaller-00172-gd1bf27c4e176 #0 Hardware name: Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 RIP: 0010:__mark_subflow_endp_available net/mptcp/pm_netlink.c:1496 [inline] RIP: 0010:mptcp_pm_nl_fullmesh net/mptcp/pm_netlink.c:1980 [inline] RIP: 0010:mptcp_nl_set_flags net/mptcp/pm_netlink.c:2003 [inline] RIP: 0010:mptcp_pm_nl_set_flags+0x974/0xdc0 net/mptcp/pm_netlink.c:2064 Code: 01 00 00 49 89 c5 e8 fb 45 e8 f5 e9 b8 fc ff ff e8 f1 45 e8 f5 4c 89 f7 be 03 00 00 00 e8 44 1d 0b f9 eb a0 e8 dd 45 e8 f5 90 <0f> 0b 90 e9 17 ff ff ff 89 d9 80 e1 07 38 c1 0f 8c c9 fc ff ff 48 RSP: 0018:ffffc9000d307240 EFLAGS: 00010293 RAX: ffffffff8bb72e03 RBX: 0000000000000000 RCX: ffff88807da88000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: ffffc9000d307430 R08: ffffffff8bb72cf0 R09: 1ffff1100b842a5e R10: dffffc0000000000 R11: ffffed100b842a5f R12: ffff88801e2e5ac0 R13: ffff88805c214800 R14: ffff88805c2152e8 R15: 1ffff1100b842a5d FS: 00005555619f6500(0000) GS:ffff8880b8600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020002840 CR3: 00000000247e6000 CR4: 00000000003526f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> genl_family_rcv_msg_doit net/netlink/genetlink.c:1115 [inline] genl_family_rcv_msg net/netlink/genetlink.c:1195 [inline] genl_rcv_msg+0xb14/0xec0 net/netlink/genetlink.c:1210 netlink_rcv_skb+0x1e3/0x430 net/netlink/af_netlink.c:2542 genl_rcv+0x28/0x40 net/netlink/genetlink.c:1219 netlink_unicast_kernel net/netlink/af_netlink.c:1321 [inline] netlink_unicast+0x7f6/0x990 net/netlink/af_netlink.c:1347 netlink_sendmsg+0x8e4/0xcb0 net/netlink/af_netlink.c:1891 sock_sendmsg_nosec net/socket.c:711 [inline] __sock_sendmsg+0x221/0x270 net/socket.c:726 ____sys_sendmsg+0x52a/0x7e0 net/socket.c:2583 ___sys_sendmsg net/socket.c:2637 [inline] __sys_sendmsg+0x269/0x350 net/socket.c:2669 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f5fe8785d29 Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007fff571f5558 EFLAGS: 00000246 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 00007f5fe8975fa0 RCX: 00007f5fe8785d29 RDX: 0000000000000000 RSI: 0000000020000480 RDI: 0000000000000007 RBP: 00007f5fe8801b08 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 00007f5fe8975fa0 R14: 00007f5fe8975fa0 R15: 00000000000011f4 </TASK> Here, syzbot managed to set the 'fullmesh' flag on an 'implicit' and used -- according to 'id_avail_bitmap' -- endpoint, causing the PM to try decrement the local_addr_used counter which is only incremented for the 'subflow' endpoint. Note that 'no type' endpoints -- not 'subflow', 'signal', 'implicit' -- are fine, because their ID will not be marked as used in the 'id_avail' bitmap, and setting 'fullmesh' can help forcing the creation of subflow when receiving an ADD_ADDR. Fixes: 73c762c1f07d ("mptcp: set fullmesh flag in pm_netlink") Cc: [email protected] Reported-by: [email protected] Closes: https://lore.kernel.org/[email protected] Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/540 Reviewed-by: Mat Martineau <[email protected]> Signed-off-by: Matthieu Baerts (NGI0) <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Joe Hattori <[email protected]> Date: Fri Dec 6 22:38:09 2024 +0900 mtd: hyperbus: hbmc-am654: fix an OF node reference leak [ Upstream commit bf5821909eb9c7f5d07d5c6e852ead2c373c94a0 ] In am654_hbmc_platform_driver, .remove() and the error path of .probe() do not decrement the refcount of an OF node obtained by of_get_next_child(). Fix this by adding of_node_put() calls. Fixes: aca31ce96814 ("mtd: hyperbus: hbmc-am654: Fix direct mapping setup flash access") Signed-off-by: Joe Hattori <[email protected]> Signed-off-by: Miquel Raynal <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: david regan <[email protected]> Date: Mon Nov 25 18:39:16 2024 -0800 mtd: rawnand: brcmnand: fix status read of brcmnand_waitfunc [ Upstream commit 03271ea36ea7a58d30a4bde182eb2a0d46220467 ] This change fixes an issue where an error return value may be mistakenly used as NAND status. Fixes: f504551b7f15 ("mtd: rawnand: Propagate error and simplify ternary operators for brcmstb_nand_wait_for_completion()") Signed-off-by: david regan <[email protected]> Reviewed-by: William Zhang <[email protected]> Signed-off-by: Miquel Raynal <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Yu Kuai <[email protected]> Date: Fri Jan 3 17:28:59 2025 +0800 nbd: don't allow reconnect after disconnect [ Upstream commit 844b8cdc681612ff24df62cdefddeab5772fadf1 ] Following process can cause nbd_config UAF: 1) grab nbd_config temporarily; 2) nbd_genl_disconnect() flush all recv_work() and release the initial reference: nbd_genl_disconnect nbd_disconnect_and_put nbd_disconnect flush_workqueue(nbd->recv_workq) if (test_and_clear_bit(NBD_RT_HAS_CONFIG_REF, ...)) nbd_config_put -> due to step 1), reference is still not zero 3) nbd_genl_reconfigure() queue recv_work() again; nbd_genl_reconfigure config = nbd_get_config_unlocked(nbd) if (!config) -> succeed if (!test_bit(NBD_RT_BOUND, ...)) -> succeed nbd_reconnect_socket queue_work(nbd->recv_workq, &args->work) 4) step 1) release the reference; 5) Finially, recv_work() will trigger UAF: recv_work nbd_config_put(nbd) -> nbd_config is freed atomic_dec(&config->recv_threads) -> UAF Fix the problem by clearing NBD_RT_BOUND in nbd_genl_disconnect(), so that nbd_genl_reconfigure() will fail. Fixes: b7aa3d39385d ("nbd: add a reconfigure netlink command") Reported-by: [email protected] Closes: https://lore.kernel.org/all/[email protected]/ Signed-off-by: Yu Kuai <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jens Axboe <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Yevgeny Kliteynik <[email protected]> Date: Thu Jan 2 20:14:10 2025 +0200 net/mlx5: HWS, fix definer's HWS_SET32 macro for negative offset [ Upstream commit be482f1d10da781db9445d2753c1e3f1fd82babf ] When bit offset for HWS_SET32 macro is negative, UBSAN complains about the shift-out-of-bounds: UBSAN: shift-out-of-bounds in drivers/net/ethernet/mellanox/mlx5/core/steering/hws/definer.c:177:2 shift exponent -8 is negative Fixes: 74a778b4a63f ("net/mlx5: HWS, added definers handling") Signed-off-by: Yevgeny Kliteynik <[email protected]> Reviewed-by: Erez Shitrit <[email protected]> Reviewed-by: Mark Bloch <[email protected]> Signed-off-by: Tariq Toukan <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Stanislav Fomichev <[email protected]> Date: Wed Jan 22 16:04:07 2025 -0800 net/mlx5e: add missing cpu_to_node to kvzalloc_node in mlx5e_open_xdpredirect_sq [ Upstream commit 979284535aaf12a287a2f43d9d5dfcbdc1dc4cac ] kvzalloc_node is not doing a runtime check on the node argument (__alloc_pages_node_noprof does have a VM_BUG_ON, but it expands to nothing on !CONFIG_DEBUG_VM builds), so doing any ethtool/netlink operation that calls mlx5e_open on a CPU that's larger that MAX_NUMNODES triggers OOB access and panic (see the trace below). Add missing cpu_to_node call to convert cpu id to node id. [ 165.427394] mlx5_core 0000:5c:00.0 beth1: Link up [ 166.479327] BUG: unable to handle page fault for address: 0000000800000010 [ 166.494592] #PF: supervisor read access in kernel mode [ 166.505995] #PF: error_code(0x0000) - not-present page ... [ 166.816958] Call Trace: [ 166.822380] <TASK> [ 166.827034] ? __die_body+0x64/0xb0 [ 166.834774] ? page_fault_oops+0x2cd/0x3f0 [ 166.843862] ? exc_page_fault+0x63/0x130 [ 166.852564] ? asm_exc_page_fault+0x22/0x30 [ 166.861843] ? __kvmalloc_node_noprof+0x43/0xd0 [ 166.871897] ? get_partial_node+0x1c/0x320 [ 166.880983] ? deactivate_slab+0x269/0x2b0 [ 166.890069] ___slab_alloc+0x521/0xa90 [ 166.898389] ? __kvmalloc_node_noprof+0x43/0xd0 [ 166.908442] __kmalloc_node_noprof+0x216/0x3f0 [ 166.918302] ? __kvmalloc_node_noprof+0x43/0xd0 [ 166.928354] __kvmalloc_node_noprof+0x43/0xd0 [ 166.938021] mlx5e_open_channels+0x5e2/0xc00 [ 166.947496] mlx5e_open_locked+0x3e/0xf0 [ 166.956201] mlx5e_open+0x23/0x50 [ 166.963551] __dev_open+0x114/0x1c0 [ 166.971292] __dev_change_flags+0xa2/0x1b0 [ 166.980378] dev_change_flags+0x21/0x60 [ 166.988887] do_setlink+0x38d/0xf20 [ 166.996628] ? ep_poll_callback+0x1b9/0x240 [ 167.005910] ? __nla_validate_parse.llvm.10713395753544950386+0x80/0xd70 [ 167.020782] ? __wake_up_sync_key+0x52/0x80 [ 167.030066] ? __mutex_lock+0xff/0x550 [ 167.038382] ? security_capable+0x50/0x90 [ 167.047279] rtnl_setlink+0x1c9/0x210 [ 167.055403] ? ep_poll_callback+0x1b9/0x240 [ 167.064684] ? security_capable+0x50/0x90 [ 167.073579] rtnetlink_rcv_msg+0x2f9/0x310 [ 167.082667] ? rtnetlink_bind+0x30/0x30 [ 167.091173] netlink_rcv_skb+0xb1/0xe0 [ 167.099492] netlink_unicast+0x20f/0x2e0 [ 167.108191] netlink_sendmsg+0x389/0x420 [ 167.116896] __sys_sendto+0x158/0x1c0 [ 167.125024] __x64_sys_sendto+0x22/0x30 [ 167.133534] do_syscall_64+0x63/0x130 [ 167.141657] ? __irq_exit_rcu.llvm.17843942359718260576+0x52/0xd0 [ 167.155181] entry_SYSCALL_64_after_hwframe+0x4b/0x53 Fixes: bb135e40129d ("net/mlx5e: move XDP_REDIRECT sq to dynamic allocation") Signed-off-by: Stanislav Fomichev <[email protected]> Reviewed-by: Joe Damato <[email protected]> Reviewed-by: Tariq Toukan <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Maher Sanalla <[email protected]> Date: Thu Jan 16 14:33:16 2025 +0200 net/mlxfw: Drop hard coded max FW flash image size [ Upstream commit 70d81f25cc92cc4e914516c9935ae752f27d78ad ] Currently, mlxfw kernel module limits FW flash image size to be 10MB at most, preventing the ability to burn recent BlueField-3 FW that exceeds the said size limit. Thus, drop the hard coded limit. Instead, rely on FW's max_component_size threshold that is reported in MCQI register as the size limit for FW image. Fixes: 410ed13cae39 ("Add the mlxfw module for Mellanox firmware flash process") Signed-off-by: Maher Sanalla <[email protected]> Signed-off-by: Moshe Shemesh <[email protected]> Reviewed-by: Ido Schimmel <[email protected]> Tested-by: Ido Schimmel <[email protected]> Reviewed-by: Michal Swiatkowski <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Paul Fertser <[email protected]> Date: Mon Jan 20 16:35:36 2025 +0300 net/ncsi: use dev_set_mac_address() for Get MC MAC Address handling [ Upstream commit 05d91cdb1f9108426b14975ef4eeddf15875ca05 ] Copy of the rationale from 790071347a0a1a89e618eedcd51c687ea783aeb3: Change ndo_set_mac_address to dev_set_mac_address because dev_set_mac_address provides a way to notify network layer about MAC change. In other case, services may not aware about MAC change and keep using old one which set from network adapter driver. As example, DHCP client from systemd do not update MAC address without notification from net subsystem which leads to the problem with acquiring the right address from DHCP server. Since dev_set_mac_address requires RTNL lock the operation can not be performed directly in the response handler, see 9e2bbab94b88295dcc57c7580393c9ee08d7314d. The way of selecting the first suitable MAC address from the list is changed, instead of having the driver check it this patch just assumes any valid MAC should be good. Fixes: b8291cf3d118 ("net/ncsi: Add NC-SI 1.2 Get MC MAC Address command") Signed-off-by: Paul Fertser <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Nikita Zhandarovich <[email protected]> Date: Wed Jan 15 08:42:20 2025 -0800 net/rose: prevent integer overflows in rose_setsockopt() [ Upstream commit d640627663bfe7d8963c7615316d7d4ef60f3b0b ] In case of possible unpredictably large arguments passed to rose_setsockopt() and multiplied by extra values on top of that, integer overflows may occur. Do the safest minimum and fix these issues by checking the contents of 'opt' and returning -EINVAL if they are too large. Also, switch to unsigned int and remove useless check for negative 'opt' in ROSE_IDLE case. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Nikita Zhandarovich <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Guangguan Wang <[email protected]> Date: Sat Jan 4 22:32:01 2025 +0800 net/smc: fix data error when recvmsg with MSG_PEEK flag [ Upstream commit a4b6539038c1aa1ae871aacf6e41b566c3613993 ] When recvmsg with MSG_PEEK flag, the data will be copied to user's buffer without advancing consume cursor and without reducing the length of rx available data. Once the expected peek length is larger than the value of bytes_to_rcv, in the loop of do while in smc_rx_recvmsg, the first loop will copy bytes_to_rcv bytes of data from the position local_tx_ctrl.cons, the second loop will copy the min(bytes_to_rcv, read_remaining) bytes from the position local_tx_ctrl.cons again because of the lacking of process with advancing consume cursor and reducing the length of available data. So do the subsequent loops. The data copied in the second loop and the subsequent loops will result in data error, as it should not be copied if no more data arrives and it should be copied from the position advancing bytes_to_rcv bytes from the local_tx_ctrl.cons if more data arrives. This issue can be reproduce by the following python script: server.py: import socket import time server_ip = '0.0.0.0' server_port = 12346 server_socket = socket.socket(socket.AF_INET, socket.SOCK_STREAM) server_socket.bind((server_ip, server_port)) server_socket.listen(1) print('Server is running and listening for connections...') conn, addr = server_socket.accept() print('Connected by', addr) while True: data = conn.recv(1024) if not data: break print('Received request:', data.decode()) conn.sendall(b'Hello, client!\n') time.sleep(5) conn.sendall(b'Hello, again!\n') conn.close() client.py: import socket server_ip = '<server ip>' server_port = 12346 resp=b'Hello, client!\nHello, again!\n' client_socket = socket.socket(socket.AF_INET, socket.SOCK_STREAM) client_socket.connect((server_ip, server_port)) request = 'Hello, server!' client_socket.sendall(request.encode()) peek_data = client_socket.recv(len(resp), socket.MSG_PEEK | socket.MSG_WAITALL) print('Peeked data:', peek_data.decode()) client_socket.close() Fixes: 952310ccf2d8 ("smc: receive data from RMBE") Reported-by: D. Wythe <[email protected]> Signed-off-by: Guangguan Wang <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Lorenzo Bianconi <[email protected]> Date: Mon Dec 16 18:47:33 2024 +0100 net: airoha: Fix error path in airoha_probe() [ Upstream commit 0c7469ee718e1dd929f52bfb142a7f6fb68f0765 ] Do not run napi_disable() if airoha_hw_init() fails since Tx/Rx napi has not been started yet. In order to fix the issue, introduce airoha_qdma_stop_napi routine and remove napi_disable in airoha_hw_cleanup(). Fixes: 23020f049327 ("net: airoha: Introduce ethernet support for EN7581 SoC") Reviewed-by: Michal Swiatkowski <[email protected]> Signed-off-by: Lorenzo Bianconi <[email protected]> Link: https://patch.msgid.link/20241216-airoha_probe-error-path-fix-v2-1-6b10e04e9a5c@kernel.org Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Christian Marangi <[email protected]> Date: Mon Jan 20 16:41:40 2025 +0100 net: airoha: Fix wrong GDM4 register definition [ Upstream commit d31a49d37cb132b31cc6683eef2122f8609d6229 ] Fix wrong GDM4 register definition, in Airoha SDK GDM4 is defined at offset 0x2400 but this doesn't make sense as it does conflict with the CDM4 that is in the same location. Following the pattern where each GDM base is at the FWD_CFG, currently GDM4 base offset is set to 0x2500. This is correct but REG_GDM4_FWD_CFG and REG_GDM4_SRC_PORT_SET are still using the SDK reference with the 0x2400 offset. Fix these 2 define by subtracting 0x100 to each register to reflect the real address location. Fixes: 23020f049327 ("net: airoha: Introduce ethernet support for EN7581 SoC") Signed-off-by: Christian Marangi <[email protected]> Acked-by: Lorenzo Bianconi <[email protected]> Reviewed-by: Jacob Keller <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Antoine Tenart <[email protected]> Date: Thu Jan 16 10:21:57 2025 +0100 net: avoid race between device unregistration and ethnl ops [ Upstream commit 12e070eb6964b341b41677fd260af5a305316a1f ] The following trace can be seen if a device is being unregistered while its number of channels are being modified. DEBUG_LOCKS_WARN_ON(lock->magic != lock) WARNING: CPU: 3 PID: 3754 at kernel/locking/mutex.c:564 __mutex_lock+0xc8a/0x1120 CPU: 3 UID: 0 PID: 3754 Comm: ethtool Not tainted 6.13.0-rc6+ #771 RIP: 0010:__mutex_lock+0xc8a/0x1120 Call Trace: <TASK> ethtool_check_max_channel+0x1ea/0x880 ethnl_set_channels+0x3c3/0xb10 ethnl_default_set_doit+0x306/0x650 genl_family_rcv_msg_doit+0x1e3/0x2c0 genl_rcv_msg+0x432/0x6f0 netlink_rcv_skb+0x13d/0x3b0 genl_rcv+0x28/0x40 netlink_unicast+0x42e/0x720 netlink_sendmsg+0x765/0xc20 __sys_sendto+0x3ac/0x420 __x64_sys_sendto+0xe0/0x1c0 do_syscall_64+0x95/0x180 entry_SYSCALL_64_after_hwframe+0x76/0x7e This is because unregister_netdevice_many_notify might run before the rtnl lock section of ethnl operations, eg. set_channels in the above example. In this example the rss lock would be destroyed by the device unregistration path before being used again, but in general running ethnl operations while dismantle has started is not a good idea. Fix this by denying any operation on devices being unregistered. A check was already there in ethnl_ops_begin, but not wide enough. Note that the same issue cannot be seen on the ioctl version (__dev_ethtool) because the device reference is retrieved from within the rtnl lock section there. Once dismantle started, the net device is unlisted and no reference will be found. Fixes: dde91ccfa25f ("ethtool: do not perform operations on net devices being unregistered") Signed-off-by: Antoine Tenart <[email protected]> Reviewed-by: Przemek Kitszel <[email protected]> Reviewed-by: Edward Cree <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Chenyuan Yang <[email protected]> Date: Thu Jan 23 15:42:13 2025 -0600 net: davicom: fix UAF in dm9000_drv_remove [ Upstream commit 19e65c45a1507a1a2926649d2db3583ed9d55fd9 ] dm is netdev private data and it cannot be used after free_netdev() call. Using dm after free_netdev() can cause UAF bug. Fix it by moving free_netdev() at the end of the function. This is similar to the issue fixed in commit ad297cd2db89 ("net: qcom/emac: fix UAF in emac_remove"). This bug is detected by our static analysis tool. Fixes: cf9e60aa69ae ("net: davicom: Fix regulator not turned off on driver removal") Signed-off-by: Chenyuan Yang <[email protected]> CC: Uwe Kleine-König <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Roger Quadros <[email protected]> Date: Thu Jan 16 15:54:49 2025 +0200 net: ethernet: ti: am65-cpsw: fix freeing IRQ in am65_cpsw_nuss_remove_tx_chns() [ Upstream commit 4395a44acb15850e492dd1de9ec4b6479d96bc80 ] When getting the IRQ we use k3_udma_glue_tx_get_irq() which returns negative error value on error. So not NULL check is not sufficient to deteremine if IRQ is valid. Check that IRQ is greater then zero to ensure it is valid. There is no issue at probe time but at runtime user can invoke .set_channels which results in the following call chain. am65_cpsw_set_channels() am65_cpsw_nuss_update_tx_rx_chns() am65_cpsw_nuss_remove_tx_chns() am65_cpsw_nuss_init_tx_chns() At this point if am65_cpsw_nuss_init_tx_chns() fails due to k3_udma_glue_tx_get_irq() then tx_chn->irq will be set to a negative value. Then, at subsequent .set_channels with higher channel count we will attempt to free an invalid IRQ in am65_cpsw_nuss_remove_tx_chns() leading to a kernel warning. The issue is present in the original commit that introduced this driver, although there, am65_cpsw_nuss_update_tx_rx_chns() existed as am65_cpsw_nuss_update_tx_chns(). Fixes: 93a76530316a ("net: ethernet: ti: introduce am65x/j721e gigabit eth subsystem driver") Signed-off-by: Roger Quadros <[email protected]> Reviewed-by: Simon Horman <[email protected]> Reviewed-by: Siddharth Vadapalli <[email protected]> Reviewed-by: Jacob Keller <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Dheeraj Reddy Jonnalagadda <[email protected]> Date: Mon Jan 20 14:24:30 2025 +0530 net: fec: implement TSO descriptor cleanup [ Upstream commit 61dc1fd9205bc9d9918aa933a847b08e80b4dc20 ] Implement cleanup of descriptors in the TSO error path of fec_enet_txq_submit_tso(). The cleanup - Unmaps DMA buffers for data descriptors skipping TSO header - Clears all buffer descriptors - Handles extended descriptors by clearing cbd_esc when enabled Fixes: 79f339125ea3 ("net: fec: Add software TSO support") Signed-off-by: Dheeraj Reddy Jonnalagadda <[email protected]> Reviewed-by: Wei Fang <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Paolo Abeni <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Jian Shen <[email protected]> Date: Sat Jan 18 17:47:41 2025 +0800 net: hns3: fix oops when unload drivers paralleling [ Upstream commit 92e5995773774a3e70257e9c95ea03518268bea5 ] When unload hclge driver, it tries to disable sriov first for each ae_dev node from hnae3_ae_dev_list. If user unloads hns3 driver at the time, because it removes all the ae_dev nodes, and it may cause oops. But we can't simply use hnae3_common_lock for this. Because in the process flow of pci_disable_sriov(), it will trigger the remove flow of VF, which will also take hnae3_common_lock. To fixes it, introduce a new mutex to protect the unload process. Fixes: 0dd8a25f355b ("net: hns3: disable sriov before unload hclge layer") Signed-off-by: Jian Shen <[email protected]> Signed-off-by: Jijie Shao <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Eric Dumazet <[email protected]> Date: Wed Jan 29 13:00:07 2025 +0000 net: hsr: fix fill_frame_info() regression vs VLAN packets [ Upstream commit 0f5697f1a3f99bc2b674b8aa3c5da822c5673c11 ] Stephan Wurm reported that my recent patch broke VLAN support. Apparently skb->mac_len is not correct for VLAN traffic as shown by debug traces [1]. Use instead pskb_may_pull() to make sure the expected header is present in skb->head. Many thanks to Stephan for his help. [1] kernel: skb len=170 headroom=2 headlen=170 tailroom=20 mac=(2,14) mac_len=14 net=(16,-1) trans=-1 shinfo(txflags=0 nr_frags=0 gso(size=0 type=0 segs=0)) csum(0x0 start=0 offset=0 ip_summed=0 complete_sw=0 valid=0 level=0) hash(0x0 sw=0 l4=0) proto=0x0000 pkttype=0 iif=0 priority=0x0 mark=0x0 alloc_cpu=0 vlan_all=0x0 encapsulation=0 inner(proto=0x0000, mac=0, net=0, trans=0) kernel: dev name=prp0 feat=0x0000000000007000 kernel: sk family=17 type=3 proto=0 kernel: skb headroom: 00000000: 74 00 kernel: skb linear: 00000000: 01 0c cd 01 00 01 00 d0 93 53 9c cb 81 00 80 00 kernel: skb linear: 00000010: 88 b8 00 01 00 98 00 00 00 00 61 81 8d 80 16 52 kernel: skb linear: 00000020: 45 47 44 4e 43 54 52 4c 2f 4c 4c 4e 30 24 47 4f kernel: skb linear: 00000030: 24 47 6f 43 62 81 01 14 82 16 52 45 47 44 4e 43 kernel: skb linear: 00000040: 54 52 4c 2f 4c 4c 4e 30 24 44 73 47 6f 6f 73 65 kernel: skb linear: 00000050: 83 07 47 6f 49 64 65 6e 74 84 08 67 8d f5 93 7e kernel: skb linear: 00000060: 76 c8 00 85 01 01 86 01 00 87 01 00 88 01 01 89 kernel: skb linear: 00000070: 01 00 8a 01 02 ab 33 a2 15 83 01 00 84 03 03 00 kernel: skb linear: 00000080: 00 91 08 67 8d f5 92 77 4b c6 1f 83 01 00 a2 1a kernel: skb linear: 00000090: a2 06 85 01 00 83 01 00 84 03 03 00 00 91 08 67 kernel: skb linear: 000000a0: 8d f5 92 77 4b c6 1f 83 01 00 kernel: skb tailroom: 00000000: 80 18 02 00 fe 4e 00 00 01 01 08 0a 4f fd 5e d1 kernel: skb tailroom: 00000010: 4f fd 5e cd Fixes: b9653d19e556 ("net: hsr: avoid potential out-of-bound access in fill_frame_info()") Reported-by: Stephan Wurm <[email protected]> Tested-by: Stephan Wurm <[email protected]> Closes: https://lore.kernel.org/netdev/Z4o_UC0HweBHJ_cw@PC-LX-SteWu/ Signed-off-by: Eric Dumazet <[email protected]> Reviewed-by: Simon Horman <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Liu Jian <[email protected]> Date: Thu Jan 16 22:30:53 2025 +0800 net: let net.core.dev_weight always be non-zero [ Upstream commit d1f9f79fa2af8e3b45cffdeef66e05833480148a ] The following problem was encountered during stability test: (NULL net_device): NAPI poll function process_backlog+0x0/0x530 \ returned 1, exceeding its budget of 0. ------------[ cut here ]------------ list_add double add: new=ffff88905f746f48, prev=ffff88905f746f48, \ next=ffff88905f746e40. WARNING: CPU: 18 PID: 5462 at lib/list_debug.c:35 \ __list_add_valid_or_report+0xf3/0x130 CPU: 18 UID: 0 PID: 5462 Comm: ping Kdump: loaded Not tainted 6.13.0-rc7+ RIP: 0010:__list_add_valid_or_report+0xf3/0x130 Call Trace: ? __warn+0xcd/0x250 ? __list_add_valid_or_report+0xf3/0x130 enqueue_to_backlog+0x923/0x1070 netif_rx_internal+0x92/0x2b0 __netif_rx+0x15/0x170 loopback_xmit+0x2ef/0x450 dev_hard_start_xmit+0x103/0x490 __dev_queue_xmit+0xeac/0x1950 ip_finish_output2+0x6cc/0x1620 ip_output+0x161/0x270 ip_push_pending_frames+0x155/0x1a0 raw_sendmsg+0xe13/0x1550 __sys_sendto+0x3bf/0x4e0 __x64_sys_sendto+0xdc/0x1b0 do_syscall_64+0x5b/0x170 entry_SYSCALL_64_after_hwframe+0x76/0x7e The reproduction command is as follows: sysctl -w net.core.dev_weight=0 ping 127.0.0.1 This is because when the napi's weight is set to 0, process_backlog() may return 0 and clear the NAPI_STATE_SCHED bit of napi->state, causing this napi to be re-polled in net_rx_action() until __do_softirq() times out. Since the NAPI_STATE_SCHED bit has been cleared, napi_schedule_rps() can be retriggered in enqueue_to_backlog(), causing this issue. Making the napi's weight always non-zero solves this problem. Triggering this issue requires system-wide admin (setting is not namespaced). Fixes: e38766054509 ("[NET]: Fix sysctl net.core.dev_weight") Fixes: 3d48b53fb2ae ("net: dev_weight: TX/RX orthogonality") Signed-off-by: Liu Jian <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Jakub Kicinski <[email protected]> Date: Wed Jan 22 14:45:03 2025 -0800 net: netdevsim: try to close UDP port harness races [ Upstream commit 50bf398e1ceacb9a7f85bd3bdca065ebe5cb6159 ] syzbot discovered that we remove the debugfs files after we free the netdev. Try to clean up the relevant dir while the device is still around. Reported-by: [email protected] Fixes: 424be63ad831 ("netdevsim: add UDP tunnel port offload support") Reviewed-by: Michal Swiatkowski <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Jakub Kicinski <[email protected]> Date: Thu Jan 23 15:16:20 2025 -0800 net: page_pool: don't try to stash the napi id [ Upstream commit 67e4bb2ced0f2d8fbd414f932daea94ba63ae4c4 ] Page ppol tried to cache the NAPI ID in page pool info to avoid having a dependency on the life cycle of the NAPI instance. Since commit under Fixes the NAPI ID is not populated until napi_enable() and there's a good chance that page pool is created before NAPI gets enabled. Protect the NAPI pointer with the existing page pool mutex, the reading path already holds it. napi_id itself we need to READ_ONCE(), it's protected by netdev_lock() which are not holding in page pool. Before this patch napi IDs were missing for mlx5: # ./cli.py --spec netlink/specs/netdev.yaml --dump page-pool-get [{'id': 144, 'ifindex': 2, 'inflight': 3072, 'inflight-mem': 12582912}, {'id': 143, 'ifindex': 2, 'inflight': 5568, 'inflight-mem': 22806528}, {'id': 142, 'ifindex': 2, 'inflight': 5120, 'inflight-mem': 20971520}, {'id': 141, 'ifindex': 2, 'inflight': 4992, 'inflight-mem': 20447232}, ... After: [{'id': 144, 'ifindex': 2, 'inflight': 3072, 'inflight-mem': 12582912, 'napi-id': 565}, {'id': 143, 'ifindex': 2, 'inflight': 4224, 'inflight-mem': 17301504, 'napi-id': 525}, {'id': 142, 'ifindex': 2, 'inflight': 4288, 'inflight-mem': 17563648, 'napi-id': 524}, ... Fixes: 86e25f40aa1e ("net: napi: Add napi_config") Reviewed-by: Mina Almasry <[email protected]> Reviewed-by: Toke Høiland-Jørgensen <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Dimitri Fedrau <[email protected]> Date: Sat Jan 18 19:43:43 2025 +0100 net: phy: marvell-88q2xxx: Fix temperature measurement with reset-gpios [ Upstream commit a197004cf3c2e6c8cc0695c787a97e62e3229754 ] When using temperature measurement on Marvell 88Q2XXX devices and the reset-gpios property is set in DT, the device does a hardware reset when interface is brought down and up again. That means that the content of the register MDIO_MMD_PCS_MV_TEMP_SENSOR2 is reset to default and that leads to permanent deactivation of the temperature measurement, because activation is done in mv88q2xxx_probe. To fix this move activation of temperature measurement to mv88q222x_config_init. Fixes: a557a92e6881 ("net: phy: marvell-88q2xxx: add support for temperature sensor") Reviewed-by: Niklas Söderlund <[email protected]> Signed-off-by: Dimitri Fedrau <[email protected]> Reviewed-by: Andrew Lunn <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Paolo Abeni <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Daniel Golle <[email protected]> Date: Wed Jan 15 14:45:00 2025 +0000 net: phy: realtek: always clear NBase-T lpa [ Upstream commit d3eb58549842c60ed46f37da7f4da969e3d6ecd3 ] Clear NBase-T link partner advertisement before calling rtlgen_read_status() to avoid phy_resolve_aneg_linkmode() wrongly setting speed and duplex. This fixes bogus 2.5G/5G/10G link partner advertisement and thus speed and duplex being set by phy_resolve_aneg_linkmode() due to stale NBase-T lpa. Fixes: 68d5cd09e891 ("net: phy: realtek: change order of calls in C22 read_status()") Signed-off-by: Daniel Golle <[email protected]> Reviewed-by: Michal Swiatkowski <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Daniel Golle <[email protected]> Date: Wed Jan 15 14:43:35 2025 +0000 net: phy: realtek: clear 1000Base-T lpa if link is down [ Upstream commit 34d5a86ff7bbe225fba3ad91f9b4dc85fb408e18 ] Only read 1000Base-T link partner advertisement if autonegotiation has completed and otherwise 1000Base-T link partner advertisement bits. This fixes bogus 1000Base-T link partner advertisement after link goes down (eg. by disconnecting the wire). Fixes: 5cb409b3960e ("net: phy: realtek: clear 1000Base-T link partner advertisement") Signed-off-by: Daniel Golle <[email protected]> Reviewed-by: Michal Swiatkowski <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Daniel Golle <[email protected]> Date: Wed Jan 15 14:43:43 2025 +0000 net: phy: realtek: clear master_slave_state if link is down [ Upstream commit ea8318cb33e593bbfc59d637eae45a69732c5387 ] rtlgen_decode_physr() which sets master_slave_state isn't called in case the link is down and other than rtlgen_read_status(), rtl822x_c45_read_status() doesn't implicitely clear master_slave_state. Avoid stale master_slave_state by always setting it to MASTER_SLAVE_STATE_UNKNOWN in rtl822x_c45_read_status() in case the link is down. Fixes: 081c9c0265c9 ("net: phy: realtek: read duplex and gbit master from PHYSR register") Signed-off-by: Daniel Golle <[email protected]> Reviewed-by: Michal Swiatkowski <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Kory Maincent <[email protected]> Date: Wed Jan 29 10:50:46 2025 +0100 net: ravb: Fix missing rtnl lock in suspend/resume path [ Upstream commit 2c2ebb2b49573e5f8726112ad06b1dffc3c9ea03 ] Fix the suspend/resume path by ensuring the rtnl lock is held where required. Calls to ravb_open, ravb_close and wol operations must be performed under the rtnl lock to prevent conflicts with ongoing ndo operations. Without this fix, the following warning is triggered: [ 39.032969] ============================= [ 39.032983] WARNING: suspicious RCU usage [ 39.033019] ----------------------------- [ 39.033033] drivers/net/phy/phy_device.c:2004 suspicious rcu_dereference_protected() usage! ... [ 39.033597] stack backtrace: [ 39.033613] CPU: 0 UID: 0 PID: 174 Comm: python3 Not tainted 6.13.0-rc7-next-20250116-arm64-renesas-00002-g35245dfdc62c #7 [ 39.033623] Hardware name: Renesas SMARC EVK version 2 based on r9a08g045s33 (DT) [ 39.033628] Call trace: [ 39.033633] show_stack+0x14/0x1c (C) [ 39.033652] dump_stack_lvl+0xb4/0xc4 [ 39.033664] dump_stack+0x14/0x1c [ 39.033671] lockdep_rcu_suspicious+0x16c/0x22c [ 39.033682] phy_detach+0x160/0x190 [ 39.033694] phy_disconnect+0x40/0x54 [ 39.033703] ravb_close+0x6c/0x1cc [ 39.033714] ravb_suspend+0x48/0x120 [ 39.033721] dpm_run_callback+0x4c/0x14c [ 39.033731] device_suspend+0x11c/0x4dc [ 39.033740] dpm_suspend+0xdc/0x214 [ 39.033748] dpm_suspend_start+0x48/0x60 [ 39.033758] suspend_devices_and_enter+0x124/0x574 [ 39.033769] pm_suspend+0x1ac/0x274 [ 39.033778] state_store+0x88/0x124 [ 39.033788] kobj_attr_store+0x14/0x24 [ 39.033798] sysfs_kf_write+0x48/0x6c [ 39.033808] kernfs_fop_write_iter+0x118/0x1a8 [ 39.033817] vfs_write+0x27c/0x378 [ 39.033825] ksys_write+0x64/0xf4 [ 39.033833] __arm64_sys_write+0x18/0x20 [ 39.033841] invoke_syscall+0x44/0x104 [ 39.033852] el0_svc_common.constprop.0+0xb4/0xd4 [ 39.033862] do_el0_svc+0x18/0x20 [ 39.033870] el0_svc+0x3c/0xf0 [ 39.033880] el0t_64_sync_handler+0xc0/0xc4 [ 39.033888] el0t_64_sync+0x154/0x158 [ 39.041274] ravb 11c30000.ethernet eth0: Link is Down Reported-by: Claudiu Beznea <[email protected]> Closes: https://lore.kernel.org/netdev/[email protected]/ Fixes: 0184165b2f42 ("ravb: add sleep PM suspend/resume support") Signed-off-by: Kory Maincent <[email protected]> Tested-by: Niklas Söderlund <[email protected]> Signed-off-by: Paolo Abeni <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Eric Dumazet <[email protected]> Date: Wed Jan 22 18:02:44 2025 +0000 net: rose: fix timer races against user threads [ Upstream commit 5de7665e0a0746b5ad7943554b34db8f8614a196 ] Rose timers only acquire the socket spinlock, without checking if the socket is owned by one user thread. Add a check and rearm the timers if needed. BUG: KASAN: slab-use-after-free in rose_timer_expiry+0x31d/0x360 net/rose/rose_timer.c:174 Read of size 2 at addr ffff88802f09b82a by task swapper/0/0 CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.13.0-rc5-syzkaller-00172-gd1bf27c4e176 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 Call Trace: <IRQ> __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0x169/0x550 mm/kasan/report.c:489 kasan_report+0x143/0x180 mm/kasan/report.c:602 rose_timer_expiry+0x31d/0x360 net/rose/rose_timer.c:174 call_timer_fn+0x187/0x650 kernel/time/timer.c:1793 expire_timers kernel/time/timer.c:1844 [inline] __run_timers kernel/time/timer.c:2418 [inline] __run_timer_base+0x66a/0x8e0 kernel/time/timer.c:2430 run_timer_base kernel/time/timer.c:2439 [inline] run_timer_softirq+0xb7/0x170 kernel/time/timer.c:2449 handle_softirqs+0x2d4/0x9b0 kernel/softirq.c:561 __do_softirq kernel/softirq.c:595 [inline] invoke_softirq kernel/softirq.c:435 [inline] __irq_exit_rcu+0xf7/0x220 kernel/softirq.c:662 irq_exit_rcu+0x9/0x30 kernel/softirq.c:678 instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1049 [inline] sysvec_apic_timer_interrupt+0xa6/0xc0 arch/x86/kernel/apic/apic.c:1049 </IRQ> Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Reported-by: syzbot <[email protected]> Signed-off-by: Eric Dumazet <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Jamal Hadi Salim <[email protected]> Date: Wed Jan 15 17:37:13 2025 -0800 net: sched: Disallow replacing of child qdisc from one parent to another [ Upstream commit bc50835e83f60f56e9bec2b392fb5544f250fb6f ] Lion Ackermann was able to create a UAF which can be abused for privilege escalation with the following script Step 1. create root qdisc tc qdisc add dev lo root handle 1:0 drr step2. a class for packet aggregation do demonstrate uaf tc class add dev lo classid 1:1 drr step3. a class for nesting tc class add dev lo classid 1:2 drr step4. a class to graft qdisc to tc class add dev lo classid 1:3 drr step5. tc qdisc add dev lo parent 1:1 handle 2:0 plug limit 1024 step6. tc qdisc add dev lo parent 1:2 handle 3:0 drr step7. tc class add dev lo classid 3:1 drr step 8. tc qdisc add dev lo parent 3:1 handle 4:0 pfifo step 9. Display the class/qdisc layout tc class ls dev lo class drr 1:1 root leaf 2: quantum 64Kb class drr 1:2 root leaf 3: quantum 64Kb class drr 3:1 root leaf 4: quantum 64Kb tc qdisc ls qdisc drr 1: dev lo root refcnt 2 qdisc plug 2: dev lo parent 1:1 qdisc pfifo 4: dev lo parent 3:1 limit 1000p qdisc drr 3: dev lo parent 1:2 step10. trigger the bug <=== prevented by this patch tc qdisc replace dev lo parent 1:3 handle 4:0 step 11. Redisplay again the qdiscs/classes tc class ls dev lo class drr 1:1 root leaf 2: quantum 64Kb class drr 1:2 root leaf 3: quantum 64Kb class drr 1:3 root leaf 4: quantum 64Kb class drr 3:1 root leaf 4: quantum 64Kb tc qdisc ls qdisc drr 1: dev lo root refcnt 2 qdisc plug 2: dev lo parent 1:1 qdisc pfifo 4: dev lo parent 3:1 refcnt 2 limit 1000p qdisc drr 3: dev lo parent 1:2 Observe that a) parent for 4:0 does not change despite the replace request. There can only be one parent. b) refcount has gone up by two for 4:0 and c) both class 1:3 and 3:1 are pointing to it. Step 12. send one packet to plug echo "" | socat -u STDIN UDP4-DATAGRAM:127.0.0.1:8888,priority=$((0x10001)) step13. send one packet to the grafted fifo echo "" | socat -u STDIN UDP4-DATAGRAM:127.0.0.1:8888,priority=$((0x10003)) step14. lets trigger the uaf tc class delete dev lo classid 1:3 tc class delete dev lo classid 1:1 The semantics of "replace" is for a del/add _on the same node_ and not a delete from one node(3:1) and add to another node (1:3) as in step10. While we could "fix" with a more complex approach there could be consequences to expectations so the patch takes the preventive approach of "disallow such config". Joint work with Lion Ackermann <[email protected]> Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Jamal Hadi Salim <[email protected]> Reviewed-by: Simon Horman <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Xin Long <[email protected]> Date: Wed Jan 15 09:27:54 2025 -0500 net: sched: refine software bypass handling in tc_run [ Upstream commit a12c76a03386e32413ae8eaaefa337e491880632 ] This patch addresses issues with filter counting in block (tcf_block), particularly for software bypass scenarios, by introducing a more accurate mechanism using useswcnt. Previously, filtercnt and skipswcnt were introduced by: Commit 2081fd3445fe ("net: sched: cls_api: add filter counter") and Commit f631ef39d819 ("net: sched: cls_api: add skip_sw counter") filtercnt tracked all tp (tcf_proto) objects added to a block, and skipswcnt counted tp objects with the skipsw attribute set. The problem is: a single tp can contain multiple filters, some with skipsw and others without. The current implementation fails in the case: When the first filter in a tp has skipsw, both skipswcnt and filtercnt are incremented, then adding a second filter without skipsw to the same tp does not modify these counters because tp->counted is already set. This results in bypass software behavior based solely on skipswcnt equaling filtercnt, even when the block includes filters without skipsw. Consequently, filters without skipsw are inadvertently bypassed. To address this, the patch introduces useswcnt in block to explicitly count tp objects containing at least one filter without skipsw. Key changes include: Whenever a filter without skipsw is added, its tp is marked with usesw and counted in useswcnt. tc_run() now uses useswcnt to determine software bypass, eliminating reliance on filtercnt and skipswcnt. This refined approach prevents software bypass for blocks containing mixed filters, ensuring correct behavior in tc_run(). Additionally, as atomic operations on useswcnt ensure thread safety and tp->lock guards access to tp->usesw and tp->counted, the broader lock down_write(&block->cb_lock) is no longer required in tc_new_tfilter(), and this resolves a performance regression caused by the filter counting mechanism during parallel filter insertions. The improvement can be demonstrated using the following script: # cat insert_tc_rules.sh tc qdisc add dev ens1f0np0 ingress for i in $(seq 16); do taskset -c $i tc -b rules_$i.txt & done wait Each of rules_$i.txt files above includes 100000 tc filter rules to a mlx5 driver NIC ens1f0np0. Without this patch: # time sh insert_tc_rules.sh real 0m50.780s user 0m23.556s sys 4m13.032s With this patch: # time sh insert_tc_rules.sh real 0m17.718s user 0m7.807s sys 3m45.050s Fixes: 047f340b36fc ("net: sched: make skip_sw actually skip software") Reported-by: Shuang Li <[email protected]> Signed-off-by: Xin Long <[email protected]> Acked-by: Marcelo Ricardo Leitner <[email protected]> Reviewed-by: Asbjørn Sloth Tønnesen <[email protected]> Tested-by: Asbjørn Sloth Tønnesen <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Kory Maincent <[email protected]> Date: Wed Jan 29 10:50:47 2025 +0100 net: sh_eth: Fix missing rtnl lock in suspend/resume path [ Upstream commit b95102215a8d0987789715ce11c0d4ec031cbfbe ] Fix the suspend/resume path by ensuring the rtnl lock is held where required. Calls to sh_eth_close, sh_eth_open and wol operations must be performed under the rtnl lock to prevent conflicts with ongoing ndo operations. Fixes: b71af04676e9 ("sh_eth: add more PM methods") Tested-by: Niklas Söderlund <[email protected]> Reviewed-by: Sergey Shtylyov <[email protected]> Signed-off-by: Kory Maincent <[email protected]> Signed-off-by: Paolo Abeni <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Kunihiko Hayashi <[email protected]> Date: Mon Jan 27 10:38:19 2025 +0900 net: stmmac: Limit FIFO size by hardware capability [ Upstream commit 044f2fbaa2725696ecbf1f02ba7ab0a8ccb7e1ae ] Tx/Rx FIFO size is specified by the parameter "{tx,rx}-fifo-depth" from stmmac_platform layer. However, these values are constrained by upper limits determined by the capabilities of each hardware feature. There is a risk that the upper bits will be truncated due to the calculation, so it's appropriate to limit them to the upper limit values and display a warning message. This only works if the hardware capability has the upper limit values. Fixes: e7877f52fd4a ("stmmac: Read tx-fifo-depth and rx-fifo-depth from the devicetree") Signed-off-by: Kunihiko Hayashi <[email protected]> Reviewed-by: Yanteng Si <[email protected]> Signed-off-by: Paolo Abeni <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Kunihiko Hayashi <[email protected]> Date: Mon Jan 27 10:38:18 2025 +0900 net: stmmac: Limit the number of MTL queues to hardware capability [ Upstream commit f5fb35a3d6b36d378b2e2ecbfb9caa337d5428e6 ] The number of MTL queues to use is specified by the parameter "snps,{tx,rx}-queues-to-use" from stmmac_platform layer. However, the maximum numbers of queues are constrained by upper limits determined by the capability of each hardware feature. It's appropriate to limit the values not to exceed the upper limit values and display a warning message. This only works if the hardware capability has the upper limit values. Fixes: d976a525c371 ("net: stmmac: multiple queues dt configuration") Signed-off-by: Kunihiko Hayashi <[email protected]> Reviewed-by: Yanteng Si <[email protected]> Signed-off-by: Paolo Abeni <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Nikita Zhandarovich <[email protected]> Date: Fri Jan 24 01:30:20 2025 -0800 net: usb: rtl8150: enable basic endpoint checking commit 90b7f2961798793275b4844348619b622f983907 upstream. Syzkaller reports [1] encountering a common issue of utilizing a wrong usb endpoint type during URB submitting stage. This, in turn, triggers a warning shown below. For now, enable simple endpoint checking (specifically, bulk and interrupt eps, testing control one is not essential) to mitigate the issue with a view to do other related cosmetic changes later, if they are necessary. [1] Syzkaller report: usb 1-1: BOGUS urb xfer, pipe 3 != type 1 WARNING: CPU: 1 PID: 2586 at drivers/usb/core/urb.c:503 usb_submit_urb+0xe4b/0x1730 driv> Modules linked in: CPU: 1 UID: 0 PID: 2586 Comm: dhcpcd Not tainted 6.11.0-rc4-syzkaller-00069-gfc88bb11617> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 RIP: 0010:usb_submit_urb+0xe4b/0x1730 drivers/usb/core/urb.c:503 Code: 84 3c 02 00 00 e8 05 e4 fc fc 4c 89 ef e8 fd 25 d7 fe 45 89 e0 89 e9 4c 89 f2 48 8> RSP: 0018:ffffc9000441f740 EFLAGS: 00010282 RAX: 0000000000000000 RBX: ffff888112487a00 RCX: ffffffff811a99a9 RDX: ffff88810df6ba80 RSI: ffffffff811a99b6 RDI: 0000000000000001 RBP: 0000000000000003 R08: 0000000000000001 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000001 R12: 0000000000000001 R13: ffff8881023bf0a8 R14: ffff888112452a20 R15: ffff888112487a7c FS: 00007fc04eea5740(0000) GS:ffff8881f6300000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f0a1de9f870 CR3: 000000010dbd0000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> rtl8150_open+0x300/0xe30 drivers/net/usb/rtl8150.c:733 __dev_open+0x2d4/0x4e0 net/core/dev.c:1474 __dev_change_flags+0x561/0x720 net/core/dev.c:8838 dev_change_flags+0x8f/0x160 net/core/dev.c:8910 devinet_ioctl+0x127a/0x1f10 net/ipv4/devinet.c:1177 inet_ioctl+0x3aa/0x3f0 net/ipv4/af_inet.c:1003 sock_do_ioctl+0x116/0x280 net/socket.c:1222 sock_ioctl+0x22e/0x6c0 net/socket.c:1341 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:907 [inline] __se_sys_ioctl fs/ioctl.c:893 [inline] __x64_sys_ioctl+0x193/0x220 fs/ioctl.c:893 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcd/0x250 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7fc04ef73d49 ... This change has not been tested on real hardware. Reported-and-tested-by: [email protected] Closes: https://syzkaller.appspot.com/bug?extid=d7e968426f644b567e31 Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: [email protected] Signed-off-by: Nikita Zhandarovich <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Paolo Abeni <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Toke Høiland-Jørgensen <[email protected]> Date: Mon Jan 27 14:13:42 2025 +0100 net: xdp: Disallow attaching device-bound programs in generic mode [ Upstream commit 3595599fa8360bb3c7afa7ee50c810b4a64106ea ] Device-bound programs are used to support RX metadata kfuncs. These kfuncs are driver-specific and rely on the driver context to read the metadata. This means they can't work in generic XDP mode. However, there is no check to disallow such programs from being attached in generic mode, in which case the metadata kfuncs will be called in an invalid context, leading to crashes. Fix this by adding a check to disallow attaching device-bound programs in generic mode. Fixes: 2b3486bc2d23 ("bpf: Introduce device-bound XDP programs") Reported-by: Marcus Wichelmann <[email protected]> Closes: https://lore.kernel.org/r/[email protected] Tested-by: Marcus Wichelmann <[email protected]> Acked-by: Stanislav Fomichev <[email protected]> Signed-off-by: Toke Høiland-Jørgensen <[email protected]> Acked-by: Daniel Borkmann <[email protected]> Acked-by: Martin KaFai Lau <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Octavian Purdila <[email protected]> Date: Tue Dec 3 19:05:19 2024 -0800 net_sched: sch_sfq: don't allow 1 packet limit [ Upstream commit 10685681bafce6febb39770f3387621bf5d67d0b ] The current implementation does not work correctly with a limit of 1. iproute2 actually checks for this and this patch adds the check in kernel as well. This fixes the following syzkaller reported crash: UBSAN: array-index-out-of-bounds in net/sched/sch_sfq.c:210:6 index 65535 is out of range for type 'struct sfq_head[128]' CPU: 0 PID: 2569 Comm: syz-executor101 Not tainted 5.10.0-smp-DEV #1 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 Call Trace: __dump_stack lib/dump_stack.c:79 [inline] dump_stack+0x125/0x19f lib/dump_stack.c:120 ubsan_epilogue lib/ubsan.c:148 [inline] __ubsan_handle_out_of_bounds+0xed/0x120 lib/ubsan.c:347 sfq_link net/sched/sch_sfq.c:210 [inline] sfq_dec+0x528/0x600 net/sched/sch_sfq.c:238 sfq_dequeue+0x39b/0x9d0 net/sched/sch_sfq.c:500 sfq_reset+0x13/0x50 net/sched/sch_sfq.c:525 qdisc_reset+0xfe/0x510 net/sched/sch_generic.c:1026 tbf_reset+0x3d/0x100 net/sched/sch_tbf.c:319 qdisc_reset+0xfe/0x510 net/sched/sch_generic.c:1026 dev_reset_queue+0x8c/0x140 net/sched/sch_generic.c:1296 netdev_for_each_tx_queue include/linux/netdevice.h:2350 [inline] dev_deactivate_many+0x6dc/0xc20 net/sched/sch_generic.c:1362 __dev_close_many+0x214/0x350 net/core/dev.c:1468 dev_close_many+0x207/0x510 net/core/dev.c:1506 unregister_netdevice_many+0x40f/0x16b0 net/core/dev.c:10738 unregister_netdevice_queue+0x2be/0x310 net/core/dev.c:10695 unregister_netdevice include/linux/netdevice.h:2893 [inline] __tun_detach+0x6b6/0x1600 drivers/net/tun.c:689 tun_detach drivers/net/tun.c:705 [inline] tun_chr_close+0x104/0x1b0 drivers/net/tun.c:3640 __fput+0x203/0x840 fs/file_table.c:280 task_work_run+0x129/0x1b0 kernel/task_work.c:185 exit_task_work include/linux/task_work.h:33 [inline] do_exit+0x5ce/0x2200 kernel/exit.c:931 do_group_exit+0x144/0x310 kernel/exit.c:1046 __do_sys_exit_group kernel/exit.c:1057 [inline] __se_sys_exit_group kernel/exit.c:1055 [inline] __x64_sys_exit_group+0x3b/0x40 kernel/exit.c:1055 do_syscall_64+0x6c/0xd0 entry_SYSCALL_64_after_hwframe+0x61/0xcb RIP: 0033:0x7fe5e7b52479 Code: Unable to access opcode bytes at RIP 0x7fe5e7b5244f. RSP: 002b:00007ffd3c800398 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7 RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007fe5e7b52479 RDX: 000000000000003c RSI: 00000000000000e7 RDI: 0000000000000000 RBP: 00007fe5e7bcd2d0 R08: ffffffffffffffb8 R09: 0000000000000014 R10: 0000000000000000 R11: 0000000000000246 R12: 00007fe5e7bcd2d0 R13: 0000000000000000 R14: 00007fe5e7bcdd20 R15: 00007fe5e7b24270 The crash can be also be reproduced with the following (with a tc recompiled to allow for sfq limits of 1): tc qdisc add dev dummy0 handle 1: root tbf rate 1Kbit burst 100b lat 1s ../iproute2-6.9.0/tc/tc qdisc add dev dummy0 handle 2: parent 1:10 sfq limit 1 ifconfig dummy0 up ping -I dummy0 -f -c2 -W0.1 8.8.8.8 sleep 1 Scenario that triggers the crash: * the first packet is sent and queued in TBF and SFQ; qdisc qlen is 1 * TBF dequeues: it peeks from SFQ which moves the packet to the gso_skb list and keeps qdisc qlen set to 1. TBF is out of tokens so it schedules itself for later. * the second packet is sent and TBF tries to queues it to SFQ. qdisc qlen is now 2 and because the SFQ limit is 1 the packet is dropped by SFQ. At this point qlen is 1, and all of the SFQ slots are empty, however q->tail is not NULL. At this point, assuming no more packets are queued, when sch_dequeue runs again it will decrement the qlen for the current empty slot causing an underflow and the subsequent out of bounds access. Reported-by: syzbot <[email protected]> Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Octavian Purdila <[email protected]> Reviewed-by: Eric Dumazet <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Pablo Neira Ayuso <[email protected]> Date: Mon Jan 6 23:40:50 2025 +0100 netfilter: nf_tables: fix set size with rbtree backend [ Upstream commit 8d738c1869f611955d91d8d0fd0012d9ef207201 ] The existing rbtree implementation uses singleton elements to represent ranges, however, userspace provides a set size according to the number of ranges in the set. Adjust provided userspace set size to the number of singleton elements in the kernel by multiplying the range by two. Check if the no-match all-zero element is already in the set, in such case release one slot in the set size. Fixes: 0ed6389c483d ("netfilter: nf_tables: rename set implementations") Signed-off-by: Pablo Neira Ayuso <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Pablo Neira Ayuso <[email protected]> Date: Tue Jan 28 12:26:33 2025 +0100 netfilter: nf_tables: reject mismatching sum of field_len with set key length commit 1b9335a8000fb70742f7db10af314104b6ace220 upstream. The field length description provides the length of each separated key field in the concatenation, each field gets rounded up to 32-bits to calculate the pipapo rule width from pipapo_init(). The set key length provides the total size of the key aligned to 32-bits. Register-based arithmetics still allows for combining mismatching set key length and field length description, eg. set key length 10 and field description [ 5, 4 ] leading to pipapo width of 12. Cc: [email protected] Fixes: 3ce67e3793f4 ("netfilter: nf_tables: do not allow mismatch field size and set key length") Reported-by: Noam Rathaus <[email protected]> Reviewed-by: Florian Westphal <[email protected]> Signed-off-by: Pablo Neira Ayuso <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Florian Westphal <[email protected]> Date: Tue Jan 14 00:50:34 2025 +0100 netfilter: nft_flow_offload: update tcp state flags under lock [ Upstream commit 7a4b61406395291ffb7220a10e8951a9a8684819 ] The conntrack entry is already public, there is a small chance that another CPU is handling a packet in reply direction and racing with the tcp state update. Move this under ct spinlock. This is done once, when ct is about to be offloaded, so this should not result in a noticeable performance hit. Fixes: 8437a6209f76 ("netfilter: nft_flow_offload: set liberal tracking mode for tcp") Signed-off-by: Florian Westphal <[email protected]> Signed-off-by: Pablo Neira Ayuso <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Mike Snitzer <[email protected]> Date: Mon Jan 13 17:29:03 2025 -0500 nfs: fix incorrect error handling in LOCALIO [ Upstream commit ead11ac50ad4b8ef1b64806e962ea984862d96ad ] nfs4_stat_to_errno() expects a NFSv4 error code as an argument and returns a POSIX errno. The problem is LOCALIO is passing nfs4_stat_to_errno() the POSIX errno return values from filp->f_op->read_iter(), filp->f_op->write_iter() and vfs_fsync_range(). So the POSIX errno that nfs_local_pgio_done() and nfs_local_commit_done() are passing to nfs4_stat_to_errno() are failing to match any NFSv4 error code, which results in nfs4_stat_to_errno() defaulting to returning -EREMOTEIO. This causes assertions in upper layers due to -EREMOTEIO not being a valid NFSv4 error code. Fix this by updating nfs_local_pgio_done() and nfs_local_commit_done() to use the new nfs_localio_errno_to_nfs4_stat() to map a POSIX errno to an NFSv4 error code. Care was taken to factor out nfs4_errtbl_common[] to avoid duplicating the same NFS error to errno table. nfs4_errtbl_common[] is checked first by both nfs4_stat_to_errno and nfs_localio_errno_to_nfs4_stat before they check their own more specialized tables (nfs4_errtbl[] and nfs4_errtbl_localio[] respectively). While auditing the associated error mapping tables, the (ab)use of -1 for the last table entry was removed in favor of using ARRAY_SIZE to iterate the nfs_errtbl[] and nfs4_errtbl[]. And 'errno_NFSERR_IO' was removed because it caused needless obfuscation. Fixes: 70ba381e1a431 ("nfs: add LOCALIO support") Reported-by: Trond Myklebust <[email protected]> Signed-off-by: Mike Snitzer <[email protected]> Signed-off-by: Anna Schumaker <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Olga Kornievskaia <[email protected]> Date: Fri Dec 13 11:52:00 2024 -0500 NFSv4.2: fix COPY_NOTIFY xdr buf size calculation [ Upstream commit e8380c2d06055665b3df6c03964911375d7f9290 ] We need to include sequence size in the compound. Fixes: 0491567b51ef ("NFS: add COPY_NOTIFY operation") Signed-off-by: Olga Kornievskaia <[email protected]> Signed-off-by: Anna Schumaker <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Olga Kornievskaia <[email protected]> Date: Fri Dec 13 11:52:01 2024 -0500 NFSv4.2: mark OFFLOAD_CANCEL MOVEABLE [ Upstream commit 668135b9348c53fd205f5e07d11e82b10f31b55b ] OFFLOAD_CANCEL should be marked MOVEABLE for when we need to move tasks off a non-functional transport. Fixes: c975c2092657 ("NFS send OFFLOAD_CANCEL when COPY killed") Signed-off-by: Olga Kornievskaia <[email protected]> Signed-off-by: Anna Schumaker <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Ryusuke Konishi <[email protected]> Date: Wed Jan 8 05:00:46 2025 +0900 nilfs2: do not force clear folio if buffer is referenced [ Upstream commit ca76bb226bf47ff04c782cacbd299f12ddee1ec1 ] Patch series "nilfs2: protect busy buffer heads from being force-cleared". This series fixes the buffer head state inconsistency issues reported by syzbot that occurs when the filesystem is corrupted and falls back to read-only, and the associated buffer head use-after-free issue. This patch (of 2): Syzbot has reported that after nilfs2 detects filesystem corruption and falls back to read-only, inconsistencies in the buffer state may occur. One of the inconsistencies is that when nilfs2 calls mark_buffer_dirty() to set a data or metadata buffer as dirty, but it detects that the buffer is not in the uptodate state: WARNING: CPU: 0 PID: 6049 at fs/buffer.c:1177 mark_buffer_dirty+0x2e5/0x520 fs/buffer.c:1177 ... Call Trace: <TASK> nilfs_palloc_commit_alloc_entry+0x4b/0x160 fs/nilfs2/alloc.c:598 nilfs_ifile_create_inode+0x1dd/0x3a0 fs/nilfs2/ifile.c:73 nilfs_new_inode+0x254/0x830 fs/nilfs2/inode.c:344 nilfs_mkdir+0x10d/0x340 fs/nilfs2/namei.c:218 vfs_mkdir+0x2f9/0x4f0 fs/namei.c:4257 do_mkdirat+0x264/0x3a0 fs/namei.c:4280 __do_sys_mkdirat fs/namei.c:4295 [inline] __se_sys_mkdirat fs/namei.c:4293 [inline] __x64_sys_mkdirat+0x87/0xa0 fs/namei.c:4293 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f The other is when nilfs_btree_propagate(), which propagates the dirty state to the ancestor nodes of a b-tree that point to a dirty buffer, detects that the origin buffer is not dirty, even though it should be: WARNING: CPU: 0 PID: 5245 at fs/nilfs2/btree.c:2089 nilfs_btree_propagate+0xc79/0xdf0 fs/nilfs2/btree.c:2089 ... Call Trace: <TASK> nilfs_bmap_propagate+0x75/0x120 fs/nilfs2/bmap.c:345 nilfs_collect_file_data+0x4d/0xd0 fs/nilfs2/segment.c:587 nilfs_segctor_apply_buffers+0x184/0x340 fs/nilfs2/segment.c:1006 nilfs_segctor_scan_file+0x28c/0xa50 fs/nilfs2/segment.c:1045 nilfs_segctor_collect_blocks fs/nilfs2/segment.c:1216 [inline] nilfs_segctor_collect fs/nilfs2/segment.c:1540 [inline] nilfs_segctor_do_construct+0x1c28/0x6b90 fs/nilfs2/segment.c:2115 nilfs_segctor_construct+0x181/0x6b0 fs/nilfs2/segment.c:2479 nilfs_segctor_thread_construct fs/nilfs2/segment.c:2587 [inline] nilfs_segctor_thread+0x69e/0xe80 fs/nilfs2/segment.c:2701 kthread+0x2f0/0x390 kernel/kthread.c:389 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 </TASK> Both of these issues are caused by the callbacks that handle the page/folio write requests, forcibly clear various states, including the working state of the buffers they hold, at unexpected times when they detect read-only fallback. Fix these issues by checking if the buffer is referenced before clearing the page/folio state, and skipping the clear if it is. Link: https://lkml.kernel.org/r/[email protected] Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Ryusuke Konishi <[email protected]> Reported-by: [email protected] Closes: https://syzkaller.appspot.com/bug?extid=b2b14916b77acf8626d7 Reported-by: [email protected] Link: https://syzkaller.appspot.com/bug?extid=d98fd19acd08b36ff422 Fixes: 8c26c4e2694a ("nilfs2: fix issue with flush kernel thread after remount in RO mode because of driver's internal error or metadata corruption") Tested-by: [email protected] Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Ryusuke Konishi <[email protected]> Date: Sat Jan 11 23:26:35 2025 +0900 nilfs2: handle errors that nilfs_prepare_chunk() may return [ Upstream commit ee70999a988b8abc3490609142f50ebaa8344432 ] Patch series "nilfs2: fix issues with rename operations". This series fixes BUG_ON check failures reported by syzbot around rename operations, and a minor behavioral issue where the mtime of a child directory changes when it is renamed instead of moved. This patch (of 2): The directory manipulation routines nilfs_set_link() and nilfs_delete_entry() rewrite the directory entry in the folio/page previously read by nilfs_find_entry(), so error handling is omitted on the assumption that nilfs_prepare_chunk(), which prepares the buffer for rewriting, will always succeed for these. And if an error is returned, it triggers the legacy BUG_ON() checks in each routine. This assumption is wrong, as proven by syzbot: the buffer layer called by nilfs_prepare_chunk() may call nilfs_get_block() if necessary, which may fail due to metadata corruption or other reasons. This has been there all along, but improved sanity checks and error handling may have made it more reproducible in fuzzing tests. Fix this issue by adding missing error paths in nilfs_set_link(), nilfs_delete_entry(), and their caller nilfs_rename(). Link: https://lkml.kernel.org/r/[email protected] Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Ryusuke Konishi <[email protected]> Reported-by: [email protected] Closes: https://syzkaller.appspot.com/bug?extid=32c3706ebf5d95046ea1 Reported-by: [email protected] Closes: https://syzkaller.appspot.com/bug?extid=1097e95f134f37d9395c Fixes: 2ba466d74ed7 ("nilfs2: directory entry operations") Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Ryusuke Konishi <[email protected]> Date: Wed Jan 8 05:00:47 2025 +0900 nilfs2: protect access to buffers with no active references [ Upstream commit 367a9bffabe08c04f6d725032cce3d891b2b9e1a ] nilfs_lookup_dirty_data_buffers(), which iterates through the buffers attached to dirty data folios/pages, accesses the attached buffers without locking the folios/pages. For data cache, nilfs_clear_folio_dirty() may be called asynchronously when the file system degenerates to read only, so nilfs_lookup_dirty_data_buffers() still has the potential to cause use after free issues when buffers lose the protection of their dirty state midway due to this asynchronous clearing and are unintentionally freed by try_to_free_buffers(). Eliminate this race issue by adjusting the lock section in this function. Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Ryusuke Konishi <[email protected]> Fixes: 8c26c4e2694a ("nilfs2: fix issue with flush kernel thread after remount in RO mode because of driver's internal error or metadata corruption") Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Sagi Grimberg <[email protected]> Date: Sat Jan 4 23:27:11 2025 +0200 nvme-tcp: Fix I/O queue cpu spreading for multiple controllers [ Upstream commit 32193789878c259e39b97bd0c0f2f0ccbe5cb8a8 ] Since day-1 we are assigning the queue io_cpu very naively. We always base the queue id (controller scope) and assign it its matching cpu from the online mask. This works fine when the number of queues match the number of cpu cores. The problem starts when we have less queues than cpu cores. First, we should take into account the mq_map and select a cpu within the cpus that are assigned to this queue by the mq_map in order to minimize cross numa cpu bouncing. Second, even worse is that we don't take into account multiple controllers may have assigned queues to a given cpu. As a result we may simply compund more and more queues on the same set of cpus, which is suboptimal. We fix this by introducing global per-cpu counters that tracks the number of queues assigned to each cpu, and we select the least used cpu based on the mq_map and the per-cpu counters, and assign it as the queue io_cpu. The behavior for a single controller is slightly optimized by selecting better cpu candidates by consulting with the mq_map, and multiple controllers are spreading queues among cpu cores much better, resulting in lower average cpu load, and less likelihood to hit hotspots. Note that the accounting is not 100% perfect, but we don't need to be, we're simply putting our best effort to select the best candidate cpu core that we find at any given point. Another byproduct is that every controller reset/reconnect may change the queues io_cpu mapping, based on the current LRU accounting scheme. Here is the baseline queue io_cpu assignment for 4 controllers, 2 queues per controller, and 4 cpus on the host: nvme1: queue 0: using cpu 0 nvme1: queue 1: using cpu 1 nvme2: queue 0: using cpu 0 nvme2: queue 1: using cpu 1 nvme3: queue 0: using cpu 0 nvme3: queue 1: using cpu 1 nvme4: queue 0: using cpu 0 nvme4: queue 1: using cpu 1 And this is the fixed io_cpu assignment: nvme1: queue 0: using cpu 0 nvme1: queue 1: using cpu 2 nvme2: queue 0: using cpu 1 nvme2: queue 1: using cpu 3 nvme3: queue 0: using cpu 0 nvme3: queue 1: using cpu 2 nvme4: queue 0: using cpu 1 nvme4: queue 1: using cpu 3 Fixes: 3f2304f8c6d6 ("nvme-tcp: add NVMe over TCP host driver") Suggested-by: Hannes Reinecke <[email protected]> Signed-off-by: Sagi Grimberg <[email protected]> Reviewed-by: Chaitanya Kulkarni <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]> [fixed kbuild reported errors] Signed-off-by: Chaitanya Kulkarni <[email protected]> Signed-off-by: Keith Busch <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Keisuke Nishimura <[email protected]> Date: Fri Dec 20 13:00:47 2024 +0100 nvme: Add error check for xa_store in nvme_get_effects_log [ Upstream commit ac32057acc7f3d7a238dafaa9b2aa2bc9750080e ] The xa_store() may fail due to memory allocation failure because there is no guarantee that the index csi is already used. This fix adds an error check of the return value of xa_store() in nvme_get_effects_log(). Fixes: 1cf7a12e09aa ("nvme: use an xarray to lookup the Commands Supported and Effects log") Signed-off-by: Keisuke Nishimura <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]> Reviewed-by: Sagi Grimberg <[email protected]> Signed-off-by: Keith Busch <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Keisuke Nishimura <[email protected]> Date: Mon Dec 16 16:27:20 2024 +0100 nvme: Add error path for xa_store in nvme_init_effects [ Upstream commit d4a95adeabc6b5a39405e49c6d5ed14dd83682c4 ] The xa_store() may fail due to memory allocation failure because there is no guarantee that the index NVME_CSI_NVM is already used. This fix introduces a new function to handle the error path. Fixes: cc115cbe12d9 ("nvme: always initialize known command effects") Signed-off-by: Keisuke Nishimura <[email protected]> Reviewed-by: Sagi Grimberg <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]> Signed-off-by: Keith Busch <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Jens Axboe <[email protected]> Date: Mon Jan 13 10:27:54 2025 -0700 nvme: fix bogus kzalloc() return check in nvme_init_effects_log() [ Upstream commit 170e086ad3997f816d1f551f178a03a626a130b7 ] nvme_init_effects_log() returns failure when kzalloc() is successful, which is obviously wrong and causes failures to boot. Correct the check. Fixes: d4a95adeabc6 ("nvme: Add error path for xa_store in nvme_init_effects") Signed-off-by: Jens Axboe <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Su Yue <[email protected]> Date: Mon Jan 6 22:06:53 2025 +0800 ocfs2: mark dquot as inactive if failed to start trans while releasing dquot [ Upstream commit 276c61385f6bc3223a5ecd307cf4aba2dfbb9a31 ] While running fstests generic/329, the kernel workqueue quota_release_workfn is dead looping in calling ocfs2_release_dquot(). The ocfs2 state is already readonly but ocfs2_release_dquot wants to start a transaction but fails and returns. ===================================================================== [ 2918.123602 ][ T275 ] On-disk corruption discovered. Please run fsck.ocfs2 once the filesystem is unmounted. [ 2918.124034 ][ T275 ] (kworker/u135:1,275,11):ocfs2_release_dquot:765 ERROR: status = -30 [ 2918.124452 ][ T275 ] (kworker/u135:1,275,11):ocfs2_release_dquot:795 ERROR: status = -30 [ 2918.124883 ][ T275 ] (kworker/u135:1,275,11):ocfs2_start_trans:357 ERROR: status = -30 [ 2918.125276 ][ T275 ] OCFS2: abort (device dm-0): ocfs2_start_trans: Detected aborted journal [ 2918.125710 ][ T275 ] On-disk corruption discovered. Please run fsck.ocfs2 once the filesystem is unmounted. ===================================================================== ocfs2_release_dquot() is much like dquot_release(), which is called by ext4 to handle similar situation. So here fix it by marking the dquot as inactive like what dquot_release() does. Link: https://lkml.kernel.org/r/[email protected] Fixes: 9e33d69f553a ("ocfs2: Implementation of local and global quota file handling") Signed-off-by: Su Yue <[email protected]> Reviewed-by: Joseph Qi <[email protected]> Cc: Mark Fasheh <[email protected]> Cc: Joel Becker <[email protected]> Cc: Junxiao Bi <[email protected]> Cc: Changwei Ge <[email protected]> Cc: Jun Piao <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Shinas Rasheed <[email protected]> Date: Fri Jan 17 01:46:50 2025 -0800 octeon_ep: remove firmware stats fetch in ndo_get_stats64 [ Upstream commit 1f64255bb76c11d0c41a7d81d7cec68e49d5362d ] The firmware stats fetch call that happens in ndo_get_stats64() is currently not required, and causes a warning to issue. The warn log is given below: [ 123.316837] ------------[ cut here ]------------ [ 123.316840] Voluntary context switch within RCU read-side critical section! [ 123.316917] pc : rcu_note_context_switch+0x2e4/0x300 [ 123.316919] lr : rcu_note_context_switch+0x2e4/0x300 [ 123.316947] Call trace: [ 123.316949] rcu_note_context_switch+0x2e4/0x300 [ 123.316952] __schedule+0x84/0x584 [ 123.316955] schedule+0x38/0x90 [ 123.316956] schedule_timeout+0xa0/0x1d4 [ 123.316959] octep_send_mbox_req+0x190/0x230 [octeon_ep] [ 123.316966] octep_ctrl_net_get_if_stats+0x78/0x100 [octeon_ep] [ 123.316970] octep_get_stats64+0xd4/0xf0 [octeon_ep] [ 123.316975] dev_get_stats+0x4c/0x114 [ 123.316977] dev_seq_printf_stats+0x3c/0x11c [ 123.316980] dev_seq_show+0x1c/0x40 [ 123.316982] seq_read_iter+0x3cc/0x4e0 [ 123.316985] seq_read+0xc8/0x110 [ 123.316987] proc_reg_read+0x9c/0xec [ 123.316990] vfs_read+0xc8/0x2ec [ 123.316993] ksys_read+0x70/0x100 [ 123.316995] __arm64_sys_read+0x20/0x30 [ 123.316997] invoke_syscall.constprop.0+0x7c/0xd0 [ 123.317000] do_el0_svc+0xb4/0xd0 [ 123.317002] el0_svc+0xe8/0x1f4 [ 123.317005] el0t_64_sync_handler+0x134/0x150 [ 123.317006] el0t_64_sync+0x17c/0x180 [ 123.317008] ---[ end trace 63399811432ab69b ]--- Fixes: 6a610a46bad1 ("octeon_ep: add support for ndo ops") Signed-off-by: Shinas Rasheed <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Shinas Rasheed <[email protected]> Date: Fri Jan 17 01:46:52 2025 -0800 octeon_ep_vf: remove firmware stats fetch in ndo_get_stats64 [ Upstream commit cc0e510cc89fe0a6479203bc20cd964962dc6a43 ] The firmware stats fetch call that happens in ndo_get_stats64() is currently not required, and causes a warning to issue. The corresponding warn log for the PF is given below: [ 123.316837] ------------[ cut here ]------------ [ 123.316840] Voluntary context switch within RCU read-side critical section! [ 123.316917] pc : rcu_note_context_switch+0x2e4/0x300 [ 123.316919] lr : rcu_note_context_switch+0x2e4/0x300 [ 123.316947] Call trace: [ 123.316949] rcu_note_context_switch+0x2e4/0x300 [ 123.316952] __schedule+0x84/0x584 [ 123.316955] schedule+0x38/0x90 [ 123.316956] schedule_timeout+0xa0/0x1d4 [ 123.316959] octep_send_mbox_req+0x190/0x230 [octeon_ep] [ 123.316966] octep_ctrl_net_get_if_stats+0x78/0x100 [octeon_ep] [ 123.316970] octep_get_stats64+0xd4/0xf0 [octeon_ep] [ 123.316975] dev_get_stats+0x4c/0x114 [ 123.316977] dev_seq_printf_stats+0x3c/0x11c [ 123.316980] dev_seq_show+0x1c/0x40 [ 123.316982] seq_read_iter+0x3cc/0x4e0 [ 123.316985] seq_read+0xc8/0x110 [ 123.316987] proc_reg_read+0x9c/0xec [ 123.316990] vfs_read+0xc8/0x2ec [ 123.316993] ksys_read+0x70/0x100 [ 123.316995] __arm64_sys_read+0x20/0x30 [ 123.316997] invoke_syscall.constprop.0+0x7c/0xd0 [ 123.317000] do_el0_svc+0xb4/0xd0 [ 123.317002] el0_svc+0xe8/0x1f4 [ 123.317005] el0t_64_sync_handler+0x134/0x150 [ 123.317006] el0t_64_sync+0x17c/0x180 [ 123.317008] ---[ end trace 63399811432ab69b ]--- Fixes: c3fad23cdc06 ("octeon_ep_vf: add support for ndo ops") Signed-off-by: Shinas Rasheed <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Dmytro Maluka <[email protected]> Date: Sun Jan 5 17:27:41 2025 +0000 of/fdt: Restore possibility to use both ACPI and FDT from bootloader [ Upstream commit 14bce187d1600710623d81888da3501bbc470ba2 ] There are cases when the bootloader provides information to the kernel in both ACPI and DTB, not interchangeably. One such use case is virtual machines in Android. When running on x86, the Android Virtualization Framework (AVF) boots VMs with ACPI like it is usually done on x86 (i.e. the virtual LAPIC, IOAPIC, HPET, PCI MMCONFIG etc are described in ACPI) but also passes various AVF-specific boot parameters in DTB. This allows reusing the same implementations of various AVF components on both arm64 and x86. Commit 7b937cc243e5 ("of: Create of_root if no dtb provided by firmware") removed the possibility to do that, since among other things it introduced forcing emptying the bootloader-provided DTB if ACPI is enabled (probably assuming that if ACPI is available, a DTB can only be useful for applying overlays to it afterwards, for testing purposes). So restore this possibility. Instead of completely preventing using ACPI and DT together, rely on arch-specific setup code to prevent using both to set up the same things (see various acpi_disabled checks under arch/). Fixes: 7b937cc243e5 ("of: Create of_root if no dtb provided by firmware") Signed-off-by: Dmytro Maluka <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Rob Herring (Arm) <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Zijun Hu <[email protected]> Date: Thu Jan 9 21:26:57 2025 +0800 of: property: Avoiding using uninitialized variable @imaplen in parse_interrupt_map() [ Upstream commit f73780e772c06901e99b2ad114b7f0f3fbe73ad4 ] parse_interrupt_map() will use uninitialized variable @imaplen if fails to get property 'interrupt-map'. Fix by using the variable after successfully getting the property. Fixes: e7985f43609c ("of: property: Fix fw_devlink handling of interrupt-map") Signed-off-by: Zijun Hu <[email protected]> Reviewed-by: Krzysztof Kozlowski <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Rob Herring (Arm) <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Zijun Hu <[email protected]> Date: Thu Jan 9 21:27:01 2025 +0800 of: reserved-memory: Do not make kmemleak ignore freed address [ Upstream commit 29091a52562bca4d6e678dd8f0085dac119d6a21 ] early_init_dt_alloc_reserved_memory_arch() will free address @base when suffers memblock_mark_nomap() error, but it still makes kmemleak ignore the freed address @base via kmemleak_ignore_phys(). That is unnecessary, besides, also causes unnecessary warning messages: kmemleak_ignore_phys() -> make_black_object() -> paint_ptr() -> kmemleak_warn() // warning message here. Fix by avoiding kmemleak_ignore_phys() when suffer the error. Fixes: 658aafc8139c ("memblock: exclude MEMBLOCK_NOMAP regions from kmemleak") Signed-off-by: Zijun Hu <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Rob Herring (Arm) <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Neil Armstrong <[email protected]> Date: Tue Dec 3 09:12:59 2024 +0100 OPP: add index check to assert to avoid buffer overflow in _read_freq() [ Upstream commit d659bc68ed489022ea33342cfbda2911a81e7a0d ] Pass the freq index to the assert function to make sure we do not read a freq out of the opp->rates[] table when called from the indexed variants: dev_pm_opp_find_freq_exact_indexed() or dev_pm_opp_find_freq_ceil/floor_indexed(). Add a secondary parameter to the assert function, unused for assert_single_clk() then add assert_clk_index() which will check for the clock index when called from the _indexed() find functions. Fixes: 142e17c1c2b4 ("OPP: Introduce dev_pm_opp_find_freq_{ceil/floor}_indexed() APIs") Fixes: a5893928bb17 ("OPP: Add dev_pm_opp_find_freq_exact_indexed()") Signed-off-by: Neil Armstrong <[email protected]> Signed-off-by: Viresh Kumar <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Neil Armstrong <[email protected]> Date: Tue Dec 3 09:13:00 2024 +0100 OPP: fix dev_pm_opp_find_bw_*() when bandwidth table not initialized [ Upstream commit b44b9bc7cab2967c3d6a791b1cd542c89fc07f0e ] If a driver calls dev_pm_opp_find_bw_ceil/floor() the retrieve bandwidth from the OPP table but the bandwidth table was not created because the interconnect properties were missing in the OPP consumer node, the kernel will crash with: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000004 ... pc : _read_bw+0x8/0x10 lr : _opp_table_find_key+0x9c/0x174 ... Call trace: _read_bw+0x8/0x10 (P) _opp_table_find_key+0x9c/0x174 (L) _find_key+0x98/0x168 dev_pm_opp_find_bw_ceil+0x50/0x88 ... In order to fix the crash, create an assert function to check if the bandwidth table was created before trying to get a bandwidth with _read_bw(). Fixes: add1dc094a74 ("OPP: Use generic key finding helpers for bandwidth key") Signed-off-by: Neil Armstrong <[email protected]> Signed-off-by: Viresh Kumar <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Joe Hattori <[email protected]> Date: Tue Jan 7 14:44:53 2025 +0900 OPP: OF: Fix an OF node leak in _opp_add_static_v2() [ Upstream commit 1d38eb7f7b26261a0b642f6e0923269c7c000a97 ] _opp_add_static_v2() leaks the obtained OF node reference when _of_opp_alloc_required_opps() fails. Add an of_node_put() call in the error path. Fixes: 3466ea2cd6b6 ("OPP: Don't drop opp->np reference while it is still in use") Signed-off-by: Joe Hattori <[email protected]> Signed-off-by: Viresh Kumar <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Chen Ridong <[email protected]> Date: Fri Jan 10 06:16:37 2025 +0000 padata: add pd get/put refcnt helper [ Upstream commit ae154202cc6a189b035359f3c4e143d5c24d5352 ] Add helpers for pd to get/put refcnt to make code consice. Signed-off-by: Chen Ridong <[email protected]> Acked-by: Daniel Jordan <[email protected]> Signed-off-by: Herbert Xu <[email protected]> Stable-dep-of: dd7d37ccf6b1 ("padata: avoid UAF for reorder_work") Signed-off-by: Sasha Levin <[email protected]>
Author: Chen Ridong <[email protected]> Date: Fri Jan 10 06:16:39 2025 +0000 padata: avoid UAF for reorder_work [ Upstream commit dd7d37ccf6b11f3d95e797ebe4e9e886d0332600 ] Although the previous patch can avoid ps and ps UAF for _do_serial, it can not avoid potential UAF issue for reorder_work. This issue can happen just as below: crypto_request crypto_request crypto_del_alg padata_do_serial ... padata_reorder // processes all remaining // requests then breaks while (1) { if (!padata) break; ... } padata_do_serial // new request added list_add // sees the new request queue_work(reorder_work) padata_reorder queue_work_on(squeue->work) ... <kworker context> padata_serial_worker // completes new request, // no more outstanding // requests crypto_del_alg // free pd <kworker context> invoke_padata_reorder // UAF of pd To avoid UAF for 'reorder_work', get 'pd' ref before put 'reorder_work' into the 'serial_wq' and put 'pd' ref until the 'serial_wq' finish. Fixes: bbefa1dd6a6d ("crypto: pcrypt - Avoid deadlock by using per-instance padata queues") Signed-off-by: Chen Ridong <[email protected]> Acked-by: Daniel Jordan <[email protected]> Signed-off-by: Herbert Xu <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Thomas Weißschuh <[email protected]> Date: Fri Dec 27 23:32:01 2024 +0100 padata: fix sysfs store callback check [ Upstream commit 9ff6e943bce67d125781fe4780a5d6f072dc44c0 ] padata_sysfs_store() was copied from padata_sysfs_show() but this check was not adapted. Today there is no attribute which can fail this check, but if there is one it may as well be correct. Fixes: 5e017dc3f8bc ("padata: Added sysfs primitives to padata subsystem") Signed-off-by: Thomas Weißschuh <[email protected]> Signed-off-by: Herbert Xu <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Chen Ridong <[email protected]> Date: Fri Jan 10 06:16:38 2025 +0000 padata: fix UAF in padata_reorder [ Upstream commit e01780ea4661172734118d2a5f41bc9720765668 ] A bug was found when run ltp test: BUG: KASAN: slab-use-after-free in padata_find_next+0x29/0x1a0 Read of size 4 at addr ffff88bbfe003524 by task kworker/u113:2/3039206 CPU: 0 PID: 3039206 Comm: kworker/u113:2 Kdump: loaded Not tainted 6.6.0+ Workqueue: pdecrypt_parallel padata_parallel_worker Call Trace: <TASK> dump_stack_lvl+0x32/0x50 print_address_description.constprop.0+0x6b/0x3d0 print_report+0xdd/0x2c0 kasan_report+0xa5/0xd0 padata_find_next+0x29/0x1a0 padata_reorder+0x131/0x220 padata_parallel_worker+0x3d/0xc0 process_one_work+0x2ec/0x5a0 If 'mdelay(10)' is added before calling 'padata_find_next' in the 'padata_reorder' function, this issue could be reproduced easily with ltp test (pcrypt_aead01). This can be explained as bellow: pcrypt_aead_encrypt ... padata_do_parallel refcount_inc(&pd->refcnt); // add refcnt ... padata_do_serial padata_reorder // pd while (1) { padata_find_next(pd, true); // using pd queue_work_on ... padata_serial_worker crypto_del_alg padata_put_pd_cnt // sub refcnt padata_free_shell padata_put_pd(ps->pd); // pd is freed // loop again, but pd is freed // call padata_find_next, UAF } In the padata_reorder function, when it loops in 'while', if the alg is deleted, the refcnt may be decreased to 0 before entering 'padata_find_next', which leads to UAF. As mentioned in [1], do_serial is supposed to be called with BHs disabled and always happen under RCU protection, to address this issue, add synchronize_rcu() in 'padata_free_shell' wait for all _do_serial calls to finish. [1] https://lore.kernel.org/all/[email protected]/ [2] https://lore.kernel.org/linux-kernel/jfjz5d7zwbytztackem7ibzalm5lnxldi2eofeiczqmqs2m7o6@fq426cwnjtkm/ Fixes: b128a3040935 ("padata: allocate workqueue internally") Signed-off-by: Chen Ridong <[email protected]> Signed-off-by: Qu Zicheng <[email protected]> Acked-by: Daniel Jordan <[email protected]> Signed-off-by: Herbert Xu <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Randy Dunlap <[email protected]> Date: Fri Jan 10 22:27:58 2025 -0800 partitions: ldm: remove the initial kernel-doc notation [ Upstream commit e494e451611a3de6ae95f99e8339210c157d70fb ] Remove the file's first comment describing what the file is. This comment is not in kernel-doc format so it causes a kernel-doc warning. ldm.h:13: warning: expecting prototype for ldm(). Prototype was for _FS_PT_LDM_H_() instead Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Randy Dunlap <[email protected]> Cc: Richard Russon (FlatCap) <[email protected]> Cc: [email protected] Cc: Jens Axboe <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jens Axboe <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Richard Zhu <[email protected]> Date: Tue Dec 10 16:15:56 2024 +0800 PCI: dwc: Always stop link in the dw_pcie_suspend_noirq [ Upstream commit 86a016e278b78cc2281edd4ffaddbc011c87a593 ] On the i.MX8QM, PCIe link can't be re-established again in dw_pcie_resume_noirq(), if the LTSSM_EN bit is not cleared properly in dw_pcie_suspend_noirq(). So, add dw_pcie_stop_link() to dw_pcie_suspend_noirq() to fix this issue and to align the suspend/resume functions since there is dw_pcie_start_link() in dw_pcie_resume_noirq() already. Fixes: 4774faf854f5 ("PCI: dwc: Implement generic suspend/resume functionality") Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Richard Zhu <[email protected]> [kwilczynski: commit log] Signed-off-by: Krzysztof Wilczyński <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]> Reviewed-by: Manivannan Sadhasivam <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Zijun Hu <[email protected]> Date: Tue Dec 10 22:00:18 2024 +0800 PCI: endpoint: Destroy the EPC device in devm_pci_epc_destroy() [ Upstream commit d4929755e4d02bd3de3ae5569dab69cb9502c54f ] The devm_pci_epc_destroy() comment says destroys the EPC device, but it does not actually do that since devres_destroy() does not call devm_pci_epc_release(), and it also can not fully undo what the API devm_pci_epc_create() does, so it is faulty. Fortunately, the faulty API has not been used by current kernel tree. Use devres_release() instead of devres_destroy() so the EPC device will be released. Link: https://lore.kernel.org/r/[email protected] Fixes: 5e8cb4033807 ("PCI: endpoint: Add EP core layer to enable EP controller and EP functions") Signed-off-by: Zijun Hu <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Manivannan Sadhasivam <[email protected]> Date: Thu Jan 16 22:46:47 2025 +0530 PCI: endpoint: pci-epf-test: Fix check for DMA MEMCPY test [ Upstream commit 235c2b197a8de2887f13990094a3343d2392155b ] Currently, if DMA MEMCPY test is requested by the host, and if the endpoint DMA controller supports DMA_PRIVATE, the test will fail. This is not correct since there is no check for DMA_MEMCPY capability and the DMA controller can support both DMA_PRIVATE and DMA_MEMCPY. Fix the check and also reword the error message. Link: https://lore.kernel.org/r/[email protected] Fixes: 8353813c88ef ("PCI: endpoint: Enable DMA tests for endpoints with DMA capabilities") Reported-by: Niklas Cassel <[email protected]> Closes: https://lore.kernel.org/linux-pci/Z3QtEihbiKIGogWA@ryzen Signed-off-by: Manivannan Sadhasivam <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]> Tested-by: Niklas Cassel <[email protected]> Reviewed-by: Niklas Cassel <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Mohamed Khalfella <[email protected]> Date: Fri Dec 27 08:08:41 2024 -0800 PCI: endpoint: pci-epf-test: Set dma_chan_rx pointer to NULL on error [ Upstream commit b1b1f4b12969130c0a6ec0cf0299460cb01e799c ] If dma_chan_tx allocation fails, set dma_chan_rx to NULL after it is freed. Link: https://lore.kernel.org/r/[email protected] Fixes: 8353813c88ef ("PCI: endpoint: Enable DMA tests for endpoints with DMA capabilities") Signed-off-by: Mohamed Khalfella <[email protected]> [kwilczynski: commit log] Signed-off-by: Krzysztof Wilczyński <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]> Reviewed-by: Niklas Cassel <[email protected]> Reviewed-by: Manivannan Sadhasivam <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Richard Zhu <[email protected]> Date: Tue Nov 26 15:56:58 2024 +0800 PCI: imx6: Add missing reference clock disable logic [ Upstream commit 93d883f89063744a92006fc356b1c767eb62d950 ] Ensure the *_enable_ref_clk() function is symmetric by addressing missing disable parts on some platforms. Fixes: d0a75c791f98 ("PCI: imx6: Factor out ref clock disable to match enable") Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Richard Zhu <[email protected]> Signed-off-by: Krzysztof Wilczyński <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]> Reviewed-by: Manivannan Sadhasivam <[email protected]> Reviewed-by: Frank Li <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Frank Li <[email protected]> Date: Tue Nov 19 14:44:24 2024 -0500 PCI: imx6: Configure PHY based on Root Complex or Endpoint mode [ Upstream commit de22e20589b79f35f92543119c33051f8179dba0 ] Pass PHY_MODE_PCIE_EP if the PCI controller operates in Endpoint (EP) mode, and fix the Root Complex (RC) mode being hardcoded using a drvdata mode check. Fixes: 8026f2d8e8a9 ("PCI: imx6: Call common PHY API to set mode, speed, and submode") Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Frank Li <[email protected]> [kwilczynski: commit log] Signed-off-by: Krzysztof Wilczyński <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]> Reviewed-by: Manivannan Sadhasivam <[email protected]> Reviewed-by: Richard Zhu <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Richard Zhu <[email protected]> Date: Tue Nov 26 15:56:57 2024 +0800 PCI: imx6: Deassert apps_reset in imx_pcie_deassert_core_reset() [ Upstream commit ef61c7d8d032adb467f99d03ccfaa293b417ac75 ] Since the apps_reset is asserted in imx_pcie_assert_core_reset(), it should be deasserted in imx_pcie_deassert_core_reset(). Fixes: 9b3fe6796d7c ("PCI: imx6: Add code to support i.MX7D") Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Richard Zhu <[email protected]> Signed-off-by: Krzysztof Wilczyński <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]> Reviewed-by: Manivannan Sadhasivam <[email protected]> Reviewed-by: Frank Li <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Richard Zhu <[email protected]> Date: Tue Nov 26 15:56:56 2024 +0800 PCI: imx6: Skip controller_id generation logic for i.MX7D [ Upstream commit f068ffdd034c93f0c768acdc87d4d2d7023c1379 ] The i.MX7D only has one PCIe controller, so controller_id should always be 0. The previous code is incorrect although yielding the correct result. Fix by removing "IMX7D" from the switch case branch. Fixes: 2d8ed461dbc9 ("PCI: imx6: Add support for i.MX8MQ") Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Richard Zhu <[email protected]> Signed-off-by: Krzysztof Wilczyński <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]> Reviewed-by: Manivannan Sadhasivam <[email protected]> Reviewed-by: Frank Li <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Daire McNamara <[email protected]> Date: Fri Oct 11 15:00:42 2024 +0100 PCI: microchip: Set inbound address translation for coherent or non-coherent mode [ Upstream commit 1390a33b3d04fdf6ba4e3e7082107a12027fc188 ] On Microchip PolarFire SoC the PCIe Root Port can be behind one of three general purpose Fabric Interface Controller (FIC) buses that encapsulates an AXI-S bus. Depending on which FIC(s) the Root Port is connected through to CPU space, and what address translation is done by that FIC, the Root Port driver's inbound address translation may vary. For all current supported designs and all future expected designs, inbound address translation done by a FIC on PolarFire SoC varies depending on whether PolarFire SoC is operating in coherent DMA mode or noncoherent DMA mode. The setup of the outbound address translation tables in the Root Port driver only needs to handle these two cases. Setup the inbound address translation tables to one of two address translations, depending on whether the Root Port is being used with coherent DMA or noncoherent DMA. Link: https://lore.kernel.org/r/[email protected] Fixes: 6f15a9c9f941 ("PCI: microchip: Add Microchip PolarFire PCIe controller driver") Signed-off-by: Daire McNamara <[email protected]> [bhelgaas: adapt for ac7f53b7e728 ("PCI: microchip: Add support for using either Root Port 1 or 2")] Signed-off-by: Bjorn Helgaas <[email protected]> Acked-by: Conor Dooley <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Krishna chaitanya chundru <[email protected]> Date: Sat Nov 23 00:40:01 2024 +0530 PCI: qcom: Update ICC and OPP values after Link Up event [ Upstream commit f0639013d340580b72df95d012a93f35eeb0da64 ] 4581403f6792 ("PCI: qcom: Enumerate endpoints based on Link up event in 'global_irq' interrupt") added the Link Up-based enumeration support, but did not update the ICC/OPP vote once link is up. Before that, the update happened during probe and the endpoints may or may not be enumerated at that time, so the ICC/OPP vote was not guaranteed to be accurate. With Link Up-based enumeration support, the driver can request the accurate vote based on the PCIe link. Call qcom_pcie_icc_opp_update() in qcom_pcie_global_irq_thread() after enumerating the endpoints. Fixes: 4581403f6792 ("PCI: qcom: Enumerate endpoints based on Link up event in 'global_irq' interrupt") Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Krishna chaitanya chundru <[email protected]> [kwilczynski: commit log] Signed-off-by: Krzysztof Wilczyński <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]> Reviewed-by: Manivannan Sadhasivam <[email protected]> Reviewed-by: Niklas Cassel <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: King Dix <[email protected]> Date: Thu Jan 9 08:50:18 2025 +0800 PCI: rcar-ep: Fix incorrect variable used when calling devm_request_mem_region() [ Upstream commit 2d2da5a4c1b4509f6f7e5a8db015cd420144beb4 ] The rcar_pcie_parse_outbound_ranges() uses the devm_request_mem_region() macro to request a needed resource. A string variable that lives on the stack is then used to store a dynamically computed resource name, which is then passed on as one of the macro arguments. This can lead to undefined behavior. Depending on the current contents of the memory, the manifestations of errors may vary. One possible output may be as follows: $ cat /proc/iomem 30000000-37ffffff : 38000000-3fffffff : Sometimes, garbage may appear after the colon. In very rare cases, if no NULL-terminator is found in memory, the system might crash because the string iterator will overrun which can lead to access of unmapped memory above the stack. Thus, fix this by replacing outbound_name with the name of the previously requested resource. With the changes applied, the output will be as follows: $ cat /proc/iomem 30000000-37ffffff : memory2 38000000-3fffffff : memory3 Fixes: 2a6d0d63d999 ("PCI: rcar: Add endpoint mode support") Link: https://lore.kernel.org/r/[email protected] Tested-by: Lad Prabhakar <[email protected]> Signed-off-by: King Dix <[email protected]> [kwilczynski: commit log] Signed-off-by: Krzysztof Wilczyński <[email protected]> Reviewed-by: Lad Prabhakar <[email protected]> Reviewed-by: Manivannan Sadhasivam <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Dan Carpenter <[email protected]> Date: Mon Dec 2 12:07:22 2024 +0300 PCI: rockchip-ep: Fix error code in rockchip_pcie_ep_init_ob_mem() [ Upstream commit 7ca288760007cab6588dc17f5b6fecf52c83a945 ] Return -ENOMEM if pci_epc_mem_alloc_addr() fails. Don't return success. Link: https://lore.kernel.org/r/[email protected] Fixes: 945648019466 ("PCI: rockchip-ep: Refactor rockchip_pcie_ep_probe() memory allocations") Signed-off-by: Dan Carpenter <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]> Signed-off-by: Krzysztof Wilczyński <[email protected]> Reviewed-by: Damien Le Moal <[email protected]> Reviewed-by: Manivannan Sadhasivam <[email protected]> Reviewed-by: Niklas Cassel <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Damien Le Moal <[email protected]> Date: Mon Dec 16 22:34:04 2024 +0900 PCI: rockchip: Add missing fields descriptions for struct rockchip_pcie_ep [ Upstream commit fd46bc0e0bb3c6607363bd23f2b3c2a73dc75d66 ] When compiling the Rockchip endpoint driver with -W=1, the following warnings can be seen in the output: drivers/pci/controller/pcie-rockchip-ep.c:59: warning: Function parameter or struct member 'perst_irq' not described in 'rockchip_pcie_ep' drivers/pci/controller/pcie-rockchip-ep.c:59: warning: Function parameter or struct member 'perst_asserted' not described in 'rockchip_pcie_ep' drivers/pci/controller/pcie-rockchip-ep.c:59: warning: Function parameter or struct member 'link_up' not described in 'rockchip_pcie_ep' drivers/pci/controller/pcie-rockchip-ep.c:59: warning: Function parameter or struct member 'link_training' not described in 'rockchip_pcie_ep' Fix these warnings by adding the missing field descriptions in struct rockchip_pcie_ep kernel-doc comment. Fixes: a7137cbf6bd5 ("PCI: rockchip-ep: Handle PERST# signal in EP mode") Fixes: bd6e61df4b2e ("PCI: rockchip-ep: Improve link training") Link: https://lore.kernel.org/r/[email protected] Reported-by: Bjorn Helgaas <[email protected]> Signed-off-by: Damien Le Moal <[email protected]> Signed-off-by: Krzysztof Wilczyński <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]> Reviewed-by: Manivannan Sadhasivam <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Ian Rogers <[email protected]> Date: Thu Jan 23 20:38:56 2025 -0800 perf annotate: Use an array for the disassembler preference [ Upstream commit bde4ccfd5ab5361490514fc4af7497989cfbee17 ] Prior to this change a string was used which could cause issues with an unrecognized disassembler in symbol__disassembler. Change to initializing an array of perf_disassembler enum values. If a value already exists then adding it a second time is ignored to avoid array out of bounds problems present in the previous code, it also allows a statically sized array and removes memory allocation needs. Errors in the disassembler string are reported when the config is parsed during perf annotate or perf top start up. If the array is uninitialized after processing the config file the default llvm, capstone then objdump values are added but without a need to parse a string. Fixes: a6e8a58de629 ("perf disasm: Allow configuring what disassemblers to use") Closes: https://lore.kernel.org/lkml/CAP-5=fUdfCyxmEiTpzS2uumUp3-SyQOseX2xZo81-dQtWXj6vA@mail.gmail.com/ Signed-off-by: Ian Rogers <[email protected]> Tested-by: Namhyung Kim <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Namhyung Kim <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Zhongqiu Han <[email protected]> Date: Thu Dec 5 16:45:00 2024 +0800 perf bpf: Fix two memory leakages when calling perf_env__insert_bpf_prog_info() [ Upstream commit 03edb7020bb920f1935c3f30acad0bb27fdb99af ] If perf_env__insert_bpf_prog_info() returns false due to a duplicate bpf prog info node insertion, the temporary info_node and info_linear memory will leak. Add a check to ensure the memory is freed if the function returns false. Fixes: d56354dc49091e33 ("perf tools: Save bpf_prog_info and BTF of new BPF programs") Reviewed-by: Namhyung Kim <[email protected]> Signed-off-by: Zhongqiu Han <[email protected]> Cc: Adrian Hunter <[email protected]> Cc: Alexander Shishkin <[email protected]> Cc: Ian Rogers <[email protected]> Cc: Ingo Molnar <[email protected]> Cc: James Clark <[email protected]> Cc: Jiri Olsa <[email protected]> Cc: Kan Liang <[email protected]> Cc: Mark Rutland <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Song Liu <[email protected]> Cc: Yicong Yang <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Arnaldo Carvalho de Melo <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Levi Yun <[email protected]> Date: Fri Nov 8 14:34:25 2024 +0000 perf expr: Initialize is_test value in expr__ctx_new() [ Upstream commit 1d18ebcfd302a2005b83ae5f13df223894d19902 ] When expr_parse_ctx is allocated by expr_ctx_new(), expr_scanner_ctx->is_test isn't initialize, so it has garbage value. this can affects the result of expr__parse() return when it parses non-exist event literal according to garbage value. Use calloc instead of malloc in expr_ctx_new() to fix this. Fixes: 3340a08354ac286e ("perf pmu-events: Fix testing with JEVENTS_ARCH=all") Reviewed-by: Ian Rogers <[email protected]> Reviewed-by: James Clark <[email protected]> Signed-off-by: Levi Yun <[email protected]> Cc: Mark Rutland <[email protected]> Cc: Namhyung Kim <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Arnaldo Carvalho de Melo <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Zhongqiu Han <[email protected]> Date: Thu Dec 5 16:44:58 2024 +0800 perf header: Fix one memory leakage in process_bpf_btf() [ Upstream commit 875d22980a062521beed7b5df71fb13a1af15d83 ] If __perf_env__insert_btf() returns false due to a duplicate btf node insertion, the temporary node will leak. Add a check to ensure the memory is freed if the function returns false. Fixes: a70a1123174ab592 ("perf bpf: Save BTF information as headers to perf.data") Reviewed-by: Namhyung Kim <[email protected]> Signed-off-by: Zhongqiu Han <[email protected]> Cc: Adrian Hunter <[email protected]> Cc: Alexander Shishkin <[email protected]> Cc: Ian Rogers <[email protected]> Cc: Ingo Molnar <[email protected]> Cc: James Clark <[email protected]> Cc: Jiri Olsa <[email protected]> Cc: Kan Liang <[email protected]> Cc: Mark Rutland <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Song Liu <[email protected]> Cc: Yicong Yang <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Arnaldo Carvalho de Melo <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Zhongqiu Han <[email protected]> Date: Thu Dec 5 16:44:59 2024 +0800 perf header: Fix one memory leakage in process_bpf_prog_info() [ Upstream commit a7da6c7030e1aec32f0a41c7b4fa70ec96042019 ] Function __perf_env__insert_bpf_prog_info() will return without inserting bpf prog info node into perf env again due to a duplicate bpf prog info node insertion, causing the temporary info_linear and info_node memory to leak. Modify the return type of this function to bool and add a check to ensure the memory is freed if the function returns false. Fixes: 606f972b1361f477 ("perf bpf: Save bpf_prog_info information as headers to perf.data") Reviewed-by: Namhyung Kim <[email protected]> Signed-off-by: Zhongqiu Han <[email protected]> Cc: Adrian Hunter <[email protected]> Cc: Alexander Shishkin <[email protected]> Cc: Ian Rogers <[email protected]> Cc: Ingo Molnar <[email protected]> Cc: James Clark <[email protected]> Cc: Jiri Olsa <[email protected]> Cc: Kan Liang <[email protected]> Cc: Mark Rutland <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Song Liu <[email protected]> Cc: Yicong Yang <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Arnaldo Carvalho de Melo <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Ian Rogers <[email protected]> Date: Tue Dec 10 22:08:31 2024 -0800 perf inject: Fix use without initialization of local variables [ Upstream commit 8e246a1b2a75e187c7d22c9aec4299057f87d19e ] Local variables were missing initialization and command line processing didn't provide default values. Fixes: 64eed019f3fce124 ("perf inject: Lazy build-id mmap2 event insertion") Reviewed-by: James Clark <[email protected]> Signed-off-by: Ian Rogers <[email protected]> Cc: Adrian Hunter <[email protected]> Cc: Alexander Shishkin <[email protected]> Cc: Ingo Molnar <[email protected]> Cc: Jiri Olsa <[email protected]> Cc: Kan Liang <[email protected]> Cc: Mark Rutland <[email protected]> Cc: Namhyung Kim <[email protected]> Cc: Peter Zijlstra <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Arnaldo Carvalho de Melo <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Chun-Tse Shao <[email protected]> Date: Thu Jan 16 15:58:14 2025 -0800 perf lock: Fix parse_lock_type which only retrieve one lock flag [ Upstream commit 1be9264158ef4818393e5d8144887a1a5d3cc480 ] `parse_lock_type` can only add the first lock flag in `lock_type_table` given input `str`. For example, for `Y rwlock`, it only adds `rwlock:R` into this perf session. Another example is for `-Y mutex`, it only adds the mutex without `LCB_F_SPIN` flag. The patch fixes this issue, makes sure both `rwlock:R` and `rwlock:W` will be added with `-Y rwlock`, and so on. Testing: $ ./perf lock con -ab -Y mutex,rwlock -- perf bench sched pipe # Running 'sched/pipe' benchmark: # Executed 1000000 pipe operations between two processes Total time: 9.313 [sec] 9.313976 usecs/op 107365 ops/sec contended total wait max wait avg wait type caller 176 1.65 ms 19.43 us 9.38 us mutex pipe_read+0x57 34 180.14 us 10.93 us 5.30 us mutex pipe_write+0x50 7 77.48 us 16.09 us 11.07 us mutex do_epoll_wait+0x24d 7 74.70 us 13.50 us 10.67 us mutex do_epoll_wait+0x24d 3 35.97 us 14.44 us 11.99 us rwlock:W ep_done_scan+0x2d 3 35.00 us 12.23 us 11.66 us rwlock:W do_epoll_wait+0x255 2 15.88 us 11.96 us 7.94 us rwlock:W do_epoll_wait+0x47c 1 15.23 us 15.23 us 15.23 us rwlock:W do_epoll_wait+0x4d0 1 14.26 us 14.26 us 14.26 us rwlock:W ep_done_scan+0x2d 2 14.00 us 7.99 us 7.00 us mutex pipe_read+0x282 1 12.29 us 12.29 us 12.29 us rwlock:R ep_poll_callback+0x35 1 12.02 us 12.02 us 12.02 us rwlock:W do_epoll_ctl+0xb65 1 10.25 us 10.25 us 10.25 us rwlock:R ep_poll_callback+0x35 1 7.86 us 7.86 us 7.86 us mutex do_epoll_ctl+0x6c1 1 5.04 us 5.04 us 5.04 us mutex do_epoll_ctl+0x3d4 [namhyung: Add a comment and rename to 'mutex:spin' for consistency Fixes: d783ea8f62c4 ("perf lock contention: Simplify parse_lock_type()") Reviewed-by: Namhyung Kim <[email protected]> Signed-off-by: Chun-Tse Shao <[email protected]> Cc: [email protected] Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Namhyung Kim <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Christophe Leroy <[email protected]> Date: Wed Jan 8 10:15:24 2025 +0100 perf machine: Don't ignore _etext when not a text symbol [ Upstream commit 7a93786c306296f15e728b1dbd949a319e4e3d19 ] Depending on how vmlinux.lds is written, _etext might be the very first data symbol instead of the very last text symbol. Don't require it to be a text symbol, accept any symbol type. Comitter notes: See the first Link for further discussion, but it all boils down to this: --- # grep -e _stext -e _etext -e _edata /proc/kallsyms c0000000 T _stext c08b8000 D _etext So there is no _edata and _etext is not text $ ppc-linux-objdump -x vmlinux | grep -e _stext -e _etext -e _edata c0000000 g .head.text 00000000 _stext c08b8000 g .rodata 00000000 _etext c1378000 g .sbss 00000000 _edata --- Fixes: ed9adb2035b5be58 ("perf machine: Read also the end of the kernel") Signed-off-by: Christophe Leroy <[email protected]> Cc: Adrian Hunter <[email protected]> Cc: Alexander Shishkin <[email protected]> Cc: Ian Rogers <[email protected]> Cc: Ingo Molnar <[email protected]> Cc: Jiri Olsa <[email protected]> Cc: Kan Liang <[email protected]> Cc: [email protected] Cc: Mark Rutland <[email protected]> Cc: Namhyung Kim <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Song Liu <[email protected]> Link: https://lore.kernel.org/r/b3ee1994d95257cb7f2de037c5030ba7d1bed404.1736327613.git.christophe.leroy@csgroup.eu Signed-off-by: Arnaldo Carvalho de Melo <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Arnaldo Carvalho de Melo <[email protected]> Date: Tue Nov 26 17:43:18 2024 -0300 perf MANIFEST: Add arch/*/include/uapi/asm/bpf_perf_event.h to the perf tarball [ Upstream commit 74c033b6aa650ea7280221a9e57b7318a120978c ] Needed to build tools/lib/bpf/ on various arches other than x86_64, notably arm64 when using the perf tarballs generated by: $ make help | grep perf- perf-tar-src-pkg - Build the perf source tarball with no compression perf-targz-src-pkg - Build the perf source tarball with gzip compression perf-tarbz2-src-pkg - Build the perf source tarball with bz2 compression perf-tarxz-src-pkg - Build the perf source tarball with xz compression perf-tarzst-src-pkg - Build the perf source tarball with zst compression $ Building with BPF support was opt-in in perf for a long time, and testing it via the tarball main kernel Makefile targets in an architecture other than x86_64 was an odd case. I had noticed this at some point earlier this year while cross building perf to some arches, including arm64, but it fell thru the cracks, see the Link tag below. Fix it now by adding those arch/*/include/uapi/asm/bpf_perf_event.h files to the MANIFEST file used in building the perf source tarball. Tested with: perfbuilder@number:~$ time dm debian:experimental-x-arm64 1 21.60 debian:experimental-x-arm64 : Ok aarch64-linux-gnu-gcc (Debian 14.1.0-5) 14.1.0 flex 2.6.4 BUILD_TARBALL_HEAD=d31a974f6edc576f84c35be9526fec549a3b3520 $ $ git log --oneline -1 d31a974f6edc576f84c35be9526fec549a3b3520 d31a974f6edc576f (HEAD -> perf-tools-next) perf MANIFEST: Add arch/*/include/uapi/asm/bpf_perf_event.h to the perf tarball $ That was previously failing: perfbuilder@number:~$ grep debian:experimental-x-arm64 dm.log.old/summary 19 4.80 debian:experimental-x-arm64 : FAIL gcc version 14.1.0 (Debian 14.1.0-5) $ perfbuilder@number:~$ grep -B6 'Error 1' dm.log.old/debian:experimental-x-arm64 In file included from /git/perf-6.12.0-rc6/tools/include/uapi/linux/bpf_perf_event.h:11, from libbpf.c:36: /git/perf-6.12.0-rc6/tools/include/uapi/asm/bpf_perf_event.h:2:10: fatal error: ../../arch/arm64/include/uapi/asm/bpf_perf_event.h: No such file or directory 2 | #include "../../arch/arm64/include/uapi/asm/bpf_perf_event.h" | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ compilation terminated. make[4]: *** [/git/perf-6.12.0-rc6/tools/build/Makefile.build:105: /tmp/build/perf/libbpf/staticobjs/libbpf.o] Error 1 perfbuilder@number:~$ Closes: https://lore.kernel.org/all/[email protected] Fixes: 9eea8fafe33eb708 ("libbpf: fix __arg_ctx type enforcement for perf_event programs") Reported-by: Michel Lind <[email protected]> Tested-by: Michel Lind <[email protected]> Cc: Adrian Hunter <[email protected]> Cc: Alexei Starovoitov <[email protected]> Cc: Andrii Nakryiko <[email protected]> Cc: Ian Rogers <[email protected]> Cc: James Clark <[email protected]> Cc: Jiri Olsa <[email protected]> Cc: Kan Liang <[email protected]> Cc: Namhyung Kim <[email protected]> Link: [email protected] Link: https://lore.kernel.org/bpf/ZfyEgoG3JFiOs2Fs@x1/ Link: https://lore.kernel.org/r/Z0Yy5u42Q1hWoEzz@x1 Signed-off-by: Arnaldo Carvalho de Melo <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Christophe Leroy <[email protected]> Date: Wed Jan 8 10:54:20 2025 +0100 perf maps: Fix display of kernel symbols [ Upstream commit dae29277fddaaf6670d17dfcbb916a2ca29c912f ] Since commit 659ad3492b913c90 ("perf maps: Switch from rbtree to lazily sorted array for addresses"), perf doesn't display anymore kernel symbols on powerpc, allthough it still detects them as kernel addresses. # Overhead Command Shared Object Symbol # ........ .......... ............. ...................................... # 80.49% Coeur main [unknown] [k] 0xc005f0f8 3.91% Coeur main gau [.] engine_loop.constprop.0.isra.0 1.72% Coeur main [unknown] [k] 0xc005f11c 1.09% Coeur main [unknown] [k] 0xc01f82c8 0.44% Coeur main libc.so.6 [.] epoll_wait 0.38% Coeur main [unknown] [k] 0xc0011718 0.36% Coeur main [unknown] [k] 0xc01f45c0 This is because function maps__find_next_entry() now returns current entry instead of next entry, leading to kernel map end address getting mis-configured with its own start address instead of the start address of the following map. Fix it by really taking the next entry, also make sure that entry follows current one by making sure entries are sorted. Fixes: 659ad3492b913c90 ("perf maps: Switch from rbtree to lazily sorted array for addresses") Reviewed-by: Arnaldo Carvalho de Melo <[email protected]> Reviewed-by: Ian Rogers <[email protected]> Signed-off-by: Christophe Leroy <[email protected]> Cc: Adrian Hunter <[email protected]> Cc: Alexander Shishkin <[email protected]> Cc: Ingo Molnar <[email protected]> Cc: Jiri Olsa <[email protected]> Cc: Kan Liang <[email protected]> Cc: Mark Rutland <[email protected]> Cc: Namhyung Kim <[email protected]> Cc: Peter Zijlstra <[email protected]> Link: https://lore.kernel.org/r/2ea4501209d5363bac71a6757fe91c0747558a42.1736329923.git.christophe.leroy@csgroup.eu Signed-off-by: Arnaldo Carvalho de Melo <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Arnaldo Carvalho de Melo <[email protected]> Date: Fri Dec 6 17:48:28 2024 -0300 perf namespaces: Fixup the nsinfo__in_pidns() return type, its bool [ Upstream commit 64a7617efd5ae1d57a75e464d7134eec947c3fe3 ] When adding support for refconunt checking a cut'n'paste made this function, that is just an accessor to a bool member of 'struct nsinfo', return a pid_t, when that member is a boolean, fix it. Fixes: bcaf0a97858de7ab ("perf namespaces: Add functions to access nsinfo") Reported-by: Francesco Nigro <[email protected]> Reported-by: Ilan Green <[email protected]> Cc: Adrian Hunter <[email protected]> Cc: Clark Williams <[email protected]> Cc: Ian Rogers <[email protected]> Cc: Ingo Molnar <[email protected]> Cc: James Clark <[email protected]> Cc: Jiri Olsa <[email protected]> Cc: Kan Liang <[email protected]> Cc: Namhyung Kim <[email protected]> Cc: Stephane Eranian <[email protected]> Cc: Thomas Gleixner <[email protected]> Cc: Yonatan Goldschmidt <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Arnaldo Carvalho de Melo <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Arnaldo Carvalho de Melo <[email protected]> Date: Fri Dec 6 17:48:26 2024 -0300 perf namespaces: Introduce nsinfo__set_in_pidns() [ Upstream commit 9c6a585d257f6845731f4e36b45fe42b5c3162f5 ] When we're processing a perf.data file we will, for every thread in that file do a machine__findnew_thread(machine, pid, tid) that when that pid is seen for the first time will create a 'struct thread' representing it. That in turn will call nsinfo__new() -> nsinfo__init() and there it will assume we're running live, which is wrong and will need to be addressed in a followup patch. The nsinfo__new() assumes that if we can't access that thread it has already finished and will ignore the -1 return from nsinfo__init(), just taking notes to avoid trying to enter in that namespace, since it isn't there anymore, a race. When doing this from 'perf inject', tho, we can fill in parts of that nsinfo from what we get from the PERF_RECORD_MMAP2 (pid, tid) and in the jitdump file name, that has the form of jit-<PID>.dump. So if the pid in the jitdump file name is not the one in the PERF_RECORD_MMAP2, we can assume that its the pid of the process _inside_ the namespace, and that perf was runing outside that namespace. This will be done in the following patch. Reported-by: Francesco Nigro <[email protected]> Reported-by: Ilan Green <[email protected]> Cc: Adrian Hunter <[email protected]> Cc: Clark Williams <[email protected]> Cc: Ian Rogers <[email protected]> Cc: Ingo Molnar <[email protected]> Cc: James Clark <[email protected]> Cc: Jiri Olsa <[email protected]> Cc: Kan Liang <[email protected]> Cc: Namhyung Kim <[email protected]> Cc: Stephane Eranian <[email protected]> Cc: Thomas Gleixner <[email protected]> Cc: Yonatan Goldschmidt <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Arnaldo Carvalho de Melo <[email protected]> Stable-dep-of: 64a7617efd5a ("perf namespaces: Fixup the nsinfo__in_pidns() return type, its bool") Signed-off-by: Sasha Levin <[email protected]>
Author: Jiachen Zhang <[email protected]> Date: Thu Jan 9 23:22:19 2025 +0800 perf report: Fix misleading help message about --demangle [ Upstream commit ac0ac75189a4d6a29a2765a7adbb62bc6cc650c7 ] The wrong help message may mislead users. This commit fixes it. Fixes: 328ccdace8855289 ("perf report: Add --no-demangle option") Reviewed-by: Namhyung Kim <[email protected]> Signed-off-by: Jiachen Zhang <[email protected]> Cc: Adrian Hunter <[email protected]> Cc: Alexander Shishkin <[email protected]> Cc: Ian Rogers <[email protected]> Cc: Ingo Molnar <[email protected]> Cc: Jiri Olsa <[email protected]> Cc: Kan Liang <[email protected]> Cc: Mark Rutland <[email protected]> Cc: Namhyung Kim <[email protected]> Cc: Peter Zijlstra <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Arnaldo Carvalho de Melo <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: James Clark <[email protected]> Date: Tue Nov 12 16:00:41 2024 +0000 perf stat: Fix trailing comma when there is no metric unit [ Upstream commit 967364894e61b15819a0c11231512ecd5a46b503 ] Now that printing metric-value and metric-unit is optional, print_running_json() shouldn't add the comma in case it becomes trailing. Replace all manual JSON comma stuff with a json_out() function that uses the existing os->first tracking and auto inserts a comma if it's needed. Update the test to handle that two of the fields can be missing. This fixes the following test failure on Cortex A57 where the branch misses metric is missing a required event: $ perf test -vvv "json output" 106: perf stat JSON output linter: --- start --- test child forked, pid 665682 Checking json output: no args Test failed for input: {"counter-value" : "3112.000000", "unit" : "", "event" : "armv8_pmuv3_1/branch-misses/", "event-runtime" : 20699340, "pcnt-running" : 100.00, } ... json.decoder.JSONDecodeError: Expecting property name enclosed in double quotes: line 12 column 144 (char 2109) ---- end(-1) ---- 106: perf stat JSON output linter : FAILED! Fixes: e1cc918b6cfd1206 ("perf stat: Drop metric-unit if unit is NULL") Signed-off-by: James Clark <[email protected]> Tested-by: Ian Rogers <[email protected]> Cc: Adrian Hunter <[email protected]> Cc: Alexander Shishkin <[email protected]> Cc: Ian Rogers <[email protected]> Cc: Ingo Molnar <[email protected]> Cc: Jiri Olsa <[email protected]> Cc: Kan Liang <[email protected]> Cc: Mark Rutland <[email protected]> Cc: Namhyung Kim <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Tim Chen <[email protected]> Cc: Yicong Yang <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Arnaldo Carvalho de Melo <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Namhyung Kim <[email protected]> Date: Thu Jan 2 12:32:51 2025 -0800 perf symbol: Prefer non-label symbols with same address [ Upstream commit 8c2eafbbfd782d6ad270ca2de21b529ac57de0f4 ] When there are more than one symbols at the same address, it needs to choose which one is better. In choose_best_symbol() it didn't check the type of symbols. It's possible to have labels in other symbols and in that case, it would be better to pick the actual symbol over the labels. To minimize the possible impact on other symbols, I only check NOTYPE symbols specifically. $ readelf -sW vmlinux | grep -e __do_softirq -e __softirqentry_text_start 105089: ffffffff82000000 814 FUNC GLOBAL DEFAULT 1 __do_softirq 111954: ffffffff82000000 0 NOTYPE GLOBAL DEFAULT 1 __softirqentry_text_start The commit 77b004f4c5c3c90b tried to do the same by not giving the size to the label symbols but it seems there's some label-only symbols in asm code. Let's restore the original code and choose the right symbol using type of the symbols. Fixes: 77b004f4c5c3c90b ("perf symbol: Do not fixup end address of labels") Reported-by: Arnaldo Carvalho de Melo <[email protected]> Tested-by: Arnaldo Carvalho de Melo <[email protected]> Signed-off-by: Namhyung Kim <[email protected]> Cc: Adrian Hunter <[email protected]> Cc: Christophe Leroy <[email protected]> Cc: Ian Rogers <[email protected]> Cc: James Clark <[email protected]> Cc: Jiri Olsa <[email protected]> Cc: Kan Liang <[email protected]> Link: http://lore.kernel.org/lkml/[email protected] Signed-off-by: Arnaldo Carvalho de Melo <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Ian Rogers <[email protected]> Date: Thu Dec 12 09:33:54 2024 -0800 perf test stat: Avoid hybrid assumption when virtualized [ Upstream commit f9c506fb69bdcfb9d7138281378129ff037f2aa1 ] The cycles event will fallback to task-clock in the hybrid test when running virtualized. Change the test to not fail for this. Fixes: 65d11821910bd910 ("perf test: Add a test for default perf stat command") Reviewed-by: James Clark <[email protected]> Signed-off-by: Ian Rogers <[email protected]> Acked-by: Namhyung Kim <[email protected]> Cc: Adrian Hunter <[email protected]> Cc: Alexander Shishkin <[email protected]> Cc: Ingo Molnar <[email protected]> Cc: Jiri Olsa <[email protected]> Cc: Kan Liang <[email protected]> Cc: Mark Rutland <[email protected]> Cc: Peter Zijlstra <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Arnaldo Carvalho de Melo <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Namhyung Kim <[email protected]> Date: Tue Jan 28 09:06:29 2025 -0800 perf test: Skip syscall enum test if no landlock syscall [ Upstream commit 72d81e10628be6a948463259cbb6d3b670b20054 ] The perf trace enum augmentation test specifically targets landlock_ add_rule syscall but IIUC it's an optional and can be opt-out by a kernel config. Currently trace_landlock() runs `perf test -w landlock` before the actual testing to check the availability but it's not enough since the workload always returns 0. Instead it could check if perf trace output has 'landlock' string. Fixes: d66763fed30f0bd8c ("perf test trace_btf_enum: Add regression test for the BTF augmentation of enums in 'perf trace'") Reviewed-by: Howard Chu <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Namhyung Kim <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Arnaldo Carvalho de Melo <[email protected]> Date: Thu Jan 2 16:50:39 2025 -0300 perf top: Don't complain about lack of vmlinux when not resolving some kernel samples [ Upstream commit 058b38ccd2af9e5c95590b018e8425fa148d7aca ] Recently we got a case where a kernel sample wasn't being resolved due to a bug that was not setting the end address on kernel functions implemented in assembly (see Link: tag), and then those were not being found by machine__resolve() -> map__find_symbol(). So we ended up with: # perf top --stdio PerfTop: 0 irqs/s kernel: 0% exact: 0% lost: 0/0 drop: 0/0 [cycles/P] ----------------------------------------------------------------------- Warning: A vmlinux file was not found. Kernel samples will not be resolved. ^Z [1]+ Stopped perf top --stdio # But then resolving all other kernel symbols. So just fixup the logic to only print that warning when there are no symbols in the kernel map. Fixes: d88205db9caa0e9d ("perf dso: Add dso__has_symbols() method") Reviewed-by: Namhyung Kim <[email protected]> Cc: Adrian Hunter <[email protected]> Cc: Ian Rogers <[email protected]> Cc: Christophe Leroy <[email protected]> Cc: James Clark <[email protected]> Cc: Jiri Olsa <[email protected]> Cc: Kan Liang <[email protected]> Link: https://lore.kernel.org/lkml/Z3buKhcCsZi3_aGb@x1 Signed-off-by: Arnaldo Carvalho de Melo <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Howard Chu <[email protected]> Date: Thu Dec 12 18:30:47 2024 -0800 perf trace: Fix BPF loading failure (-E2BIG) [ Upstream commit 013eb043f37bd87c4d60d51034401a5a6d105bcf ] As reported by Namhyung Kim and acknowledged by Qiao Zhao (link: https://lore.kernel.org/linux-perf-users/[email protected]/), on certain machines, perf trace failed to load the BPF program into the kernel. The verifier runs perf trace's BPF program for up to 1 million instructions, returning an E2BIG error, whereas the perf trace BPF program should be much less complex than that. This patch aims to fix the issue described above. The E2BIG problem from clang-15 to clang-16 is cause by this line: } else if (size < 0 && size >= -6) { /* buffer */ Specifically this check: size < 0. seems like clang generates a cool optimization to this sign check that breaks things. Making 'size' s64, and use } else if ((int)size < 0 && size >= -6) { /* buffer */ Solves the problem. This is some Hogwarts magic. And the unbounded access of clang-12 and clang-14 (clang-13 works this time) is fixed by making variable 'aug_size' s64. As for this: -if (aug_size > TRACE_AUG_MAX_BUF) - aug_size = TRACE_AUG_MAX_BUF; +aug_size = args->args[index] > TRACE_AUG_MAX_BUF ? TRACE_AUG_MAX_BUF : args->args[index]; This makes the BPF skel generated by clang-18 work. Yes, new clangs introduce problems too. Sorry, I only know that it works, but I don't know how it works. I'm not an expert in the BPF verifier. I really hope this is not a kernel version issue, as that would make the test case (kernel_nr) * (clang_nr), a true horror story. I will test it on more kernel versions in the future. Fixes: 395d38419f18: ("perf trace augmented_raw_syscalls: Add more check s to pass the verifier") Reported-by: Namhyung Kim <[email protected]> Signed-off-by: Howard Chu <[email protected]> Tested-by: Namhyung Kim <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Namhyung Kim <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Howard Chu <[email protected]> Date: Tue Jan 21 18:55:19 2025 -0800 perf trace: Fix runtime error of index out of bounds [ Upstream commit c7b87ce0dd10b64b68a0b22cb83bbd556e28fe81 ] libtraceevent parses and returns an array of argument fields, sometimes larger than RAW_SYSCALL_ARGS_NUM (6) because it includes "__syscall_nr", idx will traverse to index 6 (7th element) whereas sc->fmt->arg holds 6 elements max, creating an out-of-bounds access. This runtime error is found by UBsan. The error message: $ sudo UBSAN_OPTIONS=print_stacktrace=1 ./perf trace -a --max-events=1 builtin-trace.c:1966:35: runtime error: index 6 out of bounds for type 'syscall_arg_fmt [6]' #0 0x5c04956be5fe in syscall__alloc_arg_fmts /home/howard/hw/linux-perf/tools/perf/builtin-trace.c:1966 #1 0x5c04956c0510 in trace__read_syscall_info /home/howard/hw/linux-perf/tools/perf/builtin-trace.c:2110 #2 0x5c04956c372b in trace__syscall_info /home/howard/hw/linux-perf/tools/perf/builtin-trace.c:2436 #3 0x5c04956d2f39 in trace__init_syscalls_bpf_prog_array_maps /home/howard/hw/linux-perf/tools/perf/builtin-trace.c:3897 #4 0x5c04956d6d25 in trace__run /home/howard/hw/linux-perf/tools/perf/builtin-trace.c:4335 #5 0x5c04956e112e in cmd_trace /home/howard/hw/linux-perf/tools/perf/builtin-trace.c:5502 #6 0x5c04956eda7d in run_builtin /home/howard/hw/linux-perf/tools/perf/perf.c:351 #7 0x5c04956ee0a8 in handle_internal_command /home/howard/hw/linux-perf/tools/perf/perf.c:404 #8 0x5c04956ee37f in run_argv /home/howard/hw/linux-perf/tools/perf/perf.c:448 #9 0x5c04956ee8e9 in main /home/howard/hw/linux-perf/tools/perf/perf.c:556 #10 0x79eb3622a3b7 in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 #11 0x79eb3622a47a in __libc_start_main_impl ../csu/libc-start.c:360 #12 0x5c04955422d4 in _start (/home/howard/hw/linux-perf/tools/perf/perf+0x4e02d4) (BuildId: 5b6cab2d59e96a4341741765ad6914a4d784dbc6) 0.000 ( 0.014 ms): Chrome_ChildIO/117244 write(fd: 238, buf: !, count: 1) = 1 Fixes: 5e58fcfaf4c6 ("perf trace: Allow allocating sc->arg_fmt even without the syscall tracepoint") Signed-off-by: Howard Chu <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Namhyung Kim <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Yabin Cui <[email protected]> Date: Wed May 15 12:36:07 2024 -0700 perf/core: Save raw sample data conditionally based on sample type [ Upstream commit b9c44b91476b67327a521568a854babecc4070ab ] Currently, space for raw sample data is always allocated within sample records for both BPF output and tracepoint events. This leads to unused space in sample records when raw sample data is not requested. This patch enforces checking sample type of an event in perf_sample_save_raw_data(). So raw sample data will only be saved if explicitly requested, reducing overhead when it is not needed. Fixes: 0a9081cf0a11 ("perf/core: Add perf_sample_save_raw_data() helper") Signed-off-by: Yabin Cui <[email protected]> Signed-off-by: Ingo Molnar <[email protected]> Reviewed-by: Ian Rogers <[email protected]> Acked-by: Namhyung Kim <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Maciej S. Szmigiero <[email protected]> Date: Mon Jan 6 18:41:15 2025 +0100 pinctrl: amd: Take suspend type into consideration which pins are non-wake [ Upstream commit f31f33dbb3bab572bad9fe7b849ab0dcbe6fd279 ] Some laptops have pins which are a wake source for S0i3/S3 but which aren't a wake source for S4/S5 and which cause issues when left unmasked during hibernation (S4). For example HP EliteBook 855 G7 has pin #24 that causes instant wakeup (hibernation failure) if left unmasked (it is a wake source only for S0i3/S3). GPIO pin #24 on this platform is likely dedicated to WWAN XMM7360 modem since this pin triggers wake notify to WWAN modem's parent PCIe port. Fix this by considering a pin a wake source only if it is marked as one for the current suspend type (S0i3/S3 vs S4/S5). Since Z-wake pins only make sense at runtime these were excluded from both of suspend categories, so pins with only the Z-wake flag set are effectively treated as non-wake pins. Fixes: 2fff0b5e1a6b ("pinctrl: amd: Mask non-wake source pins with interrupt enabled at suspend") Signed-off-by: Maciej S. Szmigiero <[email protected]> Reviewed-by: Mario Limonciello <[email protected]> Link: https://lore.kernel.org/d4b2d076366fdd08a0c1cd9b7ecd91dc95e07269.1736184752.git.mail@maciej.szmigiero.name Signed-off-by: Linus Walleij <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Mingwei Zheng <[email protected]> Date: Fri Dec 6 17:16:18 2024 -0500 pinctrl: nomadik: Add check for clk_enable() [ Upstream commit 5c4bfbb21dedf5d56a55cb0e129ccb1fd5083d14 ] Add check for the return value of clk_enable() to catch the potential error. Disable success clks in the error handling. Change return type of nmk_gpio_glitch_slpm_init casade. Fixes: 3a19805920f1 ("pinctrl: nomadik: move all Nomadik drivers to subdir") Signed-off-by: Mingwei Zheng <[email protected]> Signed-off-by: Jiasheng Jiang <[email protected]> Link: https://lore.kernel.org/[email protected] Signed-off-by: Linus Walleij <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Christophe JAILLET <[email protected]> Date: Sun Nov 17 13:03:32 2024 +0100 pinctrl: samsung: Fix irq handling if an error occurs in exynos_irq_demux_eint16_31() [ Upstream commit f686a2b52e9d78cf401f1b7f446bf0c3a81ebcc0 ] chained_irq_enter(() should be paired with a corresponding chained_irq_exit(). Here, if clk_enable() fails, a early return occurs and chained_irq_exit() is not called. Add a new label and a goto for fix it. Fixes: f9c744747973 ("pinctrl: samsung: support a bus clock") Signed-off-by: Christophe JAILLET <[email protected]> Reviewed-by: André Draszik <[email protected]> Link: https://lore.kernel.org/r/f148d823acfb3326a115bd49a0eed60f2345f909.1731844995.git.christophe.jaillet@wanadoo.fr Signed-off-by: Krzysztof Kozlowski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Mingwei Zheng <[email protected]> Date: Mon Jan 6 17:06:59 2025 -0500 pinctrl: stm32: Add check for clk_enable() [ Upstream commit 451bc9aea9a1a6fe53969e81a5cb1bd785c0d989 ] Convert the driver to clk_bulk*() API. Add check for the return value of clk_bulk_enable() to catch the potential error. Fixes: 05d8af449d93 ("pinctrl: stm32: Keep pinctrl block clock enabled when LEVEL IRQ requested") Signed-off-by: Mingwei Zheng <[email protected]> Signed-off-by: Jiasheng Jiang <[email protected]> Reviewed-by: Antonio Borneo <[email protected]> Link: https://lore.kernel.org/[email protected] Signed-off-by: Linus Walleij <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Pei Xiao <[email protected]> Date: Wed Nov 20 15:51:39 2024 +0800 platform/mellanox: mlxbf-pmc: incorrect type in assignment [ Upstream commit b5dbb8e23cb334460acdb37910ce3784926e1cf1 ] Fix sparse warnings: expected 'void __iomem *addr', but got 'void *addr' Reported-by: kernel test robot <[email protected]> Closes: https://lore.kernel.org/oe-kbuild-all/[email protected]/ Fixes: 423c3361855c ("platform/mellanox: mlxbf-pmc: Add support for BlueField-3") Signed-off-by: Pei Xiao <[email protected]> Reviewed-by: David Thompson <[email protected]> Link: https://lore.kernel.org/r/fece26ad40620b1e0beb733b9bba3de3ce325761.1732088929.git.xiaopei01@kylinos.cn Reviewed-by: Ilpo Järvinen <[email protected]> Signed-off-by: Ilpo Järvinen <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Hans de Goede <[email protected]> Date: Wed Dec 4 21:42:12 2024 +0100 platform/x86: x86-android-tablets: Add missing __init to get_i2c_adap_by_*() [ Upstream commit 981fd70a5ac4347368fa8a3329b7d67f1c567ee7 ] get_i2c_adap_by_handle() and get_i2c_adap_by_pci_parent() both are only used by x86_instantiate_i2c_client() which is __init itself and in case of the latter it also uses match_parent() which is also __init. Fixes: 5b78e809f948 ("platform/x86: x86-android-tablets: Add support for getting i2c_adapter by PCI parent devname()") Reviewed-by: Andy Shevchenko <[email protected]> Signed-off-by: Hans de Goede <[email protected]> Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Ilpo Järvinen <[email protected]> Signed-off-by: Ilpo Järvinen <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Pei Xiao <[email protected]> Date: Thu Nov 21 11:55:34 2024 +0800 platform/x86: x86-android-tablets: make platform data be static [ Upstream commit 6e0fb1bdb71cf8078c8532617e565e3db22c0d3c ] make lenovo_yoga_tab2_1380_bq24190_pdata and lenovo_yoga_tab2_1380_modules to be static Reported-by: kernel test robot <[email protected]> Closes: https://lore.kernel.org/oe-kbuild-all/[email protected]/ Fixes: 3eee73ad42c3 ("platform/x86: x86-android-tablets: Add Lenovo Yoga Tablet 2 Pro 1380F/L data") Signed-off-by: Pei Xiao <[email protected]> Reviewed-by: Hans de Goede <[email protected]> Link: https://lore.kernel.org/r/daafd1371e7e9946217712ce8720e29cd5c52f7a.1732161310.git.xiaopei01@kylinos.cn Reviewed-by: Ilpo Järvinen <[email protected]> Signed-off-by: Ilpo Järvinen <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Hans de Goede <[email protected]> Date: Wed Dec 4 21:42:13 2024 +0100 platform/x86: x86-android-tablets: Make variables only used locally static [ Upstream commit f6728073baa172be6223512fffd72796de891536 ] Commit 06f876def346 ("platform/x86: x86-android-tablets: Add support for Vexia EDU ATLA 10 tablet") omitted the static keyword from some variables which are only used inside other.c . Add the missing static keyword to these, this fixes the following warnings: .../x86-android-tablets/other.c:605:12: sparse: sparse: symbol 'crystal_cove_pwrsrc_psy' was not declared. Should it be static? .../x86-android-tablets/other.c:612:28: sparse: sparse: symbol 'vexia_edu_atla10_ulpmc_node' was not declared. Should it be static? Fixes: 06f876def346 ("platform/x86: x86-android-tablets: Add support for Vexia EDU ATLA 10 tablet") Reported-by: kernel test robot <[email protected]> Closes: https://lore.kernel.org/oe-kbuild-all/[email protected]/ Signed-off-by: Hans de Goede <[email protected]> Reviewed-by: Andy Shevchenko <[email protected]> Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Ilpo Järvinen <[email protected]> Signed-off-by: Ilpo Järvinen <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Wentao Liang <[email protected]> Date: Sun Jan 19 22:32:05 2025 +0800 PM: hibernate: Add error handling for syscore_suspend() [ Upstream commit e20a70c572539a486dbd91b225fa6a194a5e2122 ] In hibernation_platform_enter(), the code did not check the return value of syscore_suspend(), potentially leading to a situation where syscore_resume() would be called even if syscore_suspend() failed. This could cause unpredictable behavior or system instability. Modify the code sequence in question to properly handle errors returned by syscore_suspend(). If an error occurs in the suspend path, the code now jumps to label 'Enable_irqs' skipping the syscore_resume() call and only enabling interrupts after setting the system state to SYSTEM_RUNNING. Fixes: 40dc166cb5dd ("PM / Core: Introduce struct syscore_ops for core subsystems PM") Signed-off-by: Wentao Liang <[email protected]> Link: https://patch.msgid.link/[email protected] [ rjw: Changelog edits ] Signed-off-by: Rafael J. Wysocki <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Sourabh Jain <[email protected]> Date: Tue Dec 17 13:16:40 2024 +0530 powerpc/book3s64/hugetlb: Fix disabling hugetlb when fadump is active [ Upstream commit d629d7a8efc33d05d62f4805c0ffb44727e3d99f ] Commit 8597538712eb ("powerpc/fadump: Do not use hugepages when fadump is active") disabled hugetlb support when fadump is active by returning early from hugetlbpage_init():arch/powerpc/mm/hugetlbpage.c and not populating hpage_shift/HPAGE_SHIFT. Later, commit 2354ad252b66 ("powerpc/mm: Update default hugetlb size early") moved the allocation of hpage_shift/HPAGE_SHIFT to early boot, which inadvertently re-enabled hugetlb support when fadump is active. Fix this by implementing hugepages_supported() on powerpc. This ensures that disabling hugetlb for the fadump kernel is independent of hpage_shift/HPAGE_SHIFT. Fixes: 2354ad252b66 ("powerpc/mm: Update default hugetlb size early") Reviewed-by: Ritesh Harjani (IBM) <[email protected]> Signed-off-by: Sourabh Jain <[email protected]> Signed-off-by: Madhavan Srinivasan <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Shivaprasad G Bhat <[email protected]> Date: Mon Jan 13 03:48:55 2025 +0000 powerpc/pseries/iommu: Don't unset window if it was never set commit 17391cb2613b82f8c405570fea605af3255ff8d2 upstream. On pSeries, when user attempts to use the same vfio container used by different iommu group, the spapr_tce_set_window() returns -EPERM and the subsequent cleanup leads to the below crash. Kernel attempted to read user page (308) - exploit attempt? BUG: Kernel NULL pointer dereference on read at 0x00000308 Faulting instruction address: 0xc0000000001ce358 Oops: Kernel access of bad area, sig: 11 [#1] NIP: c0000000001ce358 LR: c0000000001ce05c CTR: c00000000005add0 <snip> NIP [c0000000001ce358] spapr_tce_unset_window+0x3b8/0x510 LR [c0000000001ce05c] spapr_tce_unset_window+0xbc/0x510 Call Trace: spapr_tce_unset_window+0xbc/0x510 (unreliable) tce_iommu_attach_group+0x24c/0x340 [vfio_iommu_spapr_tce] vfio_container_attach_group+0xec/0x240 [vfio] vfio_group_fops_unl_ioctl+0x548/0xb00 [vfio] sys_ioctl+0x754/0x1580 system_call_exception+0x13c/0x330 system_call_vectored_common+0x15c/0x2ec <snip> --- interrupt: 3000 Fix this by having null check for the tbl passed to the spapr_tce_unset_window(). Fixes: f431a8cde7f1 ("powerpc/iommu: Reimplement the iommu_table_group_ops for pSeries") Cc: [email protected] Reported-by: Vaishnavi Bhat <[email protected]> Signed-off-by: Shivaprasad G Bhat <[email protected]> Signed-off-by: Madhavan Srinivasan <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Gaurav Batra <[email protected]> Date: Fri Dec 6 15:00:39 2024 -0600 powerpc/pseries/iommu: IOMMU incorrectly marks MMIO range in DDW [ Upstream commit 8f70caad82e9c088ed93b4fea48d941ab6441886 ] Power Hypervisor can possibily allocate MMIO window intersecting with Dynamic DMA Window (DDW) range, which is over 32-bit addressing. These MMIO pages needs to be marked as reserved so that IOMMU doesn't map DMA buffers in this range. The current code is not marking these pages correctly which is resulting in LPAR to OOPS while booting. The stack is at below BUG: Unable to handle kernel data access on read at 0xc00800005cd40000 Faulting instruction address: 0xc00000000005cdac Oops: Kernel access of bad area, sig: 11 [#1] LE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=2048 NUMA pSeries Modules linked in: af_packet rfkill ibmveth(X) lpfc(+) nvmet_fc nvmet nvme_keyring crct10dif_vpmsum nvme_fc nvme_fabrics nvme_core be2net(+) nvme_auth rtc_generic nfsd auth_rpcgss nfs_acl lockd grace sunrpc fuse configfs ip_tables x_tables xfs libcrc32c dm_service_time ibmvfc(X) scsi_transport_fc vmx_crypto gf128mul crc32c_vpmsum dm_mirror dm_region_hash dm_log dm_multipath dm_mod sd_mod scsi_dh_emc scsi_dh_rdac scsi_dh_alua t10_pi crc64_rocksoft_generic crc64_rocksoft sg crc64 scsi_mod Supported: Yes, External CPU: 8 PID: 241 Comm: kworker/8:1 Kdump: loaded Not tainted 6.4.0-150600.23.14-default #1 SLE15-SP6 b44ee71c81261b9e4bab5e0cde1f2ed891d5359b Hardware name: IBM,9080-M9S POWER9 (raw) 0x4e2103 0xf000005 of:IBM,FW950.B0 (VH950_149) hv:phyp pSeries Workqueue: events work_for_cpu_fn NIP: c00000000005cdac LR: c00000000005e830 CTR: 0000000000000000 REGS: c00001400c9ff770 TRAP: 0300 Not tainted (6.4.0-150600.23.14-default) MSR: 800000000280b033 <SF,VEC,VSX,EE,FP,ME,IR,DR,RI,LE> CR: 24228448 XER: 00000001 CFAR: c00000000005cdd4 DAR: c00800005cd40000 DSISR: 40000000 IRQMASK: 0 GPR00: c00000000005e830 c00001400c9ffa10 c000000001987d00 c00001400c4fe800 GPR04: 0000080000000000 0000000000000001 0000000004000000 0000000000800000 GPR08: 0000000004000000 0000000000000001 c00800005cd40000 ffffffffffffffff GPR12: 0000000084228882 c00000000a4c4f00 0000000000000010 0000080000000000 GPR16: c00001400c4fe800 0000000004000000 0800000000000000 c00000006088b800 GPR20: c00001401a7be980 c00001400eff3800 c000000002a2da68 000000000000002b GPR24: c0000000026793a8 c000000002679368 000000000000002a c0000000026793c8 GPR28: 000008007effffff 0000080000000000 0000000000800000 c00001400c4fe800 NIP [c00000000005cdac] iommu_table_reserve_pages+0xac/0x100 LR [c00000000005e830] iommu_init_table+0x80/0x1e0 Call Trace: [c00001400c9ffa10] [c00000000005e810] iommu_init_table+0x60/0x1e0 (unreliable) [c00001400c9ffa90] [c00000000010356c] iommu_bypass_supported_pSeriesLP+0x9cc/0xe40 [c00001400c9ffc30] [c00000000005c300] dma_iommu_dma_supported+0xf0/0x230 [c00001400c9ffcb0] [c00000000024b0c4] dma_supported+0x44/0x90 [c00001400c9ffcd0] [c00000000024b14c] dma_set_mask+0x3c/0x80 [c00001400c9ffd00] [c0080000555b715c] be_probe+0xc4/0xb90 [be2net] [c00001400c9ffdc0] [c000000000986f3c] local_pci_probe+0x6c/0x110 [c00001400c9ffe40] [c000000000188f28] work_for_cpu_fn+0x38/0x60 [c00001400c9ffe70] [c00000000018e454] process_one_work+0x314/0x620 [c00001400c9fff10] [c00000000018f280] worker_thread+0x2b0/0x620 [c00001400c9fff90] [c00000000019bb18] kthread+0x148/0x150 [c00001400c9fffe0] [c00000000000ded8] start_kernel_thread+0x14/0x18 There are 2 issues in the code 1. The index is "int" while the address is "unsigned long". This results in negative value when setting the bitmap. 2. The DMA offset is page shifted but the MMIO range is used as-is (64-bit address). MMIO address needs to be page shifted as well. Fixes: 3c33066a2190 ("powerpc/kernel/iommu: Add new iommu_table_in_use() helper") Signed-off-by: Gaurav Batra <[email protected]> Reviewed-by: Nilay Shroff <[email protected]> Signed-off-by: Madhavan Srinivasan <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Calvin Owens <[email protected]> Date: Mon Nov 11 20:13:29 2024 -0800 pps: Fix a use-after-free commit c79a39dc8d060b9e64e8b0fa9d245d44befeefbe upstream. On a board running ntpd and gpsd, I'm seeing a consistent use-after-free in sys_exit() from gpsd when rebooting: pps pps1: removed ------------[ cut here ]------------ kobject: '(null)' (00000000db4bec24): is not initialized, yet kobject_put() is being called. WARNING: CPU: 2 PID: 440 at lib/kobject.c:734 kobject_put+0x120/0x150 CPU: 2 UID: 299 PID: 440 Comm: gpsd Not tainted 6.11.0-rc6-00308-gb31c44928842 #1 Hardware name: Raspberry Pi 4 Model B Rev 1.1 (DT) pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : kobject_put+0x120/0x150 lr : kobject_put+0x120/0x150 sp : ffffffc0803d3ae0 x29: ffffffc0803d3ae0 x28: ffffff8042dc9738 x27: 0000000000000001 x26: 0000000000000000 x25: ffffff8042dc9040 x24: ffffff8042dc9440 x23: ffffff80402a4620 x22: ffffff8042ef4bd0 x21: ffffff80405cb600 x20: 000000000008001b x19: ffffff8040b3b6e0 x18: 0000000000000000 x17: 0000000000000000 x16: 0000000000000000 x15: 696e6920746f6e20 x14: 7369203a29343263 x13: 205d303434542020 x12: 0000000000000000 x11: 0000000000000000 x10: 0000000000000000 x9 : 0000000000000000 x8 : 0000000000000000 x7 : 0000000000000000 x6 : 0000000000000000 x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000000000 x2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000000000 Call trace: kobject_put+0x120/0x150 cdev_put+0x20/0x3c __fput+0x2c4/0x2d8 ____fput+0x1c/0x38 task_work_run+0x70/0xfc do_exit+0x2a0/0x924 do_group_exit+0x34/0x90 get_signal+0x7fc/0x8c0 do_signal+0x128/0x13b4 do_notify_resume+0xdc/0x160 el0_svc+0xd4/0xf8 el0t_64_sync_handler+0x140/0x14c el0t_64_sync+0x190/0x194 ---[ end trace 0000000000000000 ]--- ...followed by more symptoms of corruption, with similar stacks: refcount_t: underflow; use-after-free. kernel BUG at lib/list_debug.c:62! Kernel panic - not syncing: Oops - BUG: Fatal exception This happens because pps_device_destruct() frees the pps_device with the embedded cdev immediately after calling cdev_del(), but, as the comment above cdev_del() notes, fops for previously opened cdevs are still callable even after cdev_del() returns. I think this bug has always been there: I can't explain why it suddenly started happening every time I reboot this particular board. In commit d953e0e837e6 ("pps: Fix a use-after free bug when unregistering a source."), George Spelvin suggested removing the embedded cdev. That seems like the simplest way to fix this, so I've implemented his suggestion, using __register_chrdev() with pps_idr becoming the source of truth for which minor corresponds to which device. But now that pps_idr defines userspace visibility instead of cdev_add(), we need to be sure the pps->dev refcount can't reach zero while userspace can still find it again. So, the idr_remove() call moves to pps_unregister_cdev(), and pps_idr now holds a reference to pps->dev. pps_core: source serial1 got cdev (251:1) <...> pps pps1: removed pps_core: unregistering pps1 pps_core: deallocating pps1 Fixes: d953e0e837e6 ("pps: Fix a use-after free bug when unregistering a source.") Cc: [email protected] Signed-off-by: Calvin Owens <[email protected]> Reviewed-by: Michal Schmidt <[email protected]> Link: https://lore.kernel.org/r/a17975fd5ae99385791929e563f72564edbcf28f.1731383727.git.calvin@wbinvd.org Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: John Ogness <[email protected]> Date: Mon Dec 9 12:23:46 2024 +0106 printk: Defer legacy printing when holding printk_cpu_sync [ Upstream commit 0161e2d6950fe66cf6ac1c10d945bae971f33667 ] The documentation of printk_cpu_sync_get() clearly states that the owner must never perform any activities where it waits for a CPU. For legacy printing there can be spinning on the console_lock and on the port lock. Therefore legacy printing must be deferred when holding the printk_cpu_sync. Note that in the case of emergency states, atomic consoles are not prevented from printing when printk is deferred. This is appropriate because they do not spin-wait indefinitely for other CPUs. Reported-by: Rik van Riel <[email protected]> Closes: https://lore.kernel.org/r/[email protected] Signed-off-by: John Ogness <[email protected]> Fixes: 55d6af1d6688 ("lib/nmi_backtrace: explicitly serialize banner and regs") Reviewed-by: Petr Mladek <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Petr Mladek <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Geert Uytterhoeven <[email protected]> Date: Fri Jan 3 09:51:25 2025 +0100 ps3disk: Do not use dev->bounce_size before it is set [ Upstream commit c2398e6d5f16e15598d3a37e17107fea477e3f91 ] dev->bounce_size is only initialized after it is used to set the queue limits. Fix this by using BOUNCE_SIZE instead. Fixes: a7f18b74dbe17162 ("ps3disk: pass queue_limits to blk_mq_alloc_disk") Reported-by: Philipp Hortmann <[email protected]> Closes: https://lore.kernel.org/[email protected] Signed-off-by: Geert Uytterhoeven <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]> Link: https://lore.kernel.org/r/06988f959ea6885b8bd7fb3b9059dd54bc6bbad7.1735894216.git.geert+renesas@glider.be Signed-off-by: Jens Axboe <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Chengming Zhou <[email protected]> Date: Fri Dec 27 06:19:41 2024 +0000 psi: Fix race when task wakes up before psi_sched_switch() adjusts flags [ Upstream commit 7d9da040575b343085287686fa902a5b2d43c7ca ] When running hackbench in a cgroup with bandwidth throttling enabled, following PSI splat was observed: psi: inconsistent task state! task=1831:hackbench cpu=8 psi_flags=14 clear=0 set=4 When investigating the series of events leading up to the splat, following sequence was observed: [008] d..2.: sched_switch: ... ==> next_comm=hackbench next_pid=1831 next_prio=120 ... [008] dN.2.: dequeue_entity(task delayed): task=hackbench pid=1831 cfs_rq->throttled=0 [008] dN.2.: pick_task_fair: check_cfs_rq_runtime() throttled cfs_rq on CPU8 # CPU8 goes into newidle balance and releases the rq lock ... # CPU15 on same LLC Domain is trying to wakeup hackbench(pid=1831) [015] d..4.: psi_flags_change: psi: task state: task=1831:hackbench cpu=8 psi_flags=14 clear=0 set=4 final=14 # Splat (cfs_rq->throttled=1) [015] d..4.: sched_wakeup: comm=hackbench pid=1831 prio=120 target_cpu=008 # Task has woken on a throttled hierarchy [008] d..2.: sched_switch: prev_comm=hackbench prev_pid=1831 prev_prio=120 prev_state=S ==> ... psi_dequeue() relies on psi_sched_switch() to set the correct PSI flags for the blocked entity, however, with the introduction of DELAY_DEQUEUE, the block task can wakeup when newidle balance drops the runqueue lock during __schedule(). If a task wakes before psi_sched_switch() adjusts the PSI flags, skip any modifications in psi_enqueue() which would still see the flags of a running task and not a blocked one. Instead, rely on psi_sched_switch() to do the right thing. Since the status returned by try_to_block_task() may no longer be true by the time schedule reaches psi_sched_switch(), check if the task is blocked or not using a combination of task_on_rq_queued() and p->se.sched_delayed checks. [ prateek: Commit message, testing, early bailout in psi_enqueue() ] Fixes: 152e11f6df29 ("sched/fair: Implement delayed dequeue") # 1a6151017ee5 Signed-off-by: Chengming Zhou <[email protected]> Signed-off-by: K Prateek Nayak <[email protected]> Signed-off-by: Peter Zijlstra (Intel) <[email protected]> Reviewed-by: Chengming Zhou <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Eugen Hristev <[email protected]> Date: Wed Jan 1 13:19:21 2025 +0200 pstore/blk: trivial typo fixes [ Upstream commit 542243af7182efaeaf6d0f4643f7de437541a9af ] Fix trivial typos in comments. Fixes: 2a03ddbde1e1 ("pstore/blk: Move verify_size() macro out of function") Fixes: 17639f67c1d6 ("pstore/blk: Introduce backend for block devices") Signed-off-by: Eugen Hristev <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Kees Cook <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Thomas Weißschuh <[email protected]> Date: Sat Jan 25 10:28:38 2025 +0100 ptp: Properly handle compat ioctls [ Upstream commit 19ae40f572a9ce1ade9954990af709a03fd37010 ] Pointer arguments passed to ioctls need to pass through compat_ptr() to work correctly on s390; as explained in Documentation/driver-api/ioctl.rst. Detect compat mode at runtime and call compat_ptr() for those commands which do take pointer arguments. Suggested-by: Arnd Bergmann <[email protected]> Link: https://lore.kernel.org/lkml/[email protected]/ Fixes: d94ba80ebbea ("ptp: Added a brand new class driver for ptp clocks.") Signed-off-by: Thomas Weißschuh <[email protected]> Reviewed-by: Cyrill Gorcunov <[email protected]> Reviewed-by: Arnd Bergmann <[email protected]> Acked-by: Richard Cochran <[email protected]> Link: https://patch.msgid.link/20250125-posix-clock-compat_ioctl-v2-1-11c865c500eb@weissschuh.net Signed-off-by: Paolo Abeni <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Eric Dumazet <[email protected]> Date: Tue Dec 17 13:51:21 2024 +0000 ptr_ring: do not block hard interrupts in ptr_ring_resize_multiple() [ Upstream commit a126061c80d5efb4baef4bcf346094139cd81df6 ] Jakub added a lockdep_assert_no_hardirq() check in __page_pool_put_page() to increase test coverage. syzbot found a splat caused by hard irq blocking in ptr_ring_resize_multiple() [1] As current users of ptr_ring_resize_multiple() do not require hard irqs being masked, replace it to only block BH. Rename helpers to better reflect they are safe against BH only. - ptr_ring_resize_multiple() to ptr_ring_resize_multiple_bh() - skb_array_resize_multiple() to skb_array_resize_multiple_bh() [1] WARNING: CPU: 1 PID: 9150 at net/core/page_pool.c:709 __page_pool_put_page net/core/page_pool.c:709 [inline] WARNING: CPU: 1 PID: 9150 at net/core/page_pool.c:709 page_pool_put_unrefed_netmem+0x157/0xa40 net/core/page_pool.c:780 Modules linked in: CPU: 1 UID: 0 PID: 9150 Comm: syz.1.1052 Not tainted 6.11.0-rc3-syzkaller-00202-gf8669d7b5f5d #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 RIP: 0010:__page_pool_put_page net/core/page_pool.c:709 [inline] RIP: 0010:page_pool_put_unrefed_netmem+0x157/0xa40 net/core/page_pool.c:780 Code: 74 0e e8 7c aa fb f7 eb 43 e8 75 aa fb f7 eb 3c 65 8b 1d 38 a8 6a 76 31 ff 89 de e8 a3 ae fb f7 85 db 74 0b e8 5a aa fb f7 90 <0f> 0b 90 eb 1d 65 8b 1d 15 a8 6a 76 31 ff 89 de e8 84 ae fb f7 85 RSP: 0018:ffffc9000bda6b58 EFLAGS: 00010083 RAX: ffffffff8997e523 RBX: 0000000000000000 RCX: 0000000000040000 RDX: ffffc9000fbd0000 RSI: 0000000000001842 RDI: 0000000000001843 RBP: 0000000000000000 R08: ffffffff8997df2c R09: 1ffffd40003a000d R10: dffffc0000000000 R11: fffff940003a000e R12: ffffea0001d00040 R13: ffff88802e8a4000 R14: dffffc0000000000 R15: 00000000ffffffff FS: 00007fb7aaf716c0(0000) GS:ffff8880b9300000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fa15a0d4b72 CR3: 00000000561b0000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> tun_ptr_free drivers/net/tun.c:617 [inline] __ptr_ring_swap_queue include/linux/ptr_ring.h:571 [inline] ptr_ring_resize_multiple_noprof include/linux/ptr_ring.h:643 [inline] tun_queue_resize drivers/net/tun.c:3694 [inline] tun_device_event+0xaaf/0x1080 drivers/net/tun.c:3714 notifier_call_chain+0x19f/0x3e0 kernel/notifier.c:93 call_netdevice_notifiers_extack net/core/dev.c:2032 [inline] call_netdevice_notifiers net/core/dev.c:2046 [inline] dev_change_tx_queue_len+0x158/0x2a0 net/core/dev.c:9024 do_setlink+0xff6/0x41f0 net/core/rtnetlink.c:2923 rtnl_setlink+0x40d/0x5a0 net/core/rtnetlink.c:3201 rtnetlink_rcv_msg+0x73f/0xcf0 net/core/rtnetlink.c:6647 netlink_rcv_skb+0x1e3/0x430 net/netlink/af_netlink.c:2550 Fixes: ff4e538c8c3e ("page_pool: add a lockdep check for recycling in hardirq") Reported-by: [email protected] Closes: https://lore.kernel.org/netdev/[email protected]/T/ Signed-off-by: Eric Dumazet <[email protected]> Acked-by: Michael S. Tsirkin <[email protected]> Acked-by: Jason Wang <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Uwe Kleine-König <[email protected]> Date: Thu Jan 23 18:27:07 2025 +0100 pwm: Ensure callbacks exist before calling them commit da6b353786997c0ffa67127355ad1d54ed3324c2 upstream. If one of the waveform functions is called for a chip that only supports .apply(), we want that an error code is returned and not a NULL pointer exception. Fixes: 6c5126c6406d ("pwm: Provide new consumer API functions for waveforms") Cc: [email protected] Signed-off-by: Uwe Kleine-König <[email protected]> Tested-by: Trevor Gamblin <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Uwe Kleine-König <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Mingwei Zheng <[email protected]> Date: Fri Dec 6 16:53:18 2024 -0500 pwm: stm32-lp: Add check for clk_enable() [ Upstream commit cce16e7f6216227964cda25f5f23634bce2c500f ] Add check for the return value of clk_enable() to catch the potential error. We used APP-Miner to find it. Fixes: e70a540b4e02 ("pwm: Add STM32 LPTimer PWM driver") Signed-off-by: Mingwei Zheng <[email protected]> Signed-off-by: Jiasheng Jiang <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Uwe Kleine-König <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Mingwei Zheng <[email protected]> Date: Sun Dec 15 17:47:52 2024 -0500 pwm: stm32: Add check for clk_enable() [ Upstream commit e8c59791ebb60790c74b2c3ab520f04a8a57219a ] Add check for the return value of clk_enable() to catch the potential error. Fixes: 19f1016ea960 ("pwm: stm32: Fix enable count for clk in .probe()") Signed-off-by: Mingwei Zheng <[email protected]> Signed-off-by: Jiasheng Jiang <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Uwe Kleine-König <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Kalesh AP <[email protected]> Date: Sat Jan 4 11:45:19 2025 +0530 RDMA/bnxt_re: Fix to drop reference to the mmap entry in case of error [ Upstream commit c84f0f4f49d81645f49c3269fdcc3b84ce61e795 ] In the error handling path of bnxt_re_mmap(), driver should invoke rdma_user_mmap_entry_put() to free the reference of mmap entry in case the error happens after rdma_user_mmap_entry_get was called. Fixes: ea2224857882 ("RDMA/bnxt_re: Update alloc_page uapi for pacing") Reviewed-by: Saravanan Vajravel <[email protected]> Reviewed-by: Kashyap Desai <[email protected]> Signed-off-by: Kalesh AP <[email protected]> Signed-off-by: Selvin Xavier <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Leon Romanovsky <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Anumula Murali Mohan Reddy <[email protected]> Date: Tue Jan 7 15:20:53 2025 +0530 RDMA/cxgb4: Notify rdma stack for IB_EVENT_QP_LAST_WQE_REACHED event [ Upstream commit 42e6ddda4c17fa0d5120e3723d522649f8fc62fa ] This patch sends IB_EVENT_QP_LAST_WQE_REACHED event on a QP that is in error state and associated with an SRQ. This behaviour is incorporated in flush_qp() which is called when QP transitions to error state. Supports SRQ drain functionality added by commit 844bc12e6da3 ("IB/core: add support for draining Shared receive queues") Fixes: 844bc12e6da3 ("IB/core: add support for draining Shared receive queues") Signed-off-by: Anumula Murali Mohan Reddy <[email protected]> Signed-off-by: Potnuri Bharat Teja <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Leon Romanovsky <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Dan Carpenter <[email protected]> Date: Sat Nov 30 13:01:37 2024 +0300 rdma/cxgb4: Prevent potential integer overflow on 32bit [ Upstream commit bd96a3935e89486304461a21752f824fc25e0f0b ] The "gl->tot_len" variable is controlled by the user. It comes from process_responses(). On 32bit systems, the "gl->tot_len + sizeof(struct cpl_pass_accept_req) + sizeof(struct rss_header)" addition could have an integer wrapping bug. Use size_add() to prevent this. Fixes: 1cab775c3e75 ("RDMA/cxgb4: Fix LE hash collision bug for passive open connection") Link: https://patch.msgid.link/r/[email protected] Signed-off-by: Dan Carpenter <[email protected]> Signed-off-by: Jason Gunthorpe <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Junxian Huang <[email protected]> Date: Mon Jan 6 19:12:11 2025 +0800 RDMA/hns: Clean up the legacy CONFIG_INFINIBAND_HNS [ Upstream commit 8977b561216c7e693d61c6442657e33f134bfeb5 ] hns driver used to support hip06 and hip08 devices with CONFIG_INFINIBAND_HNS_HIP06 and CONFIG_INFINIBAND_HNS_HIP08 respectively, which both depended on CONFIG_INFINIBAND_HNS. But we no longer provide support for hip06 and only support hip08 and higher since the commit in fixes line, so there is no need to have CONFIG_INFINIBAND_HNS any more. Remove it and only keep CONFIG_INFINIBAND_HNS_HIP08. Fixes: 38d220882426 ("RDMA/hns: Remove support for HIP06") Signed-off-by: Junxian Huang <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Leon Romanovsky <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Leon Romanovsky <[email protected]> Date: Tue Dec 3 15:44:25 2024 +0200 RDMA/mlx4: Avoid false error about access to uninitialized gids array [ Upstream commit 1f53d88cbb0dcc7df235bf6611ae632b254fccd8 ] Smatch generates the following false error report: drivers/infiniband/hw/mlx4/main.c:393 mlx4_ib_del_gid() error: uninitialized symbol 'gids'. Traditionally, we are not changing kernel code and asking people to fix the tools. However in this case, the fix can be done by simply rearranging the code to be more clear. Fixes: e26be1bfef81 ("IB/mlx4: Implement ib_device callbacks") Link: https://patch.msgid.link/6a3a1577463da16962463fcf62883a87506e9b62.1733233426.git.leonro@nvidia.com Signed-off-by: Leon Romanovsky <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Patrisious Haddad <[email protected]> Date: Sun Jan 19 10:21:41 2025 +0200 RDMA/mlx5: Fix implicit ODP use after free commit d3d930411ce390e532470194296658a960887773 upstream. Prevent double queueing of implicit ODP mr destroy work by using __xa_cmpxchg() to make sure this is the only time we are destroying this specific mr. Without this change, we could try to invalidate this mr twice, which in turn could result in queuing a MR work destroy twice, and eventually the second work could execute after the MR was freed due to the first work, causing a user after free and trace below. refcount_t: underflow; use-after-free. WARNING: CPU: 2 PID: 12178 at lib/refcount.c:28 refcount_warn_saturate+0x12b/0x130 Modules linked in: bonding ib_ipoib vfio_pci ip_gre geneve nf_tables ip6_gre gre ip6_tunnel tunnel6 ipip tunnel4 ib_umad rdma_ucm mlx5_vfio_pci vfio_pci_core vfio_iommu_type1 mlx5_ib vfio ib_uverbs mlx5_core iptable_raw openvswitch nsh rpcrdma ib_iser libiscsi scsi_transport_iscsi rdma_cm iw_cm ib_cm ib_core xt_conntrack xt_MASQUERADE nf_conntrack_netlink nfnetlink xt_addrtype iptable_nat nf_nat br_netfilter rpcsec_gss_krb5 auth_rpcgss oid_registry overlay zram zsmalloc fuse [last unloaded: ib_uverbs] CPU: 2 PID: 12178 Comm: kworker/u20:5 Not tainted 6.5.0-rc1_net_next_mlx5_58c644e #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 Workqueue: events_unbound free_implicit_child_mr_work [mlx5_ib] RIP: 0010:refcount_warn_saturate+0x12b/0x130 Code: 48 c7 c7 38 95 2a 82 c6 05 bc c6 fe 00 01 e8 0c 66 aa ff 0f 0b 5b c3 48 c7 c7 e0 94 2a 82 c6 05 a7 c6 fe 00 01 e8 f5 65 aa ff <0f> 0b 5b c3 90 8b 07 3d 00 00 00 c0 74 12 83 f8 01 74 13 8d 50 ff RSP: 0018:ffff8881008e3e40 EFLAGS: 00010286 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000027 RDX: ffff88852c91b5c8 RSI: 0000000000000001 RDI: ffff88852c91b5c0 RBP: ffff8881dacd4e00 R08: 00000000ffffffff R09: 0000000000000019 R10: 000000000000072e R11: 0000000063666572 R12: ffff88812bfd9e00 R13: ffff8881c792d200 R14: ffff88810011c005 R15: ffff8881002099c0 FS: 0000000000000000(0000) GS:ffff88852c900000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f5694b5e000 CR3: 00000001153f6003 CR4: 0000000000370ea0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> ? refcount_warn_saturate+0x12b/0x130 free_implicit_child_mr_work+0x180/0x1b0 [mlx5_ib] process_one_work+0x1cc/0x3c0 worker_thread+0x218/0x3c0 kthread+0xc6/0xf0 ret_from_fork+0x1f/0x30 </TASK> Fixes: 5256edcb98a1 ("RDMA/mlx5: Rework implicit ODP destroy") Cc: [email protected] Link: https://patch.msgid.link/r/c96b8645a81085abff739e6b06e286a350d1283d.1737274283.git.leon@kernel.org Signed-off-by: Patrisious Haddad <[email protected]> Signed-off-by: Leon Romanovsky <[email protected]> Signed-off-by: Jason Gunthorpe <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Michael Guralnik <[email protected]> Date: Mon Jan 6 20:27:10 2025 +0200 RDMA/mlx5: Fix indirect mkey ODP page count [ Upstream commit 235f238402194a78ac5fb882a46717eac817e5d1 ] Restrict the check for the number of pages handled during an ODP page fault to direct mkeys. Perform the check right after handling the page fault and don't propagate the number of handled pages to callers. Indirect mkeys and their associated direct mkeys can have different start addresses. As a result, the calculation of the number of pages to handle for an indirect mkey may not match the actual page fault handling done on the direct mkey. For example: A 4K sized page fault on a KSM mkey that has a start address that is not aligned to a page will result a calculation that assumes the number of pages required to handle are 2. While the underlying MTT might be aligned will require fetching only a single page. Thus, do the calculation and compare number of pages handled only per direct mkey. Fixes: db570d7deafb ("IB/mlx5: Add ODP support to MW") Signed-off-by: Michael Guralnik <[email protected]> Reviewed-by: Artemy Kovalyov <[email protected]> Link: https://patch.msgid.link/86c483d9e75ce8fe14e9ff85b62df72b779f8ab1.1736187990.git.leon@kernel.org Signed-off-by: Leon Romanovsky <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Li Zhijian <[email protected]> Date: Mon Jan 6 08:45:16 2025 +0800 RDMA/rtrs: Add missing deinit() call [ Upstream commit 81468c4058a62e84e475433b83b3edc613294f5e ] A warning is triggered when repeatedly connecting and disconnecting the rnbd: list_add corruption. prev->next should be next (ffff88800b13e480), but was ffff88801ecd1338. (prev=ffff88801ecd1340). WARNING: CPU: 1 PID: 36562 at lib/list_debug.c:32 __list_add_valid_or_report+0x7f/0xa0 Workqueue: ib_cm cm_work_handler [ib_cm] RIP: 0010:__list_add_valid_or_report+0x7f/0xa0 ? __list_add_valid_or_report+0x7f/0xa0 ib_register_event_handler+0x65/0x93 [ib_core] rtrs_srv_ib_dev_init+0x29/0x30 [rtrs_server] rtrs_ib_dev_find_or_add+0x124/0x1d0 [rtrs_core] __alloc_path+0x46c/0x680 [rtrs_server] ? rtrs_rdma_connect+0xa6/0x2d0 [rtrs_server] ? rcu_is_watching+0xd/0x40 ? __mutex_lock+0x312/0xcf0 ? get_or_create_srv+0xad/0x310 [rtrs_server] ? rtrs_rdma_connect+0xa6/0x2d0 [rtrs_server] rtrs_rdma_connect+0x23c/0x2d0 [rtrs_server] ? __lock_release+0x1b1/0x2d0 cma_cm_event_handler+0x4a/0x1a0 [rdma_cm] cma_ib_req_handler+0x3a0/0x7e0 [rdma_cm] cm_process_work+0x28/0x1a0 [ib_cm] ? _raw_spin_unlock_irq+0x2f/0x50 cm_req_handler+0x618/0xa60 [ib_cm] cm_work_handler+0x71/0x520 [ib_cm] Commit 667db86bcbe8 ("RDMA/rtrs: Register ib event handler") introduced a new element .deinit but never used it at all. Fix it by invoking the `deinit()` to appropriately unregister the IB event handler. Cc: Jinpu Wang <[email protected]> Fixes: 667db86bcbe8 ("RDMA/rtrs: Register ib event handler") Signed-off-by: Li Zhijian <[email protected]> Link: https://patch.msgid.link/[email protected] Acked-by: Jack Wang <[email protected]> Signed-off-by: Leon Romanovsky <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: zhenwei pi <[email protected]> Date: Mon Dec 16 20:19:53 2024 +0800 RDMA/rxe: Fix mismatched max_msg_sz [ Upstream commit db03b70969aab4ef111a3369cfd90ea4da3a6aa0 ] User mode queries max_msg_sz as 0x800000 by command 'ibv_devinfo -v', however ibv_post_send/ibv_post_recv has a limit of 2^31. Fix this mismatched information. Signed-off-by: zhenwei pi <[email protected]> Fixes: f605f26ea196 ("RDMA/rxe: Protect QP state with qp->state_lock") Fixes: 5bf944f24129 ("RDMA/rxe: Add error messages") Link: https://patch.msgid.link/[email protected] Review-by: Zhu Yanjun <[email protected]> Signed-off-by: Leon Romanovsky <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Zhu Yanjun <[email protected]> Date: Fri Jan 10 17:09:27 2025 +0100 RDMA/rxe: Fix the warning "__rxe_cleanup+0x12c/0x170 [rdma_rxe]" [ Upstream commit edc4ef0e0154096d6c0cf5e06af6fc330dbad9d1 ] The Call Trace is as below: " <TASK> ? show_regs.cold+0x1a/0x1f ? __rxe_cleanup+0x12c/0x170 [rdma_rxe] ? __warn+0x84/0xd0 ? __rxe_cleanup+0x12c/0x170 [rdma_rxe] ? report_bug+0x105/0x180 ? handle_bug+0x46/0x80 ? exc_invalid_op+0x19/0x70 ? asm_exc_invalid_op+0x1b/0x20 ? __rxe_cleanup+0x12c/0x170 [rdma_rxe] ? __rxe_cleanup+0x124/0x170 [rdma_rxe] rxe_destroy_qp.cold+0x24/0x29 [rdma_rxe] ib_destroy_qp_user+0x118/0x190 [ib_core] rdma_destroy_qp.cold+0x43/0x5e [rdma_cm] rtrs_cq_qp_destroy.cold+0x1d/0x2b [rtrs_core] rtrs_srv_close_work.cold+0x1b/0x31 [rtrs_server] process_one_work+0x21d/0x3f0 worker_thread+0x4a/0x3c0 ? process_one_work+0x3f0/0x3f0 kthread+0xf0/0x120 ? kthread_complete_and_exit+0x20/0x20 ret_from_fork+0x22/0x30 </TASK> " When too many rdma resources are allocated, rxe needs more time to handle these rdma resources. Sometimes with the current timeout, rxe can not release the rdma resources correctly. Compared with other rdma drivers, a bigger timeout is used. Fixes: 215d0a755e1b ("RDMA/rxe: Stop lookup of partially built objects") Signed-off-by: Zhu Yanjun <[email protected]> Link: https://patch.msgid.link/[email protected] Tested-by: Joe Klein <[email protected]> Signed-off-by: Leon Romanovsky <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Ma Ke <[email protected]> Date: Tue Dec 17 15:55:38 2024 +0800 RDMA/srp: Fix error handling in srp_add_port [ Upstream commit a3cbf68c69611188cd304229e346bffdabfd4277 ] As comment of device_add() says, if device_add() succeeds, you should call device_del() when you want to get rid of it. If device_add() has not succeeded, use only put_device() to drop the reference count. Add a put_device() call before returning from the function to decrement reference count for cleanup. Found by code review. Fixes: c8e4c2397655 ("RDMA/srp: Rework the srp_add_port() error path") Signed-off-by: Ma Ke <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Bart Van Assche <[email protected]> Signed-off-by: Leon Romanovsky <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Alexander Stein <[email protected]> Date: Wed Jan 22 08:20:19 2025 +0100 regulator: core: Add missing newline character [ Upstream commit 155c569fa4c3b340fbf8571a0e42dd415c025377 ] dev_err_probe() error messages need newline character. Fixes: 6eabfc018e8d ("regulator: core: Allow specifying an initial load w/ the bulk API") Signed-off-by: Alexander Stein <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Chen-Yu Tsai <[email protected]> Date: Wed Dec 11 13:24:19 2024 +0800 regulator: dt-bindings: mt6315: Drop regulator-compatible property [ Upstream commit 08242719a8af603db54a2a79234a8fe600680105 ] The "regulator-compatible" property has been deprecated since 2012 in commit 13511def87b9 ("regulator: deprecate regulator-compatible DT property"), which is so old it's not even mentioned in the converted regulator bindings YAML file. It should not have been used for new submissions such as the MT6315. Drop the property from the MT6315 regulator binding and its examples. Fixes: 977fb5b58469 ("regulator: document binding for MT6315 regulator") Fixes: 6d435a94ba5b ("regulator: mt6315: Enforce regulator-compatible, not name") Signed-off-by: Chen-Yu Tsai <[email protected]> Reviewed-by: AngeloGioacchino Del Regno <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Joe Hattori <[email protected]> Date: Sat Jan 4 17:04:53 2025 +0900 regulator: of: Implement the unwind path of of_regulator_match() [ Upstream commit dddca3b2fc676113c58b04aaefe84bfb958ac83e ] of_regulator_match() does not release the OF node reference in the error path, resulting in an OF node leak. Therefore, call of_node_put() on the obtained nodes before returning the EINVAL error. Since it is possible that some drivers call this function and do not exit on failure, such as s2mps11_pmic_driver, clear the init_data and of_node in the error path. This was reported by an experimental verification tool that I am developing. As I do not have access to actual devices nor the QEMU board configuration to test drivers that call this function, no runtime test was able to be performed. Fixes: 1c8fa58f4750 ("regulator: Add generic DT parsing for regulators") Signed-off-by: Joe Hattori <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Arnaud Pouliquen <[email protected]> Date: Fri Nov 22 18:51:27 2024 +0100 remoteproc: core: Fix ida_free call while not allocated commit 7378aeb664e5ebc396950b36a1f2dedf5aabec20 upstream. In the rproc_alloc() function, on error, put_device(&rproc->dev) is called, leading to the call of the rproc_type_release() function. An error can occurs before ida_alloc is called. In such case in rproc_type_release(), the condition (rproc->index >= 0) is true as rproc->index has been initialized to 0. ida_free() is called reporting a warning: [ 4.181906] WARNING: CPU: 1 PID: 24 at lib/idr.c:525 ida_free+0x100/0x164 [ 4.186378] stm32-display-dsi 5a000000.dsi: Fixed dependency cycle(s) with /soc/dsi@5a000000/panel@0 [ 4.188854] ida_free called for id=0 which is not allocated. [ 4.198256] mipi-dsi 5a000000.dsi.0: Fixed dependency cycle(s) with /soc/dsi@5a000000 [ 4.203556] Modules linked in: panel_orisetech_otm8009a dw_mipi_dsi_stm(+) gpu_sched dw_mipi_dsi stm32_rproc stm32_crc32 stm32_ipcc(+) optee(+) [ 4.224307] CPU: 1 UID: 0 PID: 24 Comm: kworker/u10:0 Not tainted 6.12.0 #442 [ 4.231481] Hardware name: STM32 (Device Tree Support) [ 4.236627] Workqueue: events_unbound deferred_probe_work_func [ 4.242504] Call trace: [ 4.242522] unwind_backtrace from show_stack+0x10/0x14 [ 4.250218] show_stack from dump_stack_lvl+0x50/0x64 [ 4.255274] dump_stack_lvl from __warn+0x80/0x12c [ 4.260134] __warn from warn_slowpath_fmt+0x114/0x188 [ 4.265199] warn_slowpath_fmt from ida_free+0x100/0x164 [ 4.270565] ida_free from rproc_type_release+0x38/0x60 [ 4.275832] rproc_type_release from device_release+0x30/0xa0 [ 4.281601] device_release from kobject_put+0xc4/0x294 [ 4.286762] kobject_put from rproc_alloc.part.0+0x208/0x28c [ 4.292430] rproc_alloc.part.0 from devm_rproc_alloc+0x80/0xc4 [ 4.298393] devm_rproc_alloc from stm32_rproc_probe+0xd0/0x844 [stm32_rproc] [ 4.305575] stm32_rproc_probe [stm32_rproc] from platform_probe+0x5c/0xbc Calling ida_alloc earlier in rproc_alloc ensures that the rproc->index is properly set. Fixes: 08333b911f01 ("remoteproc: Directly use ida_alloc()/free()") Signed-off-by: Arnaud Pouliquen <[email protected]> Cc: [email protected] Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mathieu Poirier <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Chen-Yu Tsai <[email protected]> Date: Wed Dec 11 15:20:07 2024 +0800 remoteproc: mtk_scp: Only populate devices for SCP cores [ Upstream commit dbb9c372555c0b2a5a9264418bfba6d017752808 ] When multi-core SCP support was added, the driver was made to populate platform devices for all the sub-nodes. This ended up adding platform devices for the rpmsg sub-nodes as well, which never actually get used, since rpmsg devices are registered through the rpmsg interface. Limit of_platform_populate() to just populating the SCP cores with a compatible string match list. Fixes: 1fdbf0cdde98 ("remoteproc: mediatek: Probe SCP cluster on multi-core SCP") Cc: Tinghan Shen <[email protected]> Signed-off-by: Chen-Yu Tsai <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mathieu Poirier <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Chuck Lever <[email protected]> Date: Thu Jan 2 20:00:01 2025 -0500 Revert "SUNRPC: Reduce thread wake-up rate when receiving large RPC messages" commit 966a675da844f1a764bb44557c21561cc3d09840 upstream. I noticed that a handful of NFSv3 fstests were taking an unexpectedly long time to run. Troubleshooting showed that the server's TCP window closed and never re-opened, which caused the client to trigger an RPC retransmit timeout after 180 seconds. The client's recovery action was to establish a fresh connection and retransmit the timed-out requests. This worked, but it adds a long delay. I tracked the problem to the commit that attempted to reduce the rate at which the network layer delivers TCP socket data_ready callbacks. Under most circumstances this change worked as expected, but for NFSv3, which has no session or other type of throttling, it can overwhelm the receiver on occasion. I'm sure I could tweak the lowat settings, but the small benefit doesn't seem worth the bother. Just revert it. Fixes: 2b877fc53e97 ("SUNRPC: Reduce thread wake-up rate when receiving large RPC messages") Cc: Jakub Kicinski <[email protected]> Reviewed-by: Jeff Layton <[email protected]> Signed-off-by: Chuck Lever <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Breno Leitao <[email protected]> Date: Thu Nov 28 04:16:25 2024 -0800 rhashtable: Fix potential deadlock by moving schedule_work outside lock [ Upstream commit e1d3422c95f003eba241c176adfe593c33e8a8f6 ] Move the hash table growth check and work scheduling outside the rht lock to prevent a possible circular locking dependency. The original implementation could trigger a lockdep warning due to a potential deadlock scenario involving nested locks between rhashtable bucket, rq lock, and dsq lock. By relocating the growth check and work scheduling after releasing the rth lock, we break this potential deadlock chain. This change expands the flexibility of rhashtable by removing restrictive locking that previously limited its use in scheduler and workqueue contexts. Import to say that this calls rht_grow_above_75(), which reads from struct rhashtable without holding the lock, if this is a problem, we can move the check to the lock, and schedule the workqueue after the lock. Fixes: f0e1a0643a59 ("sched_ext: Implement BPF extensible scheduler class") Suggested-by: Tejun Heo <[email protected]> Signed-off-by: Breno Leitao <[email protected]> Modified so that atomic_inc is also moved outside of the bucket lock along with the growth above 75% check. Signed-off-by: Herbert Xu <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Herbert Xu <[email protected]> Date: Tue Jan 14 11:15:19 2025 +0800 rhashtable: Fix rhashtable_try_insert test [ Upstream commit 9d4f8e54cef2c42e23ef258833dbd06a1eaff89b ] The test on whether rhashtable_insert_one did an insertion relies on the value returned by rhashtable_lookup_one. Unfortunately that value is overwritten after rhashtable_insert_one returns. Fix this by moving the test before data gets overwritten. Simplify the test as only data == NULL matters. Finally move atomic_inc back within the lock as otherwise it may be reordered with the atomic_dec on the removal side, potentially leading to an underflow. Reported-by: Michael Kelley <[email protected]> Fixes: e1d3422c95f0 ("rhashtable: Fix potential deadlock by moving schedule_work outside lock") Signed-off-by: Herbert Xu <[email protected]> Tested-by: Michael Kelley <[email protected]> Reviewed-by: Breno Leitao <[email protected]> Tested-by: Mikhail Zaslonko <[email protected]> Signed-off-by: Herbert Xu <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Palmer Dabbelt <[email protected]> Date: Wed Jan 15 10:02:51 2025 -0800 RISC-V: Mark riscv_v_init() as __init [ Upstream commit 9d87cf525fd2e1a5fcbbb40ee3df216d1d266c88 ] This trips up with Xtheadvector enabled, but as far as I can tell it's just been an issue since the original patchset. Fixes: 7ca7a7b9b635 ("riscv: Add sysctl to set the default vector rule for new processes") Reviewed-by: Charlie Jenkins <[email protected]> Tested-by: Charlie Jenkins <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Palmer Dabbelt <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Ming Wang <[email protected]> Date: Thu Dec 5 19:43:07 2024 +0800 rtc: loongson: clear TOY_MATCH0_REG in loongson_rtc_isr() [ Upstream commit 09471d8f5b390883eaf21b917c4bf3ced1b8a1df ] The TOY_MATCH0_REG should be cleared to 0 in the RTC interrupt handler, otherwise the interrupt cannot be cleared, which will cause the loongson_rtc_isr() to be triggered multiple times. The previous code cleared TOY_MATCH0_REG in the loongson_rtc_handler(), which is an ACPI interrupt. This did not prevent loongson_rtc_isr() from being triggered multiple times. This commit moves the clearing of TOY_MATCH0_REG to the loongson_rtc_isr() to ensure that the interrupt is properly cleared. Fixes: 1b733a9ebc3d ("rtc: Add rtc driver for the Loongson family chips") Signed-off-by: Ming Wang <[email protected]> Reviewed-by: Huacai Chen <[email protected]> Reviewed-by: Keguang Zhang <[email protected]> # on LS1B Tested-by: Keguang Zhang <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Alexandre Belloni <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Oleksij Rempel <[email protected]> Date: Wed Dec 18 20:34:58 2024 +0100 rtc: pcf85063: fix potential OOB write in PCF85063 NVMEM read [ Upstream commit 3ab8c5ed4f84fa20cd16794fe8dc31f633fbc70c ] The nvmem interface supports variable buffer sizes, while the regmap interface operates with fixed-size storage. If an nvmem client uses a buffer size less than 4 bytes, regmap_read will write out of bounds as it expects the buffer to point at an unsigned int. Fix this by using an intermediary unsigned int to hold the value. Fixes: fadfd092ee91 ("rtc: pcf85063: add nvram support") Signed-off-by: Oleksij Rempel <[email protected]> Signed-off-by: Ahmad Fatoum <[email protected]> Link: https://lore.kernel.org/r/20241218-rtc-pcf85063-stack-corruption-v1-1-12fd0ee0f046@pengutronix.de Signed-off-by: Alexandre Belloni <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Dan Carpenter <[email protected]> Date: Wed Dec 11 12:32:34 2024 +0300 rtc: tps6594: Fix integer overflow on 32bit systems [ Upstream commit 09c4a610153286cef54d4f0c85398f4e32fc227e ] The problem is this multiply in tps6594_rtc_set_offset() tmp = offset * TICKS_PER_HOUR; The "tmp" variable is an s64 but "offset" is a long in the (-277774)-277774 range. On 32bit systems a long can hold numbers up to approximately two billion. The number of TICKS_PER_HOUR is really large, (32768 * 3600) or roughly a hundred million. When you start multiplying by a hundred million it doesn't take long to overflow the two billion mark. Probably the safest way to fix this is to change the type of TICKS_PER_HOUR to long long because it's such a large number. Fixes: 9f67c1e63976 ("rtc: tps6594: Add driver for TPS6594 RTC") Signed-off-by: Dan Carpenter <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Alexandre Belloni <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: David Howells <[email protected]> Date: Thu Jan 23 08:59:12 2025 +0000 rxrpc, afs: Fix peer hash locking vs RCU callback [ Upstream commit 79d458c13056559d49b5e41fbc4b6890e68cf65b ] In its address list, afs now retains pointers to and refs on one or more rxrpc_peer objects. The address list is freed under RCU and at this time, it puts the refs on those peers. Now, when an rxrpc_peer object runs out of refs, it gets removed from the peer hash table and, for that, rxrpc has to take a spinlock. However, it is now being called from afs's RCU cleanup, which takes place in BH context - but it is just taking an ordinary spinlock. The put may also be called from non-BH context, and so there exists the possibility of deadlock if the BH-based RCU cleanup happens whilst the hash spinlock is held. This led to the attached lockdep complaint. Fix this by changing spinlocks of rxnet->peer_hash_lock back to BH-disabling locks. ================================ WARNING: inconsistent lock state 6.13.0-rc5-build2+ #1223 Tainted: G E -------------------------------- inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage. swapper/1/0 [HC0[0]:SC1[1]:HE1:SE0] takes: ffff88810babe228 (&rxnet->peer_hash_lock){+.?.}-{3:3}, at: rxrpc_put_peer+0xcb/0x180 {SOFTIRQ-ON-W} state was registered at: mark_usage+0x164/0x180 __lock_acquire+0x544/0x990 lock_acquire.part.0+0x103/0x280 _raw_spin_lock+0x2f/0x40 rxrpc_peer_keepalive_worker+0x144/0x440 process_one_work+0x486/0x7c0 process_scheduled_works+0x73/0x90 worker_thread+0x1c8/0x2a0 kthread+0x19b/0x1b0 ret_from_fork+0x24/0x40 ret_from_fork_asm+0x1a/0x30 irq event stamp: 972402 hardirqs last enabled at (972402): [<ffffffff8244360e>] _raw_spin_unlock_irqrestore+0x2e/0x50 hardirqs last disabled at (972401): [<ffffffff82443328>] _raw_spin_lock_irqsave+0x18/0x60 softirqs last enabled at (972300): [<ffffffff810ffbbe>] handle_softirqs+0x3ee/0x430 softirqs last disabled at (972313): [<ffffffff810ffc54>] __irq_exit_rcu+0x44/0x110 other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(&rxnet->peer_hash_lock); <Interrupt> lock(&rxnet->peer_hash_lock); *** DEADLOCK *** 1 lock held by swapper/1/0: #0: ffffffff83576be0 (rcu_callback){....}-{0:0}, at: rcu_lock_acquire+0x7/0x30 stack backtrace: CPU: 1 UID: 0 PID: 0 Comm: swapper/1 Tainted: G E 6.13.0-rc5-build2+ #1223 Tainted: [E]=UNSIGNED_MODULE Hardware name: ASUS All Series/H97-PLUS, BIOS 2306 10/09/2014 Call Trace: <IRQ> dump_stack_lvl+0x57/0x80 print_usage_bug.part.0+0x227/0x240 valid_state+0x53/0x70 mark_lock_irq+0xa5/0x2f0 mark_lock+0xf7/0x170 mark_usage+0xe1/0x180 __lock_acquire+0x544/0x990 lock_acquire.part.0+0x103/0x280 _raw_spin_lock+0x2f/0x40 rxrpc_put_peer+0xcb/0x180 afs_free_addrlist+0x46/0x90 [kafs] rcu_do_batch+0x2d2/0x640 rcu_core+0x2f7/0x350 handle_softirqs+0x1ee/0x430 __irq_exit_rcu+0x44/0x110 irq_exit_rcu+0xa/0x30 sysvec_apic_timer_interrupt+0x7f/0xa0 </IRQ> Fixes: 72904d7b9bfb ("rxrpc, afs: Allow afs to pin rxrpc_peer objects") Signed-off-by: David Howells <[email protected]> cc: Marc Dionne <[email protected]> cc: Simon Horman <[email protected]> cc: [email protected] Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: David Howells <[email protected]> Date: Wed Dec 4 07:46:30 2024 +0000 rxrpc: Fix handling of received connection abort [ Upstream commit 0e56ebde245e4799ce74d38419426f2a80d39950 ] Fix the handling of a connection abort that we've received. Though the abort is at the connection level, it needs propagating to the calls on that connection. Whilst the propagation bit is performed, the calls aren't then woken up to go and process their termination, and as no further input is forthcoming, they just hang. Also add some tracing for the logging of connection aborts. Fixes: 248f219cb8bc ("rxrpc: Rewrite the data and ack handling code") Signed-off-by: David Howells <[email protected]> cc: Marc Dionne <[email protected]> cc: [email protected] Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Vasily Gorbik <[email protected]> Date: Fri Nov 29 01:49:26 2024 +0100 s390/mm: Allow large pages for KASAN shadow mapping [ Upstream commit e70452c4ba2ce1e24a3fdc18bd623edb7b56013c ] Commit c98d2ecae08f ("s390/mm: Uncouple physical vs virtual address spaces") introduced a large_allowed() helper that restricts which mapping modes can use large pages. This change unintentionally prevented KASAN shadow mappings from using large pages, despite there being no reason to avoid them. In fact, large pages are preferred for performance. Since commit d8073dc6bc04 ("s390/mm: Allow large pages only for aligned physical addresses"), both can_large_pud() and can_large_pmd() call _pa() to check if large page physical addresses are aligned. However, _pa() has a side effect: it allocates memory in POPULATE_KASAN_MAP_SHADOW mode. Rename large_allowed() to large_page_mapping_allowed() and add POPULATE_KASAN_MAP_SHADOW to the allowed list to restore large page mappings for KASAN shadows. While large_page_mapping_allowed() isn't strictly necessary with current mapping modes since disallowed modes either don't map anything or fail alignment and size checks, keep it for clarity. Rename _pa() to resolve_pa_may_alloc() for clarity and to emphasize existing side effect. Rework can_large_pud()/can_large_pmd() to take the side effect into consideration and actually return physical address instead of just checking conditions. Fixes: c98d2ecae08f ("s390/mm: Uncouple physical vs virtual address spaces") Reviewed-by: Alexander Gordeev <[email protected]> Signed-off-by: Vasily Gorbik <[email protected]> Signed-off-by: Alexander Gordeev <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Heiko Carstens <[email protected]> Date: Mon Jan 20 11:53:42 2025 +0100 s390/sclp: Initialize sclp subsystem via arch_cpu_finalize_init() [ Upstream commit 3bcc8a1af581af152d43e42b53db3534018301b5 ] With the switch to GENERIC_CPU_DEVICES an early call to the sclp subsystem was added to smp_prepare_cpus(). This will usually succeed since the sclp subsystem is implicitly initialized early enough if an sclp based console is present. If no such console is present the initialization happens with an arch_initcall(); in such cases calls to the sclp subsystem will fail. For CPU detection this means that the fallback sigp loop will be used permanently to detect CPUs instead of the preferred READ_CPU_INFO sclp request. Fix this by adding an explicit early sclp_init() call via arch_cpu_finalize_init(). Reported-by: Sheshu Ramanandan <[email protected]> Fixes: 4a39f12e753d ("s390/smp: Switch to GENERIC_CPU_DEVICES") Reviewed-by: Peter Oberparleiter <[email protected]> Signed-off-by: Heiko Carstens <[email protected]> Signed-off-by: Alexander Gordeev <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Nathan Chancellor <[email protected]> Date: Wed Jan 22 19:54:27 2025 -0700 s390: Add '-std=gnu11' to decompressor and purgatory CFLAGS commit 3b8b80e993766dc96d1a1c01c62f5d15fafc79b9 upstream. GCC changed the default C standard dialect from gnu17 to gnu23, which should not have impacted the kernel because it explicitly requests the gnu11 standard in the main Makefile. However, there are certain places in the s390 code that use their own CFLAGS without a '-std=' value, which break with this dialect change because of the kernel's own definitions of bool, false, and true conflicting with the C23 reserved keywords. include/linux/stddef.h:11:9: error: cannot use keyword 'false' as enumeration constant 11 | false = 0, | ^~~~~ include/linux/stddef.h:11:9: note: 'false' is a keyword with '-std=c23' onwards include/linux/types.h:35:33: error: 'bool' cannot be defined via 'typedef' 35 | typedef _Bool bool; | ^~~~ include/linux/types.h:35:33: note: 'bool' is a keyword with '-std=c23' onwards Add '-std=gnu11' to the decompressor and purgatory CFLAGS to eliminate these errors and make the C standard version of these areas match the rest of the kernel. Cc: [email protected] Signed-off-by: Nathan Chancellor <[email protected]> Tested-by: Heiko Carstens <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Alexander Gordeev <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Zichen Xie <[email protected]> Date: Wed Nov 27 21:29:56 2024 -0600 samples/landlock: Fix possible NULL dereference in parse_path() [ Upstream commit 078bf9438a31567e2c0587159ccefde835fb1ced ] malloc() may return NULL, leading to NULL dereference. Add a NULL check. Fixes: ba84b0bf5a16 ("samples/landlock: Add a sandbox manager example") Signed-off-by: Zichen Xie <[email protected]> Link: https://lore.kernel.org/r/[email protected] [mic: Simplify fix] Signed-off-by: Mickaël Salaün <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Peter Zijlstra <[email protected]> Date: Fri Dec 20 06:32:19 2024 +0000 sched/fair: Fix value reported by hot tasks pulled in /proc/schedstat [ Upstream commit a430d99e349026d53e2557b7b22bd2ebd61fe12a ] In /proc/schedstat, lb_hot_gained reports the number hot tasks pulled during load balance. This value is incremented in can_migrate_task() if the task is migratable and hot. After incrementing the value, load balancer can still decide not to migrate this task leading to wrong accounting. Fix this by incrementing stats when hot tasks are detached. This issue only exists in detach_tasks() where we can decide to not migrate hot task even if it is migratable. However, in detach_one_task(), we migrate it unconditionally. [Swapnil: Handled the case where nr_failed_migrations_hot was not accounted properly and wrote commit log] Fixes: d31980846f96 ("sched: Move up affinity check to mitigate useless redoing overhead") Signed-off-by: Peter Zijlstra (Intel) <[email protected]> Reported-by: "Gautham R. Shenoy" <[email protected]> Not-yet-signed-off-by: Peter Zijlstra <[email protected]> Signed-off-by: Swapnil Sapkal <[email protected]> Signed-off-by: Peter Zijlstra (Intel) <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Peter Zijlstra <[email protected]> Date: Fri Nov 29 11:15:41 2024 +0100 sched/fair: Untangle NEXT_BUDDY and pick_next_task() [ Upstream commit 2a77e4be12cb58bbf774e7c717c8bb80e128b7a4 ] There are 3 sites using set_next_buddy() and only one is conditional on NEXT_BUDDY, the other two sites are unconditional; to note: - yield_to_task() - cgroup dequeue / pick optimization However, having NEXT_BUDDY control both the wakeup-preemption and the picking side of things means its near useless. Fixes: 147f3efaa241 ("sched/fair: Implement an EEVDF-like scheduling policy") Signed-off-by: Peter Zijlstra (Intel) <[email protected]> Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Tianchen Ding <[email protected]> Date: Tue Dec 31 13:50:20 2024 +0800 sched: Fix race between yield_to() and try_to_wake_up() [ Upstream commit 5d808c78d97251af1d3a3e4f253e7d6c39fd871e ] We met a SCHED_WARN in set_next_buddy(): __warn_printk set_next_buddy yield_to_task_fair yield_to kvm_vcpu_yield_to [kvm] ... After a short dig, we found the rq_lock held by yield_to() may not be exactly the rq that the target task belongs to. There is a race window against try_to_wake_up(). CPU0 target_task blocking on CPU1 lock rq0 & rq1 double check task_rq == p_rq, ok woken to CPU2 (lock task_pi & rq2) task_rq = rq2 yield_to_task_fair (w/o lock rq2) In this race window, yield_to() is operating the task w/o the correct lock. Fix this by taking task pi_lock first. Fixes: d95f41220065 ("sched: Add yield_to(task, preempt) functionality") Signed-off-by: Tianchen Ding <[email protected]> Signed-off-by: Peter Zijlstra (Intel) <[email protected]> Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Andrea Righi <[email protected]> Date: Wed Nov 20 15:29:03 2024 +0100 sched_ext: Use the NUMA scheduling domain for NUMA optimizations [ Upstream commit 4572541892ea4e1dade2e9c1313d3f8069d37f0a ] Rely on the NUMA scheduling domain topology, instead of accessing NUMA topology information directly. There is basically no functional change, but in this way we ensure consistent use of the same topology information determined by the scheduling subsystem. Fixes: f6ce6b949304 ("sched_ext: Do not enable LLC/NUMA optimizations when domains overlap") Signed-off-by: Andrea Righi <[email protected]> Signed-off-by: Tejun Heo <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Guixin Liu <[email protected]> Date: Tue Jan 7 10:20:32 2025 +0800 scsi: mpi3mr: Fix possible crash when setting up bsg fails [ Upstream commit 295006f6e8c17212d3098811166e29627d19e05c ] If bsg_setup_queue() fails, the bsg_queue is assigned a non-NULL value. Consequently, in mpi3mr_bsg_exit(), the condition "if(!mrioc->bsg_queue)" will not be satisfied, preventing execution from entering bsg_remove_queue(), which could lead to the following crash: BUG: kernel NULL pointer dereference, address: 000000000000041c Call Trace: <TASK> mpi3mr_bsg_exit+0x1f/0x50 [mpi3mr] mpi3mr_remove+0x6f/0x340 [mpi3mr] pci_device_remove+0x3f/0xb0 device_release_driver_internal+0x19d/0x220 unbind_store+0xa4/0xb0 kernfs_fop_write_iter+0x11f/0x200 vfs_write+0x1fc/0x3e0 ksys_write+0x67/0xe0 do_syscall_64+0x38/0x80 entry_SYSCALL_64_after_hwframe+0x78/0xe2 Fixes: 4268fa751365 ("scsi: mpi3mr: Add bsg device support") Signed-off-by: Guixin Liu <[email protected]> Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Bart Van Assche <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Paul Menzel <[email protected]> Date: Thu Dec 12 23:18:12 2024 +0100 scsi: mpt3sas: Set ioc->manu_pg11.EEDPTagMode directly to 1 [ Upstream commit ad7c3c0cb8f61d6d5a48b83e62ca4a9fd2f26153 ] Currently, the code does: if (x == 0) { x &= ~0x3; x |= 0x1; } Zeroing bits 0 and 1 of a variable that is 0 is not necessary. So directly set the variable to 1. Cc: Sreekanth Reddy <[email protected]> Fixes: f92363d12359 ("[SCSI] mpt3sas: add new driver supporting 12GB SAS") Signed-off-by: Paul Menzel <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Martin K. Petersen <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Guixin Liu <[email protected]> Date: Wed Dec 18 09:42:13 2024 +0800 scsi: ufs: bsg: Delete bsg_dev when setting up bsg fails [ Upstream commit fcf247deb3c3e1c6be5774e3fa03bbd018eff1a9 ] We should remove the bsg device when bsg_setup_queue() fails to release the resources. Fixes: df032bf27a41 ("scsi: ufs: Add a bsg endpoint that supports UPIUs") Signed-off-by: Guixin Liu <[email protected]> Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Avri Altman <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Christophe Leroy <[email protected]> Date: Mon Jan 13 09:37:24 2025 +0100 select: Fix unbalanced user_access_end() [ Upstream commit 344af27715ddbf357cf76978d674428b88f8e92d ] While working on implementing user access validation on powerpc I got the following warnings on a pmac32_defconfig build: CC fs/select.o fs/select.o: warning: objtool: sys_pselect6+0x1bc: redundant UACCESS disable fs/select.o: warning: objtool: sys_pselect6_time32+0x1bc: redundant UACCESS disable On powerpc/32s, user_read_access_begin/end() are no-ops, but the failure path has a user_access_end() instead of user_read_access_end() which means an access end without any prior access begin. Replace that user_access_end() by user_read_access_end(). Fixes: 7e71609f64ec ("pselect6() and friends: take handling the combined 6th/7th args into helper") Signed-off-by: Christophe Leroy <[email protected]> Link: https://lore.kernel.org/r/a7139e28d767a13e667ee3c79599a8047222ef36.1736751221.git.christophe.leroy@csgroup.eu Signed-off-by: Christian Brauner <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Song Yoong Siang <[email protected]> Date: Thu Dec 5 12:42:58 2024 +0800 selftests/bpf: Actuate tx_metadata_len in xdp_hw_metadata [ Upstream commit 0bee36d1a51366fa57b731f8975f26f92943b43e ] set XDP_UMEM_TX_METADATA_LEN flag to reserve tx_metadata_len bytes of per-chunk metadata. Fixes: d5e726d9143c ("xsk: Require XDP_UMEM_TX_METADATA_LEN to actuate tx_metadata_len") Signed-off-by: Song Yoong Siang <[email protected]> Signed-off-by: Martin KaFai Lau <[email protected]> Acked-by: Stanislav Fomichev <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Jiayuan Chen <[email protected]> Date: Tue Dec 24 15:59:57 2024 +0800 selftests/bpf: Avoid generating untracked files when running bpf selftests [ Upstream commit 73b9075f334f5debf28646884a320b796b27768d ] Currently, when we run the BPF selftests with the following command: make -C tools/testing/selftests TARGETS=bpf SKIP_TARGETS="" The command generates untracked files and directories with make version less than 4.4: ''' Untracked files: (use "git add <file>..." to include in what will be committed) tools/testing/selftests/bpfFEATURE-DUMP.selftests tools/testing/selftests/bpffeature/ ''' We lost slash after word "bpf". The reason is slash appending code is as follow: ''' OUTPUT := $(OUTPUT)/ $(eval include ../../../build/Makefile.feature) OUTPUT := $(patsubst %/,%,$(OUTPUT)) ''' This way of assigning values to OUTPUT will never be effective for the variable OUTPUT provided via the command argument [1] and BPF makefile is called from parent Makfile(tools/testing/selftests/Makefile) like: ''' all: ... $(MAKE) OUTPUT=$$BUILD_TARGET -C $$TARGET ''' According to GNU make, we can use override Directive to fix this issue [2]. [1] https://www.gnu.org/software/make/manual/make.html#Overriding [2] https://www.gnu.org/software/make/manual/make.html#Override-Directive Fixes: dc3a8804d790 ("selftests/bpf: Adapt OUTPUT appending logic to lower versions of Make") Signed-off-by: Jiayuan Chen <[email protected]> Signed-off-by: Daniel Borkmann <[email protected]> Acked-by: Jiri Olsa <[email protected]> Link: https://lore.kernel.org/bpf/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Pu Lehui <[email protected]> Date: Wed Jan 15 10:02:38 2025 +0000 selftests/bpf: Fix btf leak on new btf alloc failure in btf_distill test [ Upstream commit 4a04cb326a6c7f9a2c066f8c2ca78a5a9b87ddab ] Fix btf leak on new btf alloc failure in btf_distill test. Fixes: affdeb50616b ("selftests/bpf: Extend distilled BTF tests to cover BTF relocation") Signed-off-by: Pu Lehui <[email protected]> Signed-off-by: Andrii Nakryiko <[email protected]> Link: https://lore.kernel.org/bpf/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Saket Kumar Bhaskar <[email protected]> Date: Mon Dec 9 12:27:20 2024 +0530 selftests/bpf: Fix fill_link_info selftest on powerpc [ Upstream commit 4d33dc1bc31df80356c49e40dbd3ddff19500bcb ] With CONFIG_KPROBES_ON_FTRACE enabled on powerpc, ftrace_location_range returns ftrace location for bpf_fentry_test1 at offset of 4 bytes from function entry. This is because branch to _mcount function is at offset of 4 bytes in function profile sequence. To fix this, add entry_offset of 4 bytes while verifying the address for kprobe entry address of bpf_fentry_test1 in verify_perf_link_info in selftest, when CONFIG_KPROBES_ON_FTRACE is enabled. Disassemble of bpf_fentry_test1: c000000000e4b080 <bpf_fentry_test1>: c000000000e4b080: a6 02 08 7c mflr r0 c000000000e4b084: b9 e2 22 4b bl c00000000007933c <_mcount> c000000000e4b088: 01 00 63 38 addi r3,r3,1 c000000000e4b08c: b4 07 63 7c extsw r3,r3 c000000000e4b090: 20 00 80 4e blr When CONFIG_PPC_FTRACE_OUT_OF_LINE [1] is enabled, these function profile sequence is moved out of line with an unconditional branch at offset 0. So, the test works without altering the offset for 'CONFIG_KPROBES_ON_FTRACE && CONFIG_PPC_FTRACE_OUT_OF_LINE' case. Disassemble of bpf_fentry_test1: c000000000f95190 <bpf_fentry_test1>: c000000000f95190: 00 00 00 60 nop c000000000f95194: 01 00 63 38 addi r3,r3,1 c000000000f95198: b4 07 63 7c extsw r3,r3 c000000000f9519c: 20 00 80 4e blr [1] https://lore.kernel.org/all/[email protected]/ Fixes: 23cf7aa539dc ("selftests/bpf: Add selftest for fill_link_info") Signed-off-by: Saket Kumar Bhaskar <[email protected]> Signed-off-by: Andrii Nakryiko <[email protected]> Link: https://lore.kernel.org/bpf/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Tony Ambardar <[email protected]> Date: Wed Jan 15 23:50:36 2025 -0800 selftests/bpf: Fix undefined UINT_MAX in veristat.c [ Upstream commit a8d1c48d0720140b53063ff23507845bb2078e92 ] Include <limits.h> in 'veristat.c' to provide a UINT_MAX definition and avoid multiple compile errors against mips64el/musl-libc: veristat.c: In function 'max_verifier_log_size': veristat.c:1135:36: error: 'UINT_MAX' undeclared (first use in this function) 1135 | const int SMALL_LOG_SIZE = UINT_MAX >> 8; | ^~~~~~~~ veristat.c:24:1: note: 'UINT_MAX' is defined in header '<limits.h>'; did you forget to '#include <limits.h>'? 23 | #include <math.h> +++ |+#include <limits.h> 24 | Fixes: 1f7c33630724 ("selftests/bpf: Increase verifier log limit in veristat") Signed-off-by: Tony Ambardar <[email protected]> Signed-off-by: Andrii Nakryiko <[email protected]> Link: https://lore.kernel.org/bpf/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Masami Hiramatsu (Google) <[email protected]> Date: Tue Jan 7 21:11:07 2025 +0900 selftests/ftrace: Fix to use remount when testing mount GID option commit 159ca65c42d90d5ab98fc31b708b12c0be2c26e0 upstream. Fix mount_options.tc to use remount option to mount the tracefs. Since the current implementation does not umount the tracefs, this test always fails because of -EBUSY error. Using remount option will allow us to change the mount option. Link: https://lore.kernel.org/r/173625186741.1383744.16707876180798573039.stgit@devnote2 Fixes: 8b55572e5180 ("tracing/selftests: Add tracefs mount options test") Signed-off-by: Masami Hiramatsu (Google) <[email protected]> Cc: [email protected] Signed-off-by: Shuah Khan <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Mickaël Salaün <[email protected]> Date: Wed Jan 15 15:54:07 2025 +0100 selftests/landlock: Fix build with non-default pthread linking [ Upstream commit 0e4db4f843c2c0115b5981bd6f6b75dea62e7d60 ] Old toolchains require explicit -lpthread (e.g. on Debian 11). Cc: Nathan Chancellor <[email protected]> Cc: Tahera Fahimi <[email protected]> Fixes: c8994965013e ("selftests/landlock: Test signal scoping for threads") Reviewed-by: Günther Noack <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mickaël Salaün <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Mickaël Salaün <[email protected]> Date: Wed Jan 8 16:43:28 2025 +0100 selftests/landlock: Fix error message [ Upstream commit 2107c35128ad751b201eb92fe91443450d9e5c37 ] The global variable errno may not be set in test_execute(). Do not use it in related error message. Cc: Günther Noack <[email protected]> Fixes: e1199815b47b ("selftests/landlock: Add user space tests") Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mickaël Salaün <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Kevin Brodsky <[email protected]> Date: Mon Dec 9 09:50:10 2024 +0000 selftests/mm: build with -O2 commit 46036188ea1f5266df23a6149dea0df1c77cd1c7 upstream. The mm kselftests are currently built with no optimisation (-O0). It's unclear why, and besides being obviously suboptimal, this also prevents the pkeys tests from working as intended. Let's build all the tests with -O2. [[email protected]: silence unused-result warnings] Link: https://lkml.kernel.org/r/[email protected] Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Kevin Brodsky <[email protected]> Cc: Aruna Ramakrishna <[email protected]> Cc: Catalin Marinas <[email protected]> Cc: Dave Hansen <[email protected]> Cc: Joey Gouly <[email protected]> Cc: Keith Lucas <[email protected]> Cc: Ryan Roberts <[email protected]> Cc: Shuah Khan <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Michael Ellerman <[email protected]> Date: Wed Dec 18 22:43:47 2024 +1100 selftests/powerpc: Fix argument order to timer_sub() [ Upstream commit 2bf66e66d2e6feece6175ec09ec590a0a8563bdd ] Commit c814bf958926 ("powerpc/selftests: Use timersub() for gettimeofday()"), got the order of arguments to timersub() wrong, leading to a negative time delta being reported, eg: test: gettimeofday tags: git_version:v6.12-rc5-409-gdddf291c3030 time = -3.297781 success: gettimeofday The correct order is minuend, subtrahend, which in this case is end, start. Which gives: test: gettimeofday tags: git_version:v6.12-rc5-409-gdddf291c3030-dirty time = 3.300650 success: gettimeofday Fixes: c814bf958926 ("powerpc/selftests: Use timersub() for gettimeofday()") Signed-off-by: Michael Ellerman <[email protected]> Signed-off-by: Madhavan Srinivasan <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Mathieu Desnoyers <[email protected]> Date: Tue Jan 14 09:51:32 2025 -0500 selftests/rseq: Fix handling of glibc without rseq support commit 336d02bc4c6bec5c3d933e5d470a94970f830957 upstream. When porting librseq commit: commit c7b45750fa85 ("Adapt to glibc __rseq_size feature detection") from librseq to the kernel selftests, the following line was missed at the end of rseq_init(): rseq_size = get_rseq_kernel_feature_size(); which effectively leaves rseq_size initialized to -1U when glibc does not have rseq support. glibc supports rseq from version 2.35 onwards. In a following librseq commit commit c67d198627c2 ("Only set 'rseq_size' on first thread registration") to mimic the libc behavior, a new approach is taken: don't set the feature size in 'rseq_size' until at least one thread has successfully registered. This allows using 'rseq_size' in fast-paths to test for both registration status and available features. The caveat is that on libc either all threads are registered or none are, while with bare librseq it is the responsability of the user to register all threads using rseq. This combines the changes from the following librseq git commits: commit c7b45750fa85 ("Adapt to glibc __rseq_size feature detection") commit c67d198627c2 ("Only set 'rseq_size' on first thread registration") Fixes: a0cc649353bb ("selftests/rseq: Fix mm_cid test failure") Reported-by: Raghavendra Rao Ananta <[email protected]> Signed-off-by: Mathieu Desnoyers <[email protected]> Cc: Raghavendra Rao Ananta <[email protected]> Cc: Shuah Khan <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Boqun Feng <[email protected]> Cc: "Paul E. McKenney" <[email protected]> Cc: Carlos O'Donell <[email protected]> Cc: Florian Weimer <[email protected]> Cc: Michael Jeanson <[email protected]> Cc: [email protected] Cc: [email protected] Signed-off-by: Shuah Khan <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Dmitry V. Levin <[email protected]> Date: Wed Jan 8 19:07:57 2025 +0200 selftests: harness: fix printing of mismatch values in __EXPECT() [ Upstream commit 02bc220dc6dc7c56edc4859bc5dd2c08b95d5fb5 ] intptr_t and uintptr_t are not big enough types on 32-bit architectures when printing 64-bit values, resulting to the following incorrect diagnostic output: # get_syscall_info.c:209:get_syscall_info:Expected exp_args[2] (3134324433) == info.entry.args[1] (3134324433) Replace intptr_t and uintptr_t with intmax_t and uintmax_t, respectively. With this fix, the same test produces more usable diagnostic output: # get_syscall_info.c:209:get_syscall_info:Expected exp_args[2] (3134324433) == info.entry.args[1] (18446744072548908753) Link: https://lore.kernel.org/r/[email protected] Fixes: b5bb6d3068ea ("selftests/seccomp: fix 32-bit build warnings") Signed-off-by: Dmitry V. Levin <[email protected]> Reviewed-by: Kees Cook <[email protected]> Signed-off-by: Shuah Khan <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Mickaël Salaün <[email protected]> Date: Thu Dec 12 18:42:21 2024 +0100 selftests: ktap_helpers: Fix uninitialized variable [ Upstream commit 3e707b07f582c12ed78fa5516a97bf701bf0634c ] __ktap_test() may be called without the optional third argument which is an issue for scripts using `set -u` to detect uninitialized variables and potential bugs. Fix this optional "directive" argument by either using the third argument or an empty string. This is required for the next commit to properly test script execution control. Cc: Kees Cook <[email protected]> Cc: Nícolas F. R. A. Prado <[email protected]> Cc: Shuah Khan <[email protected]> Fixes: 14571ab1ad21 ("kselftest: Add new test for detecting unprobed Devicetree devices") Signed-off-by: Mickaël Salaün <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Kees Cook <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Jan Stancek <[email protected]> Date: Thu Jan 23 09:35:42 2025 +0100 selftests: mptcp: extend CFLAGS to keep options from environment [ Upstream commit 23b3a7c4a7583eac9e3976355928a832c87caa0f ] Package build environments like Fedora rpmbuild introduced hardening options (e.g. -pie -Wl,-z,now) by passing a -spec option to CFLAGS and LDFLAGS. mptcp Makefile currently overrides CFLAGS but not LDFLAGS, which leads to a mismatch and build failure, for example: make[1]: *** [../../lib.mk:222: tools/testing/selftests/net/mptcp/mptcp_sockopt] Error 1 /usr/bin/ld: /tmp/ccqyMVdb.o: relocation R_X86_64_32 against `.rodata.str1.8' can not be used when making a PIE object; recompile with -fPIE /usr/bin/ld: failed to set dynamic section sizes: bad value collect2: error: ld returned 1 exit status Fixes: cc937dad85ae ("selftests: centralize -D_GNU_SOURCE= to CFLAGS in lib.mk") Signed-off-by: Jan Stancek <[email protected]> Reviewed-by: Hangbin Liu <[email protected]> Reviewed-by: Matthieu Baerts (NGI0) <[email protected]> Link: https://patch.msgid.link/7abc701da9df39c2d6cd15bc3cf9e6cee445cb96.1737621162.git.jstancek@redhat.com Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Jan Stancek <[email protected]> Date: Thu Jan 23 13:38:51 2025 +0100 selftests: net/{lib,openvswitch}: extend CFLAGS to keep options from environment [ Upstream commit 9b06d5b956131bde535f5c045cf8c1ff6bfba76c ] Package build environments like Fedora rpmbuild introduced hardening options (e.g. -pie -Wl,-z,now) by passing a -spec option to CFLAGS and LDFLAGS. Some Makefiles currently override CFLAGS but not LDFLAGS, which leads to a mismatch and build failure, for example: /usr/bin/ld: /tmp/ccd2apay.o: relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a PIE object; recompile with -fPIE /usr/bin/ld: failed to set dynamic section sizes: bad value collect2: error: ld returned 1 exit status make[1]: *** [../../lib.mk:222: tools/testing/selftests/net/lib/csum] Error 1 openvswitch/Makefile CFLAGS currently do not appear to be used, but fix it anyway for the case when new tests are introduced in future. Fixes: 1d0dc857b5d8 ("selftests: drv-net: add checksum tests") Signed-off-by: Jan Stancek <[email protected]> Acked-by: Matthieu Baerts (NGI0) <[email protected]> Reviewed-by: Hangbin Liu <[email protected]> Link: https://patch.msgid.link/3d173603ee258f419d0403363765c9f9494ff79a.1737635092.git.jstancek@redhat.com Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Geert Uytterhoeven <[email protected]> Date: Thu Dec 12 10:02:56 2024 +0100 selftests: timers: clocksource-switch: Adapt progress to kselftest framework [ Upstream commit 8694e6a7f7dba23d3abd9f5a96f64d161704c7b1 ] When adapting the test to the kselftest framework, a few printf() calls indicating test progress were not updated. Fix this by replacing these printf() calls by ksft_print_msg() calls. Link: https://lore.kernel.org/r/7dd4b9ab6e43268846e250878ebf25ae6d3d01ce.1733994134.git.geert+renesas@glider.be Fixes: ce7d101750ff ("selftests: timers: clocksource-switch: adapt to kselftest framework") Signed-off-by: Geert Uytterhoeven <[email protected]> Reviewed-by: Thomas Gleixner <[email protected]> Signed-off-by: Shuah Khan <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: John Ogness <[email protected]> Date: Tue Jan 7 22:32:57 2025 +0106 serial: 8250: Adjust the timeout for FIFO mode [ Upstream commit d91f98be26510f5f81ec66425bb0306d1ccd571a ] After a console has written a record into UART_TX, it uses wait_for_xmitr() to wait until the data has been sent out before returning. However, wait_for_xmitr() will timeout after 10ms, regardless if the data has been transmitted or not. For single bytes, this timeout is sufficient even at very slow baud rates, such as 1200bps. However, when FIFO mode is used, there may be 64 bytes pushed into the FIFO at once. At a baud rate of 115200bps, the 10ms timeout is still sufficient. But when using lower baud rates (such as 57600bps), the timeout is _not_ sufficient. This causes longer lines to be cut off, resulting in lost and horribly misformatted output on the console. When using FIFO mode, take the number of bytes into account to determine an appropriate maximum timeout. Increasing the timeout does not affect performance since ideally the timeout never occurs. Fixes: 8f3631f0f6eb ("serial/8250: Use fifo in 8250 console driver") Signed-off-by: John Ogness <[email protected]> Reviewed-by: Andy Shevchenko <[email protected]> Reviewed-by: Wander Lairson Costa <[email protected]> Reviewed-by: Petr Mladek <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Paulo Alcantara <[email protected]> Date: Thu Jan 16 14:29:03 2025 -0300 smb: client: fix oops due to unset link speed [ Upstream commit be7a6a77669588bfa5022a470989702bbbb11e7f ] It isn't guaranteed that NETWORK_INTERFACE_INFO::LinkSpeed will always be set by the server, so the client must handle any values and then prevent oopses like below from happening: Oops: divide error: 0000 [#1] PREEMPT SMP KASAN NOPTI CPU: 0 UID: 0 PID: 1323 Comm: cat Not tainted 6.13.0-rc7 #2 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-3.fc41 04/01/2014 RIP: 0010:cifs_debug_data_proc_show+0xa45/0x1460 [cifs] Code: 00 00 48 89 df e8 3b cd 1b c1 41 f6 44 24 2c 04 0f 84 50 01 00 00 48 89 ef e8 e7 d0 1b c1 49 8b 44 24 18 31 d2 49 8d 7c 24 28 <48> f7 74 24 18 48 89 c3 e8 6e cf 1b c1 41 8b 6c 24 28 49 8d 7c 24 RSP: 0018:ffffc90001817be0 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff88811230022c RCX: ffffffffc041bd99 RDX: 0000000000000000 RSI: 0000000000000567 RDI: ffff888112300228 RBP: ffff888112300218 R08: fffff52000302f5f R09: ffffed1022fa58ac R10: ffff888117d2c566 R11: 00000000fffffffe R12: ffff888112300200 R13: 000000012a15343f R14: 0000000000000001 R15: ffff888113f2db58 FS: 00007fe27119e740(0000) GS:ffff888148600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fe2633c5000 CR3: 0000000124da0000 CR4: 0000000000750ef0 PKRU: 55555554 Call Trace: <TASK> ? __die_body.cold+0x19/0x27 ? die+0x2e/0x50 ? do_trap+0x159/0x1b0 ? cifs_debug_data_proc_show+0xa45/0x1460 [cifs] ? do_error_trap+0x90/0x130 ? cifs_debug_data_proc_show+0xa45/0x1460 [cifs] ? exc_divide_error+0x39/0x50 ? cifs_debug_data_proc_show+0xa45/0x1460 [cifs] ? asm_exc_divide_error+0x1a/0x20 ? cifs_debug_data_proc_show+0xa39/0x1460 [cifs] ? cifs_debug_data_proc_show+0xa45/0x1460 [cifs] ? seq_read_iter+0x42e/0x790 seq_read_iter+0x19a/0x790 proc_reg_read_iter+0xbe/0x110 ? __pfx_proc_reg_read_iter+0x10/0x10 vfs_read+0x469/0x570 ? do_user_addr_fault+0x398/0x760 ? __pfx_vfs_read+0x10/0x10 ? find_held_lock+0x8a/0xa0 ? __pfx_lock_release+0x10/0x10 ksys_read+0xd3/0x170 ? __pfx_ksys_read+0x10/0x10 ? __rcu_read_unlock+0x50/0x270 ? mark_held_locks+0x1a/0x90 do_syscall_64+0xbb/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7fe271288911 Code: 00 48 8b 15 01 25 10 00 f7 d8 64 89 02 b8 ff ff ff ff eb bd e8 20 ad 01 00 f3 0f 1e fa 80 3d b5 a7 10 00 00 74 13 31 c0 0f 05 <48> 3d 00 f0 ff ff 77 4f c3 66 0f 1f 44 00 00 55 48 89 e5 48 83 ec RSP: 002b:00007ffe87c079d8 EFLAGS: 00000246 ORIG_RAX: 0000000000000000 RAX: ffffffffffffffda RBX: 0000000000040000 RCX: 00007fe271288911 RDX: 0000000000040000 RSI: 00007fe2633c6000 RDI: 0000000000000003 RBP: 00007ffe87c07a00 R08: 0000000000000000 R09: 00007fe2713e6380 R10: 0000000000000022 R11: 0000000000000246 R12: 0000000000040000 R13: 00007fe2633c6000 R14: 0000000000000003 R15: 0000000000000000 </TASK> Fix this by setting cifs_server_iface::speed to a sane value (1Gbps) by default when link speed is unset. Cc: Shyam Prasad N <[email protected]> Cc: Tom Talpey <[email protected]> Fixes: a6d8fb54a515 ("cifs: distribute channels across interfaces based on speed") Reported-by: Frank Sorenson <[email protected]> Reported-by: Jay Shin <[email protected]> Signed-off-by: Paulo Alcantara (Red Hat) <[email protected]> Signed-off-by: Steve French <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Javier Carrasco <[email protected]> Date: Thu Oct 31 13:33:36 2024 +0100 soc: atmel: fix device_node release in atmel_soc_device_init() [ Upstream commit d3455ab798100f40af77123e7c2443ec979c546b ] A device_node acquired via of_find_node_by_path() requires explicit calls to of_node_put() when it is no longer needed to avoid leaking the resource. Instead of adding the missing calls to of_node_put() in all execution paths, use the cleanup attribute for 'np' by means of the __free() macro, which automatically calls of_node_put() when the variable goes out of scope. Fixes: 960ddf70cc11 ("drivers: soc: atmel: Avoid calling at91_soc_init on non AT91 SoCs") Signed-off-by: Javier Carrasco <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Claudiu Beznea <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Mark Brown <[email protected]> Date: Fri Jan 17 16:16:03 2025 +0000 spi: omap2-mcspi: Correctly handle devm_clk_get_optional() errors [ Upstream commit a07eb4f67ed085f32002a1af2b6073546d67de3f ] devm_clk_get_optional() returns NULL for missing clocks and a PTR_ERR() if there is a clock but we fail to get it, but currently we only handle the latter case and do so as though the clock was missing. If we get an error back we should handle that as an error since the clock exists but we failed to get it, if we get NULL then the clock doesn't exist and we should handle that. Fixes: 4c6ac5446d06 ("spi: omap2-mcspi: Fix the IS_ERR() bug for devm_clk_get_optional_enabled()") Reported-by: Lars Pedersen <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Mark Brown <[email protected]> Tested-by: Lars Pedersen <[email protected]> Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Mingwei Zheng <[email protected]> Date: Fri Dec 6 20:52:06 2024 -0500 spi: zynq-qspi: Add check for clk_enable() [ Upstream commit 8332e667099712e05ec87ba2058af394b51ebdc9 ] Add check for the return value of clk_enable() to catch the potential error. Fixes: c618a90dcaf3 ("spi: zynq-qspi: Drop GPIO header") Signed-off-by: Mingwei Zheng <[email protected]> Signed-off-by: Jiasheng Jiang <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Joe Hattori <[email protected]> Date: Tue Dec 24 12:54:11 2024 +0900 staging: media: imx: fix OF node leak in imx_media_add_of_subdevs() [ Upstream commit 094f5c315f756b19198e6c401aa821ac0e868750 ] imx_media_add_of_subdevs() calls of_parse_phandle() and passes the obtained node to imx_media_of_add_csi(). The passed node is used in v4l2_async_nf_add_fwnode(), which increments the refcount of the node. Therefore, while the current implementation only releases the node when imx_media_of_add_csi() fails, but should always release it. Call of_node_put() right after imx_media_of_add_csi(). Fixes: dee747f88167 ("media: imx: Don't register IPU subdevs/links if CSI port missing") Signed-off-by: Joe Hattori <[email protected]> Reviewed-by: Vladimir Zapolskiy <[email protected]> Reviewed-by: Philipp Zabel <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Laurentiu Palcu <[email protected]> Date: Tue Dec 17 08:51:50 2024 +0200 staging: media: max96712: fix kernel oops when removing module commit ee1b5046d5cd892a0754ab982aeaaad3702083a5 upstream. The following kernel oops is thrown when trying to remove the max96712 module: Unable to handle kernel paging request at virtual address 00007375746174db Mem abort info: ESR = 0x0000000096000004 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x04: level 0 translation fault Data abort info: ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 CM = 0, WnR = 0, TnD = 0, TagAccess = 0 GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 user pgtable: 4k pages, 48-bit VAs, pgdp=000000010af89000 [00007375746174db] pgd=0000000000000000, p4d=0000000000000000 Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP Modules linked in: crct10dif_ce polyval_ce mxc_jpeg_encdec flexcan snd_soc_fsl_sai snd_soc_fsl_asoc_card snd_soc_fsl_micfil dwc_mipi_csi2 imx_csi_formatter polyval_generic v4l2_jpeg imx_pcm_dma can_dev snd_soc_imx_audmux snd_soc_wm8962 snd_soc_imx_card snd_soc_fsl_utils max96712(C-) rpmsg_ctrl rpmsg_char pwm_fan fuse [last unloaded: imx8_isi] CPU: 0 UID: 0 PID: 754 Comm: rmmod Tainted: G C 6.12.0-rc6-06364-g327fec852c31 #17 Tainted: [C]=CRAP Hardware name: NXP i.MX95 19X19 board (DT) pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : led_put+0x1c/0x40 lr : v4l2_subdev_put_privacy_led+0x48/0x58 sp : ffff80008699bbb0 x29: ffff80008699bbb0 x28: ffff00008ac233c0 x27: 0000000000000000 x26: 0000000000000000 x25: 0000000000000000 x24: 0000000000000000 x23: ffff000080cf1170 x22: ffff00008b53bd00 x21: ffff8000822ad1c8 x20: ffff000080ff5c00 x19: ffff00008b53be40 x18: 0000000000000000 x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 x14: 0000000000000004 x13: ffff0000800f8010 x12: 0000000000000000 x11: ffff000082acf5c0 x10: ffff000082acf478 x9 : ffff0000800f8010 x8 : 0101010101010101 x7 : 7f7f7f7f7f7f7f7f x6 : fefefeff6364626d x5 : 8080808000000000 x4 : 0000000000000020 x3 : 00000000553a3dc1 x2 : ffff00008ac233c0 x1 : ffff00008ac233c0 x0 : ff00737574617473 Call trace: led_put+0x1c/0x40 v4l2_subdev_put_privacy_led+0x48/0x58 v4l2_async_unregister_subdev+0x2c/0x1a4 max96712_remove+0x1c/0x38 [max96712] i2c_device_remove+0x2c/0x9c device_remove+0x4c/0x80 device_release_driver_internal+0x1cc/0x228 driver_detach+0x4c/0x98 bus_remove_driver+0x6c/0xbc driver_unregister+0x30/0x60 i2c_del_driver+0x54/0x64 max96712_i2c_driver_exit+0x18/0x1d0 [max96712] __arm64_sys_delete_module+0x1a4/0x290 invoke_syscall+0x48/0x10c el0_svc_common.constprop.0+0xc0/0xe0 do_el0_svc+0x1c/0x28 el0_svc+0x34/0xd8 el0t_64_sync_handler+0x120/0x12c el0t_64_sync+0x190/0x194 Code: f9000bf3 aa0003f3 f9402800 f9402000 (f9403400) ---[ end trace 0000000000000000 ]--- This happens because in v4l2_i2c_subdev_init(), the i2c_set_cliendata() is called again and the data is overwritten to point to sd, instead of priv. So, in remove(), the wrong pointer is passed to v4l2_async_unregister_subdev(), leading to a crash. Fixes: 5814f32fef13 ("media: staging: max96712: Add basic support for MAX96712 GMSL2 deserializer") Signed-off-by: Laurentiu Palcu <[email protected]> Cc: [email protected] Reviewed-by: Niklas Söderlund <[email protected]> Reviewed-by: Ricardo Ribalda <[email protected]> Signed-off-by: Sakari Ailus <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Jon Maloy <[email protected]> Date: Mon Jan 27 18:13:04 2025 -0500 tcp: correct handling of extreme memory squeeze [ Upstream commit 8c670bdfa58e48abad1d5b6ca1ee843ca91f7303 ] Testing with iperf3 using the "pasta" protocol splicer has revealed a problem in the way tcp handles window advertising in extreme memory squeeze situations. Under memory pressure, a socket endpoint may temporarily advertise a zero-sized window, but this is not stored as part of the socket data. The reasoning behind this is that it is considered a temporary setting which shouldn't influence any further calculations. However, if we happen to stall at an unfortunate value of the current window size, the algorithm selecting a new value will consistently fail to advertise a non-zero window once we have freed up enough memory. This means that this side's notion of the current window size is different from the one last advertised to the peer, causing the latter to not send any data to resolve the sitution. The problem occurs on the iperf3 server side, and the socket in question is a completely regular socket with the default settings for the fedora40 kernel. We do not use SO_PEEK or SO_RCVBUF on the socket. The following excerpt of a logging session, with own comments added, shows more in detail what is happening: // tcp_v4_rcv(->) // tcp_rcv_established(->) [5201<->39222]: ==== Activating log @ net/ipv4/tcp_input.c/tcp_data_queue()/5257 ==== [5201<->39222]: tcp_data_queue(->) [5201<->39222]: DROPPING skb [265600160..265665640], reason: SKB_DROP_REASON_PROTO_MEM [rcv_nxt 265600160, rcv_wnd 262144, snt_ack 265469200, win_now 131184] [copied_seq 259909392->260034360 (124968), unread 5565800, qlen 85, ofoq 0] [OFO queue: gap: 65480, len: 0] [5201<->39222]: tcp_data_queue(<-) [5201<->39222]: __tcp_transmit_skb(->) [tp->rcv_wup: 265469200, tp->rcv_wnd: 262144, tp->rcv_nxt 265600160] [5201<->39222]: tcp_select_window(->) [5201<->39222]: (inet_csk(sk)->icsk_ack.pending & ICSK_ACK_NOMEM) ? --> TRUE [tp->rcv_wup: 265469200, tp->rcv_wnd: 262144, tp->rcv_nxt 265600160] returning 0 [5201<->39222]: tcp_select_window(<-) [5201<->39222]: ADVERTISING WIN 0, ACK_SEQ: 265600160 [5201<->39222]: [__tcp_transmit_skb(<-) [5201<->39222]: tcp_rcv_established(<-) [5201<->39222]: tcp_v4_rcv(<-) // Receive queue is at 85 buffers and we are out of memory. // We drop the incoming buffer, although it is in sequence, and decide // to send an advertisement with a window of zero. // We don't update tp->rcv_wnd and tp->rcv_wup accordingly, which means // we unconditionally shrink the window. [5201<->39222]: tcp_recvmsg_locked(->) [5201<->39222]: __tcp_cleanup_rbuf(->) tp->rcv_wup: 265469200, tp->rcv_wnd: 262144, tp->rcv_nxt 265600160 [5201<->39222]: [new_win = 0, win_now = 131184, 2 * win_now = 262368] [5201<->39222]: [new_win >= (2 * win_now) ? --> time_to_ack = 0] [5201<->39222]: NOT calling tcp_send_ack() [tp->rcv_wup: 265469200, tp->rcv_wnd: 262144, tp->rcv_nxt 265600160] [5201<->39222]: __tcp_cleanup_rbuf(<-) [rcv_nxt 265600160, rcv_wnd 262144, snt_ack 265469200, win_now 131184] [copied_seq 260040464->260040464 (0), unread 5559696, qlen 85, ofoq 0] returning 6104 bytes [5201<->39222]: tcp_recvmsg_locked(<-) // After each read, the algorithm for calculating the new receive // window in __tcp_cleanup_rbuf() finds it is too small to advertise // or to update tp->rcv_wnd. // Meanwhile, the peer thinks the window is zero, and will not send // any more data to trigger an update from the interrupt mode side. [5201<->39222]: tcp_recvmsg_locked(->) [5201<->39222]: __tcp_cleanup_rbuf(->) tp->rcv_wup: 265469200, tp->rcv_wnd: 262144, tp->rcv_nxt 265600160 [5201<->39222]: [new_win = 262144, win_now = 131184, 2 * win_now = 262368] [5201<->39222]: [new_win >= (2 * win_now) ? --> time_to_ack = 0] [5201<->39222]: NOT calling tcp_send_ack() [tp->rcv_wup: 265469200, tp->rcv_wnd: 262144, tp->rcv_nxt 265600160] [5201<->39222]: __tcp_cleanup_rbuf(<-) [rcv_nxt 265600160, rcv_wnd 262144, snt_ack 265469200, win_now 131184] [copied_seq 260099840->260171536 (71696), unread 5428624, qlen 83, ofoq 0] returning 131072 bytes [5201<->39222]: tcp_recvmsg_locked(<-) // The above pattern repeats again and again, since nothing changes // between the reads. [...] [5201<->39222]: tcp_recvmsg_locked(->) [5201<->39222]: __tcp_cleanup_rbuf(->) tp->rcv_wup: 265469200, tp->rcv_wnd: 262144, tp->rcv_nxt 265600160 [5201<->39222]: [new_win = 262144, win_now = 131184, 2 * win_now = 262368] [5201<->39222]: [new_win >= (2 * win_now) ? --> time_to_ack = 0] [5201<->39222]: NOT calling tcp_send_ack() [tp->rcv_wup: 265469200, tp->rcv_wnd: 262144, tp->rcv_nxt 265600160] [5201<->39222]: __tcp_cleanup_rbuf(<-) [rcv_nxt 265600160, rcv_wnd 262144, snt_ack 265469200, win_now 131184] [copied_seq 265600160->265600160 (0), unread 0, qlen 0, ofoq 0] returning 54672 bytes [5201<->39222]: tcp_recvmsg_locked(<-) // The receive queue is empty, but no new advertisement has been sent. // The peer still thinks the receive window is zero, and sends nothing. // We have ended up in a deadlock situation. Note that well behaved endpoints will send win0 probes, so the problem will not occur. Furthermore, we have observed that in these situations this side may send out an updated 'th->ack_seq´ which is not stored in tp->rcv_wup as it should be. Backing ack_seq seems to be harmless, but is of course still wrong from a protocol viewpoint. We fix this by updating the socket state correctly when a packet has been dropped because of memory exhaustion and we have to advertize a zero window. Further testing shows that the connection recovers neatly from the squeeze situation, and traffic can continue indefinitely. Fixes: e2142825c120 ("net: tcp: send zero-window ACK when no memory") Cc: Menglong Dong <[email protected]> Reviewed-by: Stefano Brivio <[email protected]> Signed-off-by: Jon Maloy <[email protected]> Reviewed-by: Jason Xing <[email protected]> Reviewed-by: Eric Dumazet <[email protected]> Reviewed-by: Neal Cardwell <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Mahdi Arghavani <[email protected]> Date: Fri Jan 17 21:37:51 2025 +0000 tcp_cubic: fix incorrect HyStart round start detection [ Upstream commit 25c1a9ca53db5780757e7f53e688b8f916821baa ] I noticed that HyStart incorrectly marks the start of rounds, leading to inaccurate measurements of ACK train lengths and resetting the `ca->sample_cnt` variable. This inaccuracy can impact HyStart's functionality in terminating exponential cwnd growth during Slow-Start, potentially degrading TCP performance. The issue arises because the changes introduced in commit 4e1fddc98d25 ("tcp_cubic: fix spurious Hystart ACK train detections for not-cwnd-limited flows") moved the caller of the `bictcp_hystart_reset` function inside the `hystart_update` function. This modification added an additional condition for triggering the caller, requiring that (tcp_snd_cwnd(tp) >= hystart_low_window) must also be satisfied before invoking `bictcp_hystart_reset`. This fix ensures that `bictcp_hystart_reset` is correctly called at the start of a new round, regardless of the congestion window size. This is achieved by moving the condition (tcp_snd_cwnd(tp) >= hystart_low_window) from before calling `bictcp_hystart_reset` to after it. I tested with a client and a server connected through two Linux software routers. In this setup, the minimum RTT was 150 ms, the bottleneck bandwidth was 50 Mbps, and the bottleneck buffer size was 1 BDP, calculated as (50M / 1514 / 8) * 0.150 = 619 packets. I conducted the test twice, transferring data from the server to the client for 1.5 seconds. Before the patch was applied, HYSTART-DELAY stopped the exponential growth of cwnd when cwnd = 516, and the bottleneck link was not yet saturated (516 < 619). After the patch was applied, HYSTART-ACK-TRAIN stopped the exponential growth of cwnd when cwnd = 632, and the bottleneck link was saturated (632 > 619). In this test, applying the patch resulted in 300 KB more data delivered. Fixes: 4e1fddc98d25 ("tcp_cubic: fix spurious Hystart ACK train detections for not-cwnd-limited flows") Signed-off-by: Mahdi Arghavani <[email protected]> Reviewed-by: Jason Xing <[email protected]> Cc: Neal Cardwell <[email protected]> Cc: Eric Dumazet <[email protected]> Cc: Haibo Zhang <[email protected]> Cc: David Eyers <[email protected]> Cc: Abbas Arghavani <[email protected]> Reviewed-by: Neal Cardwell <[email protected]> Tested-by: Neal Cardwell <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Octavian Purdila <[email protected]> Date: Mon Dec 30 12:56:47 2024 -0800 team: prevent adding a device which is already a team device lower [ Upstream commit 3fff5da4ca2164bb4d0f1e6cd33f6eb8a0e73e50 ] Prevent adding a device which is already a team device lower, e.g. adding veth0 if vlan1 was already added and veth0 is a lower of vlan1. This is not useful in practice and can lead to recursive locking: $ ip link add veth0 type veth peer name veth1 $ ip link set veth0 up $ ip link set veth1 up $ ip link add link veth0 name veth0.1 type vlan protocol 802.1Q id 1 $ ip link add team0 type team $ ip link set veth0.1 down $ ip link set veth0.1 master team0 team0: Port device veth0.1 added $ ip link set veth0 down $ ip link set veth0 master team0 ============================================ WARNING: possible recursive locking detected 6.13.0-rc2-virtme-00441-ga14a429069bb #46 Not tainted -------------------------------------------- ip/7684 is trying to acquire lock: ffff888016848e00 (team->team_lock_key){+.+.}-{4:4}, at: team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973) but task is already holding lock: ffff888016848e00 (team->team_lock_key){+.+.}-{4:4}, at: team_add_slave (drivers/net/team/team_core.c:1147 drivers/net/team/team_core.c:1977) other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(team->team_lock_key); lock(team->team_lock_key); *** DEADLOCK *** May be due to missing lock nesting notation 2 locks held by ip/7684: stack backtrace: CPU: 3 UID: 0 PID: 7684 Comm: ip Not tainted 6.13.0-rc2-virtme-00441-ga14a429069bb #46 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 Call Trace: <TASK> dump_stack_lvl (lib/dump_stack.c:122) print_deadlock_bug.cold (kernel/locking/lockdep.c:3040) __lock_acquire (kernel/locking/lockdep.c:3893 kernel/locking/lockdep.c:5226) ? netlink_broadcast_filtered (net/netlink/af_netlink.c:1548) lock_acquire.part.0 (kernel/locking/lockdep.c:467 kernel/locking/lockdep.c:5851) ? team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973) ? trace_lock_acquire (./include/trace/events/lock.h:24 (discriminator 2)) ? team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973) ? lock_acquire (kernel/locking/lockdep.c:5822) ? team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973) __mutex_lock (kernel/locking/mutex.c:587 kernel/locking/mutex.c:735) ? team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973) ? team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973) ? fib_sync_up (net/ipv4/fib_semantics.c:2167) ? team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973) team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973) notifier_call_chain (kernel/notifier.c:85) call_netdevice_notifiers_info (net/core/dev.c:1996) __dev_notify_flags (net/core/dev.c:8993) ? __dev_change_flags (net/core/dev.c:8975) dev_change_flags (net/core/dev.c:9027) vlan_device_event (net/8021q/vlan.c:85 net/8021q/vlan.c:470) ? br_device_event (net/bridge/br.c:143) notifier_call_chain (kernel/notifier.c:85) call_netdevice_notifiers_info (net/core/dev.c:1996) dev_open (net/core/dev.c:1519 net/core/dev.c:1505) team_add_slave (drivers/net/team/team_core.c:1219 drivers/net/team/team_core.c:1977) ? __pfx_team_add_slave (drivers/net/team/team_core.c:1972) do_set_master (net/core/rtnetlink.c:2917) do_setlink.isra.0 (net/core/rtnetlink.c:3117) Reported-by: [email protected] Closes: https://syzkaller.appspot.com/bug?extid=3c47b5843403a45aef57 Fixes: 3d249d4ca7d0 ("net: introduce ethernet teaming device") Signed-off-by: Octavian Purdila <[email protected]> Reviewed-by: Hangbin Liu <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Arnaldo Carvalho de Melo <[email protected]> Date: Wed Dec 11 12:24:21 2024 -0300 tools build: Remove the libunwind feature tests from the ones detected when test-all.o builds [ Upstream commit b40fbeb0b1cd72912c41fb18c8b5e4b73ed191c4 ] We have a tools/build/feature/test-all.c that has the most common set of features that perf uses and are expected to have its development files available when building perf. When we made libwunwind opt-in we forgot to remove them from the list of features that are assumed to be available when test-all.c builds, remove them. Before this patch: $ rm -rf /tmp/b ; mkdir /tmp/b ; make -C tools/perf O=/tmp/b feature-dump ; grep feature-libunwind-aarch64= /tmp/b/FEATURE-DUMP feature-libunwind-aarch64=1 $ Even tho this not being test built and those header files being available: $ head -5 tools/build/feature/test-libunwind-aarch64.c // SPDX-License-Identifier: GPL-2.0 #include <libunwind-aarch64.h> #include <stdlib.h> extern int UNW_OBJ(dwarf_search_unwind_table) (unw_addr_space_t as, $ After this patch: $ grep feature-libunwind- /tmp/b/FEATURE-DUMP $ Now an audit on what is being enabled when test-all.c builds will be performed. Fixes: 176c9d1e6a06f2fa ("tools features: Don't check for libunwind devel files by default") Cc: Adrian Hunter <[email protected]> Cc: Ian Rogers <[email protected]> Cc: James Clark <[email protected]> Cc: Jiri Olsa <[email protected]> Cc: Kan Liang <[email protected]> Cc: Namhyung Kim <[email protected]> Signed-off-by: Arnaldo Carvalho de Melo <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Arnaldo Carvalho de Melo <[email protected]> Date: Tue Dec 3 17:52:33 2024 -0300 tools features: Don't check for libunwind devel files by default [ Upstream commit 176c9d1e6a06f2fa62c1b9743369ab35c724d2c4 ] Since 13e17c9ff49119aa ("perf build: Make libunwind opt-in rather than opt-out"), so we shouldn't by default be testing for its availability at build time in tools/build/features/test-all.c. That test was designed to test the features we expect to be the most common ones in most builds, so if we test build just that file, then we assume the features there are present and will not test one by one. Removing it from test-all.c gets rid of the first impediment for test-all.c to build successfully: $ cat /tmp/build/perf-tools-next/feature/test-all.make.output In file included from test-all.c:62: test-libunwind.c:2:10: fatal error: libunwind.h: No such file or directory 2 | #include <libunwind.h> | ^~~~~~~~~~~~~ compilation terminated. $ We then get to: $ cat /tmp/build/perf-tools-next/feature/test-all.make.output /usr/bin/ld: cannot find -lunwind-x86_64: No such file or directory /usr/bin/ld: cannot find -lunwind: No such file or directory collect2: error: ld returned 1 exit status $ So make all the logic related to setting CFLAGS, LDFLAGS, etc for libunwind to be conditional on NO_LIBWUNWIND=1, which is now the default, now we get a faster build: $ cat /tmp/build/perf-tools-next/feature/test-all.make.output $ ldd /tmp/build/perf-tools-next/feature/test-all.bin linux-vdso.so.1 (0x00007fef04cde000) libdw.so.1 => /lib64/libdw.so.1 (0x00007fef04a49000) libpython3.12.so.1.0 => /lib64/libpython3.12.so.1.0 (0x00007fef04478000) libm.so.6 => /lib64/libm.so.6 (0x00007fef04394000) libtraceevent.so.1 => /lib64/libtraceevent.so.1 (0x00007fef0436c000) libtracefs.so.1 => /lib64/libtracefs.so.1 (0x00007fef04345000) libcrypto.so.3 => /lib64/libcrypto.so.3 (0x00007fef03e95000) libz.so.1 => /lib64/libz.so.1 (0x00007fef03e72000) libelf.so.1 => /lib64/libelf.so.1 (0x00007fef03e56000) libnuma.so.1 => /lib64/libnuma.so.1 (0x00007fef03e48000) libslang.so.2 => /lib64/libslang.so.2 (0x00007fef03b65000) libperl.so.5.38 => /lib64/libperl.so.5.38 (0x00007fef037c6000) libc.so.6 => /lib64/libc.so.6 (0x00007fef035d5000) liblzma.so.5 => /lib64/liblzma.so.5 (0x00007fef035a0000) libzstd.so.1 => /lib64/libzstd.so.1 (0x00007fef034e1000) libbz2.so.1 => /lib64/libbz2.so.1 (0x00007fef034cd000) /lib64/ld-linux-x86-64.so.2 (0x00007fef04ce0000) libcrypt.so.2 => /lib64/libcrypt.so.2 (0x00007fef03495000) $ Fixes: 13e17c9ff49119aa ("perf build: Make libunwind opt-in rather than opt-out") Cc: Adrian Hunter <[email protected]> Cc: Ian Rogers <[email protected]> Cc: James Clark <[email protected]> Cc: Jiri Olsa <[email protected]> Cc: Kan Liang <[email protected]> Cc: Namhyung Kim <[email protected]> Link: https://lore.kernel.org/lkml/Z09zTztD8X8qIWCX@x1 Signed-off-by: Arnaldo Carvalho de Melo <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Luo Yifan <[email protected]> Date: Tue Jan 28 23:27:01 2025 +0900 tools/bootconfig: Fix the wrong format specifier [ Upstream commit f6ab7384d554ba80ff4793259d75535874b366f5 ] Use '%u' instead of '%d' for unsigned int. Link: https://lore.kernel.org/all/[email protected]/ Fixes: 973780011106 ("tools/bootconfig: Suppress non-error messages") Signed-off-by: Luo Yifan <[email protected]> Signed-off-by: Masami Hiramatsu (Google) <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Len Brown <[email protected]> Date: Mon Jan 27 16:42:19 2025 -0600 tools/power turbostat: Fix forked child affinity regression [ Upstream commit b32c36975da48afc9089f8b61f7b2dcc40e479d2 ] In "one-shot" mode, turbostat 1. takes a counter snapshot 2. forks and waits for a child 3. takes the end counter snapshot and prints the result. But turbostat counter snapshots currently use affinity to travel around the system so that counter reads are "local", and this affinity must be cleared between #1 and #2 above. The offending commit removed that reset that allowed the child to run on cpu_present_set. Fix that issue, and improve upon the original by using cpu_possible_set for the child. This allows the child to also run on CPUs that hotplug online during its runtime. Reported-by: Zhang Rui <[email protected]> Fixes: 7bb3fe27ad4f ("tools/power/turbostat: Obey allowed CPUs during startup") Signed-off-by: Len Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Patryk Wlazlyn <[email protected]> Date: Fri Dec 20 13:38:34 2024 +0100 tools/power turbostat: Fix PMT mmaped file size rounding [ Upstream commit 2f60f03934a50bc1fb69bb4f47a25cddd6807b0b ] This (the old code) is just not how you round up to a page size. Noticed on a recent Intel platform. Previous ones must have been reporting sizes already aligned to a page and so the bug was missed when testing. Fixes: f0e4ed752fda ("tools/power turbostat: Add early support for PMT counters") Signed-off-by: Patryk Wlazlyn <[email protected]> Signed-off-by: Len Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Marco Leogrande <[email protected]> Date: Mon Dec 2 12:45:30 2024 -0800 tools/testing/selftests/bpf/test_tc_tunnel.sh: Fix wait for server bind [ Upstream commit e2f0791124a1b6ca8d570110cbd487969d9d41ef ] Commit f803bcf9208a ("selftests/bpf: Prevent client connect before server bind in test_tc_tunnel.sh") added code that waits for the netcat server to start before the netcat client attempts to connect to it. However, not all calls to 'server_listen' were guarded. This patch adds the existing 'wait_for_port' guard after the remaining call to 'server_listen'. Fixes: f803bcf9208a ("selftests/bpf: Prevent client connect before server bind in test_tc_tunnel.sh") Signed-off-by: Marco Leogrande <[email protected]> Acked-by: Stanislav Fomichev <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Alexei Starovoitov <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Vishal Chourasia <[email protected]> Date: Fri Jan 17 15:42:59 2025 +0100 tools: Sync if_xdp.h uapi tooling header [ Upstream commit 01f3ce5328c405179b2c69ea047c423dad2bfa6d ] Sync if_xdp.h uapi header to remove following warning: Warning: Kernel ABI header at 'tools/include/uapi/linux/if_xdp.h' differs from latest version at 'include/uapi/linux/if_xdp.h' Fixes: 48eb03dd2630 ("xsk: Add TX timestamp and TX checksum offload support") Signed-off-by: Vishal Chourasia <[email protected]> Signed-off-by: Song Yoong Siang <[email protected]> Signed-off-by: Daniel Borkmann <[email protected]> Link: https://lore.kernel.org/bpf/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Jakub Kicinski <[email protected]> Date: Thu Jan 23 17:21:30 2025 -0800 tools: ynl: c: correct reverse decode of empty attrs [ Upstream commit 964417a5d4a06614ef7fb3ae69bb17c91a2dc016 ] netlink reports which attribute was incorrect by sending back an attribute offset. Offset points to the address of struct nlattr, but to interpret the type we also need the nesting path. Attribute IDs have different meaning in different nests of the same message. Correct the condition for "is the offset within current attribute". ynl_attr_data_len() does not include the attribute header, so the end offset was off by 4 bytes. This means that we'd always skip over flags and empty nests. The devmem tests, for example, issues an invalid request with empty queue nests, resulting in the following error: YNL failed: Kernel error: missing attribute: .queues.ifindex The message is incorrect, "queues" nest does not have an "ifindex" attribute defined. With this fix we decend correctly into the nest: YNL failed: Kernel error: missing attribute: .queues.id Fixes: 86878f14d71a ("tools: ynl: user space helpers") Reviewed-by: Donald Hunter <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Jiri Slaby (SUSE) <[email protected]> Date: Fri Jan 10 12:52:28 2025 +0100 tty: mips_ejtag_fdc: fix one more u8 warning [ Upstream commit 6dd1de91e7a62bfd3878992c1db6e1d443022c76 ] The LKP robot complains about: drivers/tty/mips_ejtag_fdc.c:1224:31: error: incompatible pointer types passing 'const char *[1]' to parameter of type 'const u8 **' (aka 'const unsigned char **') Fix this by turning the missing pieces (fetch from kgdbfdc_wbuf) to u8 too. Note the filling part (kgdbfdc_write_char()) already receives and stores u8 to kgdbfdc_wbuf. Fixes: ce7cbd9a6c81 ("tty: mips_ejtag_fdc: use u8 for character pointers") Reported-by: kernel test robot <[email protected]> Closes: https://lore.kernel.org/oe-kbuild-all/[email protected]/ Signed-off-by: Jiri Slaby (SUSE) <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Zhihao Cheng <[email protected]> Date: Sat Dec 14 19:01:53 2024 +0800 ubi: Revert "ubi: wl: Close down wear-leveling before nand is suspended" [ Upstream commit 844c6fdc13cf3d9d251533631988a58f8356a8c8 ] Commit 5580cdae05ae ("ubi: wl: Close down wear-leveling before nand is suspended") added a reboot notification in UBI layer to shutdown the wear-leveling subsystem, which imported an UAF problem[1]. Besides that, the method also brings other potential UAF problems, for example: reboot kworker ubi_wl_reboot_notifier ubi_wl_close ubi_fastmap_close kfree(ubi->fm) update_fastmap_work_fn ubi_update_fastmap old_fm = ubi->fm if (old_fm && old_fm->e[i]) // UAF! Actually, the problem fixed by commit 5580cdae05ae ("ubi: wl: Close down wear-leveling before nand is suspended") has been solved by commit 8cba323437a4 ("mtd: rawnand: protect access to rawnand devices while in suspend"), which was discussed in [2]. So we can revert the commit 5580cdae05ae ("ubi: wl: Close down wear-leveling before nand is suspended") directly. [1] https://lore.kernel.org/linux-mtd/[email protected]/ [2] https://lore.kernel.org/all/[email protected]/ Fixes: 5580cdae05ae ("ubi: wl: Close down wear-leveling before nand is suspended") Reported-by: Dennis Lam <[email protected]> Closes: https://lore.kernel.org/linux-mtd/[email protected]/ Signed-off-by: Zhihao Cheng <[email protected]> Acked-by: Mårten Lindahl <[email protected]> Signed-off-by: Richard Weinberger <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: pangliyuan <[email protected]> Date: Tue Dec 24 16:18:23 2024 +0800 ubifs: skip dumping tnc tree when zroot is null [ Upstream commit bdb0ca39e0acccf6771db49c3f94ed787d05f2d7 ] Clearing slab cache will free all znode in memory and make c->zroot.znode = NULL, then dumping tnc tree will access c->zroot.znode which cause null pointer dereference. Link: https://bugzilla.kernel.org/show_bug.cgi?id=219624#c0 Fixes: 1e51764a3c2a ("UBIFS: add new flash file system") Signed-off-by: pangliyuan <[email protected]> Reviewed-by: Zhihao Cheng <[email protected]> Signed-off-by: Richard Weinberger <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Stefano Brivio <[email protected]> Date: Wed Dec 18 17:21:16 2024 +0100 udp: Deal with race between UDP socket address change and rehash [ Upstream commit a502ea6fa94b1f7be72a24bcf9e3f5f6b7e6e90c ] If a UDP socket changes its local address while it's receiving datagrams, as a result of connect(), there is a period during which a lookup operation might fail to find it, after the address is changed but before the secondary hash (port and address) and the four-tuple hash (local and remote ports and addresses) are updated. Secondary hash chains were introduced by commit 30fff9231fad ("udp: bind() optimisation") and, as a result, a rehash operation became needed to make a bound socket reachable again after a connect(). This operation was introduced by commit 719f835853a9 ("udp: add rehash on connect()") which isn't however a complete fix: the socket will be found once the rehashing completes, but not while it's pending. This is noticeable with a socat(1) server in UDP4-LISTEN mode, and a client sending datagrams to it. After the server receives the first datagram (cf. _xioopen_ipdgram_listen()), it issues a connect() to the address of the sender, in order to set up a directed flow. Now, if the client, running on a different CPU thread, happens to send a (subsequent) datagram while the server's socket changes its address, but is not rehashed yet, this will result in a failed lookup and a port unreachable error delivered to the client, as apparent from the following reproducer: LEN=$(($(cat /proc/sys/net/core/wmem_default) / 4)) dd if=/dev/urandom bs=1 count=${LEN} of=tmp.in while :; do taskset -c 1 socat UDP4-LISTEN:1337,null-eof OPEN:tmp.out,create,trunc & sleep 0.1 || sleep 1 taskset -c 2 socat OPEN:tmp.in UDP4:localhost:1337,shut-null wait done where the client will eventually get ECONNREFUSED on a write() (typically the second or third one of a given iteration): 2024/11/13 21:28:23 socat[46901] E write(6, 0x556db2e3c000, 8192): Connection refused This issue was first observed as a seldom failure in Podman's tests checking UDP functionality while using pasta(1) to connect the container's network namespace, which leads us to a reproducer with the lookup error resulting in an ICMP packet on a tap device: LOCAL_ADDR="$(ip -j -4 addr show|jq -rM '.[] | .addr_info[0] | select(.scope == "global").local')" while :; do ./pasta --config-net -p pasta.pcap -u 1337 socat UDP4-LISTEN:1337,null-eof OPEN:tmp.out,create,trunc & sleep 0.2 || sleep 1 socat OPEN:tmp.in UDP4:${LOCAL_ADDR}:1337,shut-null wait cmp tmp.in tmp.out done Once this fails: tmp.in tmp.out differ: char 8193, line 29 we can finally have a look at what's going on: $ tshark -r pasta.pcap 1 0.000000 :: ? ff02::16 ICMPv6 110 Multicast Listener Report Message v2 2 0.168690 88.198.0.161 ? 88.198.0.164 UDP 8234 60260 ? 1337 Len=8192 3 0.168767 88.198.0.161 ? 88.198.0.164 UDP 8234 60260 ? 1337 Len=8192 4 0.168806 88.198.0.161 ? 88.198.0.164 UDP 8234 60260 ? 1337 Len=8192 5 0.168827 c6:47:05:8d:dc:04 ? Broadcast ARP 42 Who has 88.198.0.161? Tell 88.198.0.164 6 0.168851 9a:55:9a:55:9a:55 ? c6:47:05:8d:dc:04 ARP 42 88.198.0.161 is at 9a:55:9a:55:9a:55 7 0.168875 88.198.0.161 ? 88.198.0.164 UDP 8234 60260 ? 1337 Len=8192 8 0.168896 88.198.0.164 ? 88.198.0.161 ICMP 590 Destination unreachable (Port unreachable) 9 0.168926 88.198.0.161 ? 88.198.0.164 UDP 8234 60260 ? 1337 Len=8192 10 0.168959 88.198.0.161 ? 88.198.0.164 UDP 8234 60260 ? 1337 Len=8192 11 0.168989 88.198.0.161 ? 88.198.0.164 UDP 4138 60260 ? 1337 Len=4096 12 0.169010 88.198.0.161 ? 88.198.0.164 UDP 42 60260 ? 1337 Len=0 On the third datagram received, the network namespace of the container initiates an ARP lookup to deliver the ICMP message. In another variant of this reproducer, starting the client with: strace -f pasta --config-net -u 1337 socat UDP4-LISTEN:1337,null-eof OPEN:tmp.out,create,trunc 2>strace.log & and connecting to the socat server using a loopback address: socat OPEN:tmp.in UDP4:localhost:1337,shut-null we can more clearly observe a sendmmsg() call failing after the first datagram is delivered: [pid 278012] connect(173, 0x7fff96c95fc0, 16) = 0 [...] [pid 278012] recvmmsg(173, 0x7fff96c96020, 1024, MSG_DONTWAIT, NULL) = -1 EAGAIN (Resource temporarily unavailable) [pid 278012] sendmmsg(173, 0x561c5ad0a720, 1, MSG_NOSIGNAL) = 1 [...] [pid 278012] sendmmsg(173, 0x561c5ad0a720, 1, MSG_NOSIGNAL) = -1 ECONNREFUSED (Connection refused) and, somewhat confusingly, after a connect() on the same socket succeeded. Until commit 4cdeeee9252a ("net: udp: prefer listeners bound to an address"), the race between receive address change and lookup didn't actually cause visible issues, because, once the lookup based on the secondary hash chain failed, we would still attempt a lookup based on the primary hash (destination port only), and find the socket with the outdated secondary hash. That change, however, dropped port-only lookups altogether, as side effect, making the race visible. To fix this, while avoiding the need to make address changes and rehash atomic against lookups, reintroduce primary hash lookups as fallback, if lookups based on four-tuple and secondary hashes fail. To this end, introduce a simplified lookup implementation, which doesn't take care of SO_REUSEPORT groups: if we have one, there are multiple sockets that would match the four-tuple or secondary hash, meaning that we can't run into this race at all. v2: - instead of synchronising lookup operations against address change plus rehash, reintroduce a simplified version of the original primary hash lookup as fallback v1: - fix build with CONFIG_IPV6=n: add ifdef around sk_v6_rcv_saddr usage (Kuniyuki Iwashima) - directly use sk_rcv_saddr for IPv4 receive addresses instead of fetching inet_rcv_saddr (Kuniyuki Iwashima) - move inet_update_saddr() to inet_hashtables.h and use that to set IPv4/IPv6 addresses as suitable (Kuniyuki Iwashima) - rebase onto net-next, update commit message accordingly Reported-by: Ed Santiago <[email protected]> Link: https://github.com/containers/podman/issues/24147 Analysed-by: David Gibson <[email protected]> Fixes: 30fff9231fad ("udp: bind() optimisation") Signed-off-by: Stefano Brivio <[email protected]> Reviewed-by: Eric Dumazet <[email protected]> Reviewed-by: Willem de Bruijn <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Joe Hattori <[email protected]> Date: Thu Jan 9 09:16:38 2025 +0900 usb: dwc3-am62: Fix an OF node leak in phy_syscon_pll_refclk() commit a266462b937beba065e934a563efe13dd246a164 upstream. phy_syscon_pll_refclk() leaks an OF node obtained by of_parse_phandle_with_fixed_args(), thus add an of_node_put() call. Cc: stable <[email protected]> Fixes: e8784c0aec03 ("drivers: usb: dwc3: Add AM62 USB wrapper driver") Signed-off-by: Joe Hattori <[email protected]> Acked-by: Thinh Nguyen <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Kyle Tso <[email protected]> Date: Wed Jan 15 12:45:48 2025 +0800 usb: dwc3: core: Defer the probe until USB power supply ready commit 66e0ea341a2a78d14336117f19763bd9be26d45d upstream. Currently, DWC3 driver attempts to acquire the USB power supply only once during the probe. If the USB power supply is not ready at that time, the driver simply ignores the failure and continues the probe, leading to permanent non-functioning of the gadget vbus_draw callback. Address this problem by delaying the dwc3 driver initialization until the USB power supply is registered. Fixes: 6f0764b5adea ("usb: dwc3: add a power supply for current control") Cc: stable <[email protected]> Signed-off-by: Kyle Tso <[email protected]> Acked-by: Thinh Nguyen <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Ray Chi <[email protected]> Date: Mon Jan 6 16:22:37 2025 +0800 usb: dwc3: Skip resume if pm_runtime_set_active() fails commit e3a9bd247cddfb6fa0c29c2361f70b76c359eaa0 upstream. When the system begins to enter suspend mode, dwc3_suspend() is called by PM suspend. There is a problem that if someone interrupt the system suspend process between dwc3_suspend() and pm_suspend() of its parent device, PM suspend will be canceled and attempt to resume suspended devices so that dwc3_resume() will be called. However, dwc3 and its parent device (like the power domain or glue driver) may already be suspended by runtime PM in fact. If this sutiation happened, the pm_runtime_set_active() in dwc3_resume() will return an error since parent device was suspended. This can lead to unexpected behavior if DWC3 proceeds to execute dwc3_resume_common(). EX. RPM suspend: ... -> dwc3_runtime_suspend() -> rpm_suspend() of parent device ... PM suspend: ... -> dwc3_suspend() -> pm_suspend of parent device ^ interrupt, so resume suspended device ... <- dwc3_resume() <-/ ^ pm_runtime_set_active() returns error To prevent the problem, this commit will skip dwc3_resume_common() and return the error if pm_runtime_set_active() fails. Fixes: 68c26fe58182 ("usb: dwc3: set pm runtime active before resume common") Cc: stable <[email protected]> Signed-off-by: Ray Chi <[email protected]> Acked-by: Thinh Nguyen <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Thinh Nguyen <[email protected]> Date: Wed Dec 11 00:31:36 2024 +0000 usb: gadget: f_tcm: Don't free command immediately commit c225d006a31949d673e646d585d9569bc28feeb9 upstream. Don't prematurely free the command. Wait for the status completion of the sense status. It can be freed then. Otherwise we will double-free the command. Fixes: cff834c16d23 ("usb-gadget/tcm: Convert to TARGET_SCF_ACK_KREF I/O krefs") Cc: [email protected] Signed-off-by: Thinh Nguyen <[email protected]> Link: https://lore.kernel.org/r/ae919ac431f16275e05ec819bdffb3ac5f44cbe1.1733876548.git.Thinh.Nguyen@synopsys.com Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Thinh Nguyen <[email protected]> Date: Wed Dec 11 00:31:55 2024 +0000 usb: gadget: f_tcm: Fix Get/SetInterface return value commit 3b997089903b909684114aca6f79d683e5c64a0e upstream. Check to make sure that the GetInterface and SetInterface are for valid interface. Return proper alternate setting number on GetInterface. Fixes: 0b8b1a1fede0 ("usb: gadget: f_tcm: Provide support to get alternate setting in tcm function") Cc: [email protected] Signed-off-by: Thinh Nguyen <[email protected]> Link: https://lore.kernel.org/r/ffd91b4640945ea4d3b4f4091cf1abbdbd9cf4fc.1733876548.git.Thinh.Nguyen@synopsys.com Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Kyle Tso <[email protected]> Date: Tue Jan 14 22:24:35 2025 +0800 usb: typec: tcpci: Prevent Sink disconnection before vPpsShutdown in SPR PPS commit 4d27afbf256028a1f54363367f30efc8854433c3 upstream. The Source can drop its output voltage to the minimum of the requested PPS APDO voltage range when it is in Current Limit Mode. If this voltage falls within the range of vPpsShutdown, the Source initiates a Hard Reset and discharges Vbus. However, currently the Sink may disconnect before the voltage reaches vPpsShutdown, leading to unexpected behavior. Prevent premature disconnection by setting the Sink's disconnect threshold to the minimum vPpsShutdown value. Additionally, consider the voltage drop due to IR drop when calculating the appropriate threshold. This ensures a robust and reliable interaction between the Source and Sink during SPR PPS Current Limit Mode operation. Fixes: 4288debeaa4e ("usb: typec: tcpci: Fix up sink disconnect thresholds for PD") Cc: stable <[email protected]> Signed-off-by: Kyle Tso <[email protected]> Reviewed-by: Heikki Krogerus <[email protected]> Reviewed-by: Badhri Jagan Sridharan <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Jos Wang <[email protected]> Date: Sun Jan 5 21:52:45 2025 +0800 usb: typec: tcpm: set SRC_SEND_CAPABILITIES timeout to PD_T_SENDER_RESPONSE commit 2eb3da037c2c20fa30bc502bc092479b2a1aaae2 upstream. As PD2.0 spec ("8.3.3.2.3 PE_SRC_Send_Capabilities state"), after the Source receives the GoodCRC Message from the Sink in response to the Source_Capabilities message, it should start the SenderResponseTimer, after the timer times out, the state machine transitions to the HARD_RESET state. Fixes: f0690a25a140 ("staging: typec: USB Type-C Port Manager (tcpm)") Cc: [email protected] Signed-off-by: Jos Wang <[email protected]> Reviewed-by: Badhri Jagan Sridharan <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Michal Pecio <[email protected]> Date: Fri Dec 27 14:01:40 2024 +0200 usb: xhci: Fix NULL pointer dereference on certain command aborts commit 1e0a19912adb68a4b2b74fd77001c96cd83eb073 upstream. If a command is queued to the final usable TRB of a ring segment, the enqueue pointer is advanced to the subsequent link TRB and no further. If the command is later aborted, when the abort completion is handled the dequeue pointer is advanced to the first TRB of the next segment. If no further commands are queued, xhci_handle_stopped_cmd_ring() sees the ring pointers unequal and assumes that there is a pending command, so it calls xhci_mod_cmd_timer() which crashes if cur_cmd was NULL. Don't attempt timer setup if cur_cmd is NULL. The subsequent doorbell ring likely is unnecessary too, but it's harmless. Leave it alone. This is probably Bug 219532, but no confirmation has been received. The issue has been independently reproduced and confirmed fixed using a USB MCU programmed to NAK the Status stage of SET_ADDRESS forever. Everything continued working normally after several prevented crashes. Link: https://bugzilla.kernel.org/show_bug.cgi?id=219532 Fixes: c311e391a7ef ("xhci: rework command timeout and cancellation,") CC: [email protected] Signed-off-by: Michal Pecio <[email protected]> Signed-off-by: Mathias Nyman <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Michal Luczaj <[email protected]> Date: Tue Jan 28 14:15:28 2025 +0100 vsock: Allow retrying on connect() failure [ Upstream commit aa388c72113b7458127b709bdd7d3628af26e9b4 ] sk_err is set when a (connectible) connect() fails. Effectively, this makes an otherwise still healthy SS_UNCONNECTED socket impossible to use for any subsequent connection attempts. Clear sk_err upon trying to establish a connection. Fixes: d021c344051a ("VSOCK: Introduce VM Sockets") Reviewed-by: Stefano Garzarella <[email protected]> Reviewed-by: Luigi Leonardi <[email protected]> Signed-off-by: Michal Luczaj <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Shigeru Yoshida <[email protected]> Date: Thu Jan 23 23:57:46 2025 +0900 vxlan: Fix uninit-value in vxlan_vnifilter_dump() [ Upstream commit 5066293b9b7046a906eff60e3949a887ae185a43 ] KMSAN reported an uninit-value access in vxlan_vnifilter_dump() [1]. If the length of the netlink message payload is less than sizeof(struct tunnel_msg), vxlan_vnifilter_dump() accesses bytes beyond the message. This can lead to uninit-value access. Fix this by returning an error in such situations. [1] BUG: KMSAN: uninit-value in vxlan_vnifilter_dump+0x328/0x920 drivers/net/vxlan/vxlan_vnifilter.c:422 vxlan_vnifilter_dump+0x328/0x920 drivers/net/vxlan/vxlan_vnifilter.c:422 rtnl_dumpit+0xd5/0x2f0 net/core/rtnetlink.c:6786 netlink_dump+0x93e/0x15f0 net/netlink/af_netlink.c:2317 __netlink_dump_start+0x716/0xd60 net/netlink/af_netlink.c:2432 netlink_dump_start include/linux/netlink.h:340 [inline] rtnetlink_dump_start net/core/rtnetlink.c:6815 [inline] rtnetlink_rcv_msg+0x1256/0x14a0 net/core/rtnetlink.c:6882 netlink_rcv_skb+0x467/0x660 net/netlink/af_netlink.c:2542 rtnetlink_rcv+0x35/0x40 net/core/rtnetlink.c:6944 netlink_unicast_kernel net/netlink/af_netlink.c:1321 [inline] netlink_unicast+0xed6/0x1290 net/netlink/af_netlink.c:1347 netlink_sendmsg+0x1092/0x1230 net/netlink/af_netlink.c:1891 sock_sendmsg_nosec net/socket.c:711 [inline] __sock_sendmsg+0x330/0x3d0 net/socket.c:726 ____sys_sendmsg+0x7f4/0xb50 net/socket.c:2583 ___sys_sendmsg+0x271/0x3b0 net/socket.c:2637 __sys_sendmsg net/socket.c:2669 [inline] __do_sys_sendmsg net/socket.c:2674 [inline] __se_sys_sendmsg net/socket.c:2672 [inline] __x64_sys_sendmsg+0x211/0x3e0 net/socket.c:2672 x64_sys_call+0x3878/0x3d90 arch/x86/include/generated/asm/syscalls_64.h:47 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xd9/0x1d0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f Uninit was created at: slab_post_alloc_hook mm/slub.c:4110 [inline] slab_alloc_node mm/slub.c:4153 [inline] kmem_cache_alloc_node_noprof+0x800/0xe80 mm/slub.c:4205 kmalloc_reserve+0x13b/0x4b0 net/core/skbuff.c:587 __alloc_skb+0x347/0x7d0 net/core/skbuff.c:678 alloc_skb include/linux/skbuff.h:1323 [inline] netlink_alloc_large_skb+0xa5/0x280 net/netlink/af_netlink.c:1196 netlink_sendmsg+0xac9/0x1230 net/netlink/af_netlink.c:1866 sock_sendmsg_nosec net/socket.c:711 [inline] __sock_sendmsg+0x330/0x3d0 net/socket.c:726 ____sys_sendmsg+0x7f4/0xb50 net/socket.c:2583 ___sys_sendmsg+0x271/0x3b0 net/socket.c:2637 __sys_sendmsg net/socket.c:2669 [inline] __do_sys_sendmsg net/socket.c:2674 [inline] __se_sys_sendmsg net/socket.c:2672 [inline] __x64_sys_sendmsg+0x211/0x3e0 net/socket.c:2672 x64_sys_call+0x3878/0x3d90 arch/x86/include/generated/asm/syscalls_64.h:47 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xd9/0x1d0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f CPU: 0 UID: 0 PID: 30991 Comm: syz.4.10630 Not tainted 6.12.0-10694-gc44daa7e3c73 #29 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-3.fc41 04/01/2014 Fixes: f9c4bb0b245c ("vxlan: vni filtering support on collect metadata device") Reported-by: syzkaller <[email protected]> Signed-off-by: Shigeru Yoshida <[email protected]> Reviewed-by: Ido Schimmel <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Joe Hattori <[email protected]> Date: Sun Jan 5 20:17:18 2025 +0900 watchdog: rti_wdt: Fix an OF node leak in rti_wdt_probe() [ Upstream commit 143981aa63f33d469a55a55fd9fb81cd90109672 ] rti_wdt_probe() does not release the OF node reference obtained by of_parse_phandle(). Add a of_node_put() call. This was found by an experimental verification tool that I am developing. Due to the lack of the actual device, no runtime test was able to be performed. Fixes: f20ca595ae23 ("watchdog:rit_wdt: Add support for WDIOF_CARDRESET") Signed-off-by: Joe Hattori <[email protected]> Reviewed-by: Guenter Roeck <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Guenter Roeck <[email protected]> Signed-off-by: Wim Van Sebroeck <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Balaji Pothunoori <[email protected]> Date: Wed Oct 30 17:16:25 2024 +0530 wifi: ath11k: Fix unexpected return buffer manager error for WCN6750/WCN6855 [ Upstream commit 78e154d42f2c72905fe66a400847e1b2b101b7b2 ] The following error messages were encountered while parsing fragmented RX packets for WCN6750/WCN6855: ath11k 17a10040.wifi: invalid return buffer manager 4 This issue arose due to a hardcoded check for HAL_RX_BUF_RBM_SW3_BM introduced in 'commit 71c748b5e01e ("ath11k: Fix unexpected return buffer manager error for QCA6390")' For WCN6750 and WCN6855, the return buffer manager ID should be HAL_RX_BUF_RBM_SW1_BM. The incorrect conditional check caused fragmented packets to be dropped, resulting in the above error log. Fix this by adding a check for HAL_RX_BUF_RBM_SW1_BM. Tested-on: WCN6750 hw1.0 AHB WLAN.MSL.2.0.c2-00258-QCAMSLSWPL-1 Tested-on: WCN6855 hw2.1 WLAN.HSP.1.1-04479-QCAHSPSWPL_V1_V2_SILICONZ_IOE-1 Fixes: 71c748b5e01e ("ath11k: Fix unexpected return buffer manager error for QCA6390") Signed-off-by: Balaji Pothunoori <[email protected]> Acked-by: Jeff Johnson <[email protected]> Acked-by: Kalle Valo <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jeff Johnson <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Aditya Kumar Singh <[email protected]> Date: Sun Jan 12 11:23:00 2025 +0530 wifi: ath12k: fix key cache handling [ Upstream commit 336097d74c284a7c928b723ce8690f28912da03d ] Currently, an interface is created in the driver during channel assignment. If mac80211 attempts to set a key for an interface before this assignment, the driver caches the key. Once the interface is created, the driver installs the cached key to the hardware. This sequence is exemplified in mesh mode operation where the group key is set before channel assignment. However, in ath12k_mac_update_key_cache(), after caching the key, due to incorrect logic, it is deleted from the cache during the subsequent loop iteration. As a result, after the interface is created, the driver does not find any cached key, and the key is not installed to the hardware which is wrong. This leads to issue in mesh, where broadcast traffic is not encrypted over the air. Fix this issue by adjusting the logic of ath12k_mac_update_key_cache() properly. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.3.1-00173-QCAHKSWPL_SILICONZ-1 Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.3-03253.1-QCAHKSWPL_SILICONZ-29 # Nicolas Escande <[email protected]> Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.3.1-00173-QCAHKSWPL_SILICONZ-1 # Nicolas Escande <[email protected]> Fixes: 25e18b9d6b4b ("wifi: ath12k: modify ath12k_mac_op_set_key() for MLO") Signed-off-by: Aditya Kumar Singh <[email protected]> Acked-by: Kalle Valo <[email protected]> Tested-by: Nicolas Escande <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jeff Johnson <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Aditya Kumar Singh <[email protected]> Date: Tue Dec 10 10:56:33 2024 +0530 wifi: ath12k: fix read pointer after free in ath12k_mac_assign_vif_to_vdev() [ Upstream commit 5a10971c7645a95f5d5dc23c26fbac4bf61801d0 ] In ath12k_mac_assign_vif_to_vdev(), if arvif is created on a different radio, it gets deleted from that radio through a call to ath12k_mac_unassign_link_vif(). This action frees the arvif pointer. Subsequently, there is a check involving arvif, which will result in a read-after-free scenario. Fix this by moving this check after arvif is again assigned via call to ath12k_mac_assign_link_vif(). Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.3.1-00173-QCAHKSWPL_SILICONZ-1 Closes: https://scan5.scan.coverity.com/#/project-view/63541/10063?selectedIssue=1636423 Fixes: b5068bc9180d ("wifi: ath12k: Cache vdev configs before vdev create") Signed-off-by: Aditya Kumar Singh <[email protected]> Acked-by: Jeff Johnson <[email protected]> Acked-by: Kalle Valo <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jeff Johnson <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Sathishkumar Muruganandam <[email protected]> Date: Mon Sep 9 13:00:49 2024 +0530 wifi: ath12k: fix tx power, max reg power update to firmware [ Upstream commit 3540bba855b4b422e8b977d11aa8173ccb4f089d ] Currently, when the vdev start WMI cmd is sent from host, vdev related parameters such as max_reg_power, max_power, and max_antenna_gain are multiplied by 2 before being sent to the firmware. This is incorrect because the firmware uses 1 dBm steps for power calculations. This leads to incorrect power values being used in the firmware and radio, potentially causing incorrect behavior. Fix the update of max_reg_power, max_power, and max_antenna_gain values in the ath12k_mac_vdev_start_restart function, ensuring accurate power settings in the firmware by sending these values as-is, without multiplication. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.1.1-00214-QCAHKSWPL_SILICONZ-1 Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3 Signed-off-by: Sathishkumar Muruganandam <[email protected]> Signed-off-by: Santhosh Ramesh <[email protected]> Fixes: d889913205cf ("wifi: ath12k: driver for Qualcomm Wi-Fi 7 devices") Acked-by: Kalle Valo <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jeff Johnson <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Marcel Hamer <[email protected]> Date: Wed Dec 11 14:36:18 2024 +0100 wifi: brcmfmac: add missing header include for brcmf_dbg [ Upstream commit b05d30c2b6df7e2172b18bf1baee9b202f9c6b53 ] Including the fwil.h header file can lead to a build error: drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwil.h: \ In function ‘brcmf_fil_cmd_int_set’: drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwil.h:90:9: error: implicit \ declaration of function ‘brcmf_dbg’ [-Werror=implicit-function-declaration] 90 | brcmf_dbg(FIL, "ifidx=%d, cmd=%d, value=%d\n", ifp->ifidx, cmd, data); | ^~~~~~~~~ The error is often avoided because the debug.h header file is included before the fwil.h header file. This makes sure the header include order is irrelevant by explicitly adding the debug.h header. Fixes: 31343230abb1 ("wifi: brcmfmac: export firmware interface functions") Signed-off-by: Marcel Hamer <[email protected]> Acked-by: Arend van Spriel <[email protected]> Signed-off-by: Kalle Valo <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Dmitry Antipov <[email protected]> Date: Mon Jan 13 18:54:17 2025 +0300 wifi: cfg80211: adjust allocation of colocated AP data [ Upstream commit 1a0d24775cdee2b8dc14bfa4f4418c930ab1ac57 ] In 'cfg80211_scan_6ghz()', an instances of 'struct cfg80211_colocated_ap' are allocated as if they would have 'ssid' as trailing VLA member. Since this is not so, extra IEEE80211_MAX_SSID_LEN bytes are not needed. Briefly tested with KUnit. Fixes: c8cb5b854b40 ("nl80211/cfg80211: support 6 GHz scanning") Signed-off-by: Dmitry Antipov <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Johannes Berg <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Kees Cook <[email protected]> Date: Mon Dec 30 10:36:14 2024 -0800 wifi: cfg80211: Move cfg80211_scan_req_add_chan() n_channels increment earlier [ Upstream commit 3a0168626c138734490bc52c4105ce8e79d2f923 ] Since adding __counted_by(n_channels) to struct cfg80211_scan_request, anything adding to the channels array must increment n_channels first. Move n_channels increment earlier. Reported-by: John Rowley <[email protected]> Closes: https://lore.kernel.org/stable/1815535c709ba9d9.156c6a5c9cdf6e59.b249b6b6a5ee4634@localhost.localdomain/ Fixes: aa4ec06c455d ("wifi: cfg80211: use __counted_by where appropriate") Signed-off-by: Kees Cook <[email protected]> Reviewed-by: Gustavo A. R. Silva <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Johannes Berg <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Zichen Xie <[email protected]> Date: Fri Nov 15 00:38:36 2024 -0600 wifi: cfg80211: tests: Fix potential NULL dereference in test_cfg80211_parse_colocated_ap() [ Upstream commit 13c4f7714c6a1ecf748a2f22099447c14fe6ed8c ] kunit_kzalloc() may return NULL, dereferencing it without NULL check may lead to NULL dereference. Add a NULL check for ies. Fixes: 45d43937a44c ("wifi: cfg80211: add a kunit test for 6 GHz colocated AP parsing") Signed-off-by: Zichen Xie <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Johannes Berg <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Johannes Berg <[email protected]> Date: Fri Dec 27 10:01:01 2024 +0200 wifi: iwlwifi: fw: read STEP table from correct UEFI var [ Upstream commit 80c2b651fe7fc82e1d1b3e4f9651095896a095f0 ] This variable exists for the "common" (WiFi/BT) GUID, not the WiFi-only GUID. Fix that by passing the GUID to the function. A short-cut for the wifi-only version remains so not all code must be updated. However, rename the GUID defines to be clearer. Fixes: 09b4c35d73a5 ("wifi: iwlwifi: mvm: Support STEP equalizer settings from BIOS.") Signed-off-by: Johannes Berg <[email protected]> Reviewed-by: Daniel Gabay <[email protected]> Signed-off-by: Miri Korenblit <[email protected]> Link: https://patch.msgid.link/20241227095718.89a5ad921b6d.Idae95a70ff69d2ba1b610e8eced826961ce7de98@changeid Signed-off-by: Johannes Berg <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Miri Korenblit <[email protected]> Date: Sun Dec 29 16:44:36 2024 +0200 wifi: iwlwifi: mvm: avoid NULL pointer dereference [ Upstream commit cf704a7624f99eb2ffca1a16c69183e85544a613 ] When iterating over the links of a vif, we need to make sure that the pointer is valid (in other words - that the link exists) before dereferncing it. Use for_each_vif_active_link that also does the check. Fixes: 2b7ee1a10a72 ("wifi: iwlwiif: mvm: handle the new BT notif") Signed-off-by: Miri Korenblit <[email protected]> Reviewed-by: Emmanuel Grumbach <[email protected]> Link: https://patch.msgid.link/20241229164246.31d41f7d3eab.I7fb7036a0b187c1636b01970207259cb2327952c@changeid Signed-off-by: Johannes Berg <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Daniel Gabay <[email protected]> Date: Sun Dec 29 16:44:38 2024 +0200 wifi: iwlwifi: mvm: don't count mgmt frames as MPDU [ Upstream commit 76260267ba26a6e513acefa5e7de1200fbeb5b5d ] When handling TX_CMD notification, for mgmt frames tid is equal to IWL_MAX_TID_COUNT, so with the current logic we'll count that as MPDU, fix that. Fixes: ec0d43d26f2c ("wifi: iwlwifi: mvm: Activate EMLSR based on traffic volume") Signed-off-by: Daniel Gabay <[email protected]> Signed-off-by: Miri Korenblit <[email protected]> Link: https://patch.msgid.link/20241229164246.80b119bb5d08.I31b1e8ba25cce15819225e5ac80332e4eaa20c13@changeid Signed-off-by: Johannes Berg <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Emmanuel Grumbach <[email protected]> Date: Sun Dec 29 16:44:42 2024 +0200 wifi: iwlwifi: mvm: remove unneeded NULL pointer checks [ Upstream commit 79f4b6934dbd7dd6741726ba004a15e25380b8cc ] Smatch reported that we dereference the data pointer to calculate the expected length before we check it's not NULL. While this is true (and hence needs to be fixed), this will never happen because the data pointer comes from struct iwl_rx_packet object which has the following layout: struct iwl_rx_packet { __le32 len_n_flags; struct iwl_cmd_header hdr; u8 data[]; } __packed; So, if the pointer to iwl_rx_packet is valid, data will be valid as well. Remove the NULL pointer check on 'data' to avoid confusing smatch. Also remove the check from similar functions in the same flow that were cargo cult copy-pasted. Fixes: 4635e6eaa0fe ("wifi: iwlwifi: mvm: support new versions of the wowlan APIs") Reported-by: kernel test robot <[email protected]> Reported-by: Dan Carpenter <[email protected]> Closes: https://lore.kernel.org/r/[email protected]/ Signed-off-by: Emmanuel Grumbach <[email protected]> Reviewed-by: Johannes Berg <[email protected]> Signed-off-by: Miri Korenblit <[email protected]> Link: https://patch.msgid.link/20241229164246.c8ce6e041e4b.I4dc19289e3f3807386768c846e08be3ea322cd15@changeid Signed-off-by: Johannes Berg <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Johannes Berg <[email protected]> Date: Thu Jan 2 16:20:06 2025 +0200 wifi: mac80211: don't flush non-uploaded STAs [ Upstream commit aa3ce3f8fafa0b8fb062f28024855ea8cb3f3450 ] If STA state is pre-moved to AUTHORIZED (such as in IBSS scenarios) and insertion fails, the station is freed. In this case, the driver never knew about the station, so trying to flush it is unexpected and may crash. Check if the sta was uploaded to the driver before and fix this. Fixes: d00800a289c9 ("wifi: mac80211: add flush_sta method") Signed-off-by: Johannes Berg <[email protected]> Signed-off-by: Miri Korenblit <[email protected]> Link: https://patch.msgid.link/20250102161730.e3d10970a7c7.I491bbcccc46f835ade07df0640a75f6ed92f20a3@changeid Signed-off-by: Johannes Berg <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Ilan Peer <[email protected]> Date: Thu Jan 2 16:20:00 2025 +0200 wifi: mac80211: Fix common size calculation for ML element [ Upstream commit 19aa842dcbb5860509b7e1b7745dbae0b791f6c4 ] When the ML type is EPCS the control bitmap is reserved, the length is always 7 and is captured by the 1st octet after the control. Fixes: 0f48b8b88aa9 ("wifi: ieee80211: add definitions for multi-link element") Signed-off-by: Ilan Peer <[email protected]> Reviewed-by: Johannes Berg <[email protected]> Signed-off-by: Miri Korenblit <[email protected]> Link: https://patch.msgid.link/20250102161730.5790376754a7.I381208cbb72b1be2a88239509294099e9337e254@changeid Signed-off-by: Johannes Berg <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Andy Strohman <[email protected]> Date: Tue Jan 7 10:44:31 2025 +0000 wifi: mac80211: fix tid removal during mesh forwarding [ Upstream commit 3aaa1a5a9a2ceeb32afa6ea4110a92338a863c33 ] With change (wifi: mac80211: fix receiving A-MSDU frames on mesh interfaces), a non-zero TID assignment is lost during slow path mesh forwarding. Prior to this change, ieee80211_rx_h_mesh_fwding() left the TID intact in the header. As a result of this header corruption, packets belonging to non-zero TIDs will get treating as belonging TID 0 by functions such as ieee80211_get_tid(). While this miscategorization by itself is an issue, there are additional ramifications due to the fact that skb->priority still reflects the mesh forwarded packet's ingress (correct) TID. The mt7915 driver inspects the TID recorded within skb->priority and relays this to the hardware/radio during TX. The radio firmware appears to react to this by changing the sequence control header, but it does not also ensure/correct the TID in the QoS control header. As a result, the receiver will see packets with sequence numbers corresponding to the wrong TID. The receiver of the forwarded packet will see TID 0 in QoS control but a sequence number corresponding to the correct (different) TID in sequence control. This causes data stalls for TID 0 until the TID 0 sequence number advances past what the receiver believes it should be due to this bug. Mesh routing mpath changes cause a brief transition from fast path forwarding to slow path forwarding. Since this bug only affects the slow path forwarding, mpath changes bring opportunity for the bug to be triggered. In the author's case, he was experiencing TID 0 data stalls after mpath changes on an intermediate mesh node. These observed stalls may be specific to mediatek radios. But the inconsistency between the packet header and skb->priority may cause problems for other drivers as well. Regardless if this causes connectivity issues on other radios, this change is necessary in order transmit (forward) the packet on the correct TID and to have a consistent view a packet's TID within mac80211. Fixes: 986e43b19ae9 ("wifi: mac80211: fix receiving A-MSDU frames on mesh interfaces") Signed-off-by: Andy Strohman <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Johannes Berg <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Johannes Berg <[email protected]> Date: Mon Dec 30 09:14:07 2024 +0100 wifi: mac80211: prohibit deactivating all links [ Upstream commit 7553477cbfd784b128297f9ed43751688415bbaa ] In the internal API this calls this is a WARN_ON, but that should remain since internally we want to know about bugs that may cause this. Prevent deactivating all links in the debugfs write directly. Reported-by: [email protected] Fixes: 3d9011029227 ("wifi: mac80211: implement link switching") Signed-off-by: Johannes Berg <[email protected]> Link: https://patch.msgid.link/20241230091408.505bd125c35a.Ic3c1f9572b980a952a444cad62b09b9c6721732b@changeid Signed-off-by: Johannes Berg <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Sean Wang <[email protected]> Date: Tue Dec 10 17:19:10 2024 -0800 wifi: mt76: connac: Extend mt76_connac_mcu_uni_add_dev for MLO [ Upstream commit 9e4c3a007f01f567f2a8af35decd1e3c1c151c0f ] This commit extends the `mt76_connac_mcu_uni_add_dev` function to include support for Multi-Link Operation (MLO). Additionally, backward compatibility for MT7921 is preserved, enabling seamless integration with existing setups. Fixes: 86c051f2c418 ("wifi: mt76: mt7925: enabling MLO when the firmware supports it") Signed-off-by: Sean Wang <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Felix Fietkau <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Ming Yen Hsieh <[email protected]> Date: Tue Dec 10 17:19:18 2024 -0800 wifi: mt76: Enhance mt7925_mac_link_sta_add to support MLO [ Upstream commit e6803d39a8aa59e557402a541a97ee04b06c49b2 ] Enhance mt7925_mac_link_sta_add to support MLO. Fixes: 86c051f2c418 ("wifi: mt76: mt7925: enabling MLO when the firmware supports it") Signed-off-by: Ming Yen Hsieh <[email protected]> Signed-off-by: Sean Wang <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Felix Fietkau <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: WangYuli <[email protected]> Date: Mon Jan 13 15:02:41 2025 +0800 wifi: mt76: mt76u_vendor_request: Do not print error messages when -EPROTO [ Upstream commit f1b1e133a770fcdbd89551651232b034d2f7a27a ] When initializing the network card, unplugging the device will trigger an -EPROTO error, resulting in a flood of error messages being printed frantically. The exception is printed as follows： mt76x2u 2-2.4:1.0: vendor request req:47 off:9018 failed:-71 mt76x2u 2-2.4:1.0: vendor request req:47 off:9018 failed:-71 ... It will continue to print more than 2000 times for about 5 minutes, causing the usb device to be unable to be disconnected. During this period, the usb port cannot recognize the new device because the old device has not disconnected. There may be other operating methods that cause -EPROTO, but -EPROTO is a low-level hardware error. It is unwise to repeat vendor requests expecting to read correct data. It is a better choice to treat -EPROTO and -ENODEV the same way. Similar to commit 9b0f100c1970 ("mt76: usb: process URBs with status EPROTO properly") do no schedule rx_worker for urb marked with status set -EPROTO. I also reproduced this situation when plugging and unplugging the device, and this patch is effective. Just do not vendor request again for urb marked with status set -EPROTO. Link: https://lore.kernel.org/all/[email protected]/ Link: https://lore.kernel.org/all/[email protected]/ Fixes: b40b15e1521f ("mt76: add usb support to mt76 layer") Co-developed-by: Xu Rao <[email protected]> Signed-off-by: Xu Rao <[email protected]> Signed-off-by: WangYuli <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Felix Fietkau <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Felix Fietkau <[email protected]> Date: Mon Dec 30 20:41:59 2024 +0100 wifi: mt76: mt7915: firmware restart on devices with a second pcie link [ Upstream commit 9b60e2ae511c959024ecf6578b3fbe85cd06d7cc ] It seems that the firmware checks the register used for detecting matching PCIe links in order to figure out if a secondary PCIe link is enabled. Write the register again just before starting the firmware on hw reset, in order to fix an issue that left the second band unusable after restart. Fixes: 9093cfff72e3 ("mt76: mt7915: add support for using a secondary PCIe link for gen1") Link: https://patch.msgid.link/[email protected] Signed-off-by: Felix Fietkau <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Christophe JAILLET <[email protected]> Date: Sun Sep 29 21:53:40 2024 +0200 wifi: mt76: mt7915: Fix an error handling path in mt7915_add_interface() [ Upstream commit 126a516fe30639708e759678bcb10178938cc718 ] If mt76_wcid_alloc() fails, the "mt76.mutex" mutex needs to be released as done in the other error handling paths of mt7915_add_interface(). Fixes: f3049b88b2b3 ("wifi: mt76: mt7915: allocate vif wcid in the same range as stations") Signed-off-by: Christophe JAILLET <[email protected]> Link: https://patch.msgid.link/b9d8fbfc19360bfe60b9cea1cb0f735ab3b4bc26.1727639596.git.christophe.jaillet@wanadoo.fr Signed-off-by: Felix Fietkau <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Nicolas Cavallari <[email protected]> Date: Fri Sep 27 10:53:17 2024 +0200 wifi: mt76: mt7915: Fix mesh scan on MT7916 DBDC [ Upstream commit f21b77cb556296116b1cce1d62295d13e35da574 ] commit c4f075582304 ("wifi: mt76: mt7915: fix command timeout in AP stop period") changes the behavior of mt7915_bss_info_changed() in mesh mode when enable_beacon becomes false: it calls mt7915_mcu_add_bss_info(..., false) and mt7915_mcu_add_sta(..., false) while the previous code didn't. These sends mcu commands that apparently confuse the firmware. This breaks scanning while in mesh mode on AsiaRF MT7916 DBDC-based cards: scanning works but no mesh frames get sent afterwards and the firmware seems to be hosed. It breaks on MT7916 DBDC but not on MT7915 DBDC. Fixes: c4f075582304 ("wifi: mt76: mt7915: fix command timeout in AP stop period") Signed-off-by: Nicolas Cavallari <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Felix Fietkau <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Felix Fietkau <[email protected]> Date: Mon Dec 30 20:42:00 2024 +0100 wifi: mt76: mt7915: fix omac index assignment after hardware reset [ Upstream commit cd043bbba6f9b71ebe0781d1bd2107565363c4b9 ] Reset per-phy mac address slot mask in order to avoid leaking entries. Fixes: 8a55712d124f ("wifi: mt76: mt7915: enable full system reset support") Link: https://patch.msgid.link/[email protected] Signed-off-by: Felix Fietkau <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: xueqin Luo <[email protected]> Date: Mon Dec 2 11:19:17 2024 +0800 wifi: mt76: mt7915: fix overflows seen when writing limit attributes [ Upstream commit 64d571742b0ae44eee5efd51e2d4a09d7f6782fc ] DIV_ROUND_CLOSEST() after kstrtoul() results in an overflow if a large number such as 18446744073709551615 is provided by the user. Fix it by reordering clamp_val() and DIV_ROUND_CLOSEST() operations. This commit was inspired by commit: 57ee12b6c514. Fixes: 02ee68b95d81 ("mt76: mt7915: add control knobs for thermal throttling") Signed-off-by: xueqin Luo <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Felix Fietkau <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Peter Chiu <[email protected]> Date: Thu Jan 9 19:04:35 2025 +0800 wifi: mt76: mt7915: fix register mapping [ Upstream commit dd1649ef966bb87053c17385ea2cfd1758f5385b ] Bypass the entry when ofs is equal to dev->reg.map[i].size. Without this patch, it would get incorrect register mapping when the CR address is located at the boundary of an entry. Fixes: cd4c314a65d3 ("mt76: mt7915: refine register definition") Signed-off-by: Peter Chiu <[email protected]> Signed-off-by: Shengyu Qu <[email protected]> Link: https://patch.msgid.link/OSZPR01MB843401EAA1DA6BD7AEF356F298132@OSZPR01MB8434.jpnprd01.prod.outlook.com Signed-off-by: Felix Fietkau <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Michael Lo <[email protected]> Date: Thu Aug 1 10:43:35 2024 +0800 wifi: mt76: mt7921: fix using incorrect group cipher after disconnection. [ Upstream commit aa566ac6b7272e7ea5359cb682bdca36d2fc7e73 ] To avoid incorrect cipher after disconnection, we should do the key deletion process in this case. Fixes: e6db67fa871d ("wifi: mt76: ignore key disable commands") Signed-off-by: Michael Lo <[email protected]> Signed-off-by: Ming Yen Hsieh <[email protected]> Tested-by: David Ruth <[email protected]> Reviewed-by: David Ruth <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Felix Fietkau <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Ming Yen Hsieh <[email protected]> Date: Tue Dec 10 17:19:25 2024 -0800 wifi: mt76: mt7925: Cleanup MLO settings post-disconnection [ Upstream commit 816161051a039eeb1226fc85e2b38389f508906c ] Clean up MLO settings after disconnection. Fixes: 86c051f2c418 ("wifi: mt76: mt7925: enabling MLO when the firmware supports it") Signed-off-by: Ming Yen Hsieh <[email protected]> Signed-off-by: Sean Wang <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Felix Fietkau <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Ming Yen Hsieh <[email protected]> Date: Tue Dec 10 17:19:17 2024 -0800 wifi: mt76: mt7925: Enhance mt7925_mac_link_bss_add to support MLO [ Upstream commit ac03e5b82bc6b44e8ea3e7c7c624ee1445ff4e4b ] In mt7925_mac_link_bss_add(), the mt76_connac_mcu_uni_add_dev() function must be executed only after all parameters have been properly initialized. Fixes: 86c051f2c418 ("wifi: mt76: mt7925: enabling MLO when the firmware supports it") Signed-off-by: Ming Yen Hsieh <[email protected]> Signed-off-by: Sean Wang <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Felix Fietkau <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Leon Yen <[email protected]> Date: Tue Dec 10 17:19:16 2024 -0800 wifi: mt76: mt7925: Fix CNM Timeout with Single Active Link in MLO [ Upstream commit 4a596010b246816d7589d8d775b83833a59e63f9 ] Fix CNM command timeout issue when only a single active link is available during MLO connection to fix the following kernel log error. [ 741.931030] wlan0: [link 1] local address be:90:e0:22:c4:22, AP link address 08:0c:43:7a:19:2a [ 741.931042] wlan0: [link 1] determined AP 08:0c:43:7a:19:2a to be EHT [ 741.931052] wlan0: [link 1] connecting with EHT mode, max bandwidth 160 MHz [ 741.931071] wlan0: WMM AC=0 acm=0 aifs=2 cWmin=3 cWmax=7 txop=47 uapsd=0, downgraded=0 [ 741.931076] wlan0: WMM AC=1 acm=0 aifs=2 cWmin=7 cWmax=15 txop=94 uapsd=0, downgraded=0 [ 741.931080] wlan0: WMM AC=2 acm=0 aifs=3 cWmin=15 cWmax=1023 txop=0 uapsd=0, downgraded=0 [ 741.931085] wlan0: WMM AC=3 acm=0 aifs=7 cWmin=15 cWmax=1023 txop=0 uapsd=0, downgraded=0 [ 741.931095] wlan0: moving STA 22:0c:43:7a:19:2a to state 3 [ 749.090928] mt7925e 0000:2b:00.0: Message 00020002 (seq 15) timeout [ 752.162972] mt7925e 0000:2b:00.0: Message 00020003 (seq 1) timeout [ 755.234975] mt7925e 0000:2b:00.0: Message 00020002 (seq 2) timeout [ 758.306971] mt7925e 0000:2b:00.0: Message 00020004 (seq 3) timeout Fixes: 86c051f2c418 ("wifi: mt76: mt7925: enabling MLO when the firmware supports it") Signed-off-by: Leon Yen <[email protected]> Signed-off-by: Sean Wang <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Felix Fietkau <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Ming Yen Hsieh <[email protected]> Date: Mon Nov 4 13:14:47 2024 +0800 wifi: mt76: mt7925: fix get wrong chip cap from incorrect pointer [ Upstream commit 4d264f31b3074d361f65702dd7969861bcf1c158 ] Use tlv instead of skb, because using skb will get valid data with wrong offset. Fixes: 86c051f2c418 ("wifi: mt76: mt7925: enabling MLO when the firmware supports it") Signed-off-by: Ming Yen Hsieh <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Felix Fietkau <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Ming Yen Hsieh <[email protected]> Date: Tue Dec 10 17:19:11 2024 -0800 wifi: mt76: mt7925: Fix incorrect MLD address in bss_mld_tlv for MLO support [ Upstream commit 4d5427443595439c6cf5edfd9fb7224589f65b27 ] For this TLV, the address should be set to the MLD address rather than the link address. Fixes: 86c051f2c418 ("wifi: mt76: mt7925: enabling MLO when the firmware supports it") Signed-off-by: Ming Yen Hsieh <[email protected]> Signed-off-by: Sean Wang <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Felix Fietkau <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Ming Yen Hsieh <[email protected]> Date: Tue Dec 10 17:19:12 2024 -0800 wifi: mt76: mt7925: Fix incorrect WCID assignment for MLO [ Upstream commit 4911e4cb157cf87d5bdb3fa8e0c200032443371e ] For MLO, each link must have a corresponding WCID. Fixes: 86c051f2c418 ("wifi: mt76: mt7925: enabling MLO when the firmware supports it") Signed-off-by: Ming Yen Hsieh <[email protected]> Signed-off-by: Sean Wang <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Felix Fietkau <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: allan.wang <[email protected]> Date: Tue Dec 10 17:19:14 2024 -0800 wifi: mt76: mt7925: Fix incorrect WCID phy_idx assignment [ Upstream commit 4f741a2378b27a6be5e63b829cae4eb9cf2484e7 ] Fix incorrect WCID phy_idx assignment. Fixes: 86c051f2c418 ("wifi: mt76: mt7925: enabling MLO when the firmware supports it") Signed-off-by: allan.wang <[email protected]> Signed-off-by: Sean Wang <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Felix Fietkau <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Charles Han <[email protected]> Date: Fri Oct 25 15:55:54 2024 +0800 wifi: mt76: mt7925: fix NULL deref check in mt7925_change_vif_links [ Upstream commit 5cd0bd815c8a48862a296df9b30e0ea0da14acd3 ] In mt7925_change_vif_links() devm_kzalloc() may return NULL but this returned value is not checked. Fixes: 69acd6d910b0 ("wifi: mt76: mt7925: add mt7925_change_vif_links") Signed-off-by: Charles Han <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Felix Fietkau <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Dan Carpenter <[email protected]> Date: Wed Sep 11 10:43:03 2024 +0300 wifi: mt76: mt7925: fix off by one in mt7925_load_clc() [ Upstream commit 08fa656c91fd5fdf47ba393795b9c0d1e97539ed ] This comparison should be >= instead of > to prevent an out of bounds read and write. Fixes: 9679ca7326e5 ("wifi: mt76: mt7925: fix a potential array-index-out-of-bounds issue for clc") Signed-off-by: Dan Carpenter <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Felix Fietkau <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Ming Yen Hsieh <[email protected]> Date: Thu Nov 7 13:30:05 2024 +0800 wifi: mt76: mt7925: fix the invalid ip address for arp offload [ Upstream commit 113d469e7e23579a64b0fbb2eadf9228763092be ] The wrong ieee80211_vif will lead to get invalid ip address and the correct ieee80211_vif can be obtained from ieee80211_bss_conf. Fixes: 147324292979 ("wifi: mt76: mt7925: add link handling in the BSS_CHANGED_ARP_FILTER handler") Signed-off-by: Ming Yen Hsieh <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Felix Fietkau <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Eric-SY Chang <[email protected]> Date: Fri Nov 1 15:43:40 2024 +0800 wifi: mt76: mt7925: fix wrong band_idx setting when enable sniffer mode [ Upstream commit 85bb7c10c1a013ab29d4be07559105dd843c6f7d ] Currently, sniffer mode does not support band auto, so set band_idx to the default 0. Fixes: 0cb349d742d1 ("wifi: mt76: mt7925: update mt7925_mac_link_bss_add for MLO") Signed-off-by: Eric-SY Chang <[email protected]> Signed-off-by: Ming Yen Hsieh <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Felix Fietkau <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Ming Yen Hsieh <[email protected]> Date: Tue Dec 10 17:19:15 2024 -0800 wifi: mt76: mt7925: fix wrong parameter for related cmd of chan info [ Upstream commit 3f0d2178aaf1ed1c017e61cde9ce8a4432c804d1 ] Fix incorrect parameters for the related channel information command. Fixes: 86c051f2c418 ("wifi: mt76: mt7925: enabling MLO when the firmware supports it") Signed-off-by: Ming Yen Hsieh <[email protected]> Signed-off-by: Sean Wang <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Felix Fietkau <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Ming Yen Hsieh <[email protected]> Date: Tue Dec 10 17:19:23 2024 -0800 wifi: mt76: mt7925: Init secondary link PM state [ Upstream commit 28045ef2bc5bbeec4717da98bf31aca0faaccf02 ] Initialize secondary link PM state. Fixes: 86c051f2c418 ("wifi: mt76: mt7925: enabling MLO when the firmware supports it") Signed-off-by: Ming Yen Hsieh <[email protected]> Signed-off-by: Sean Wang <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Felix Fietkau <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Ming Yen Hsieh <[email protected]> Date: Tue Dec 10 17:19:26 2024 -0800 wifi: mt76: mt7925: Properly handle responses for commands with events [ Upstream commit 349460913a4d029cc37c9e3817b1903233b4a627 ] Properly retrieve the response for commands with events. Ensure accurate handling of event-driven commands. Fixes: 86c051f2c418 ("wifi: mt76: mt7925: enabling MLO when the firmware supports it") Signed-off-by: Ming Yen Hsieh <[email protected]> Signed-off-by: Sean Wang <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Felix Fietkau <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Ming Yen Hsieh <[email protected]> Date: Tue Dec 10 17:19:19 2024 -0800 wifi: mt76: mt7925: Update mt7925_mcu_sta_update for BC in ASSOC state [ Upstream commit 0e02f6ed6a49577e29e0b1f7900fad3ed8ae870c ] Update mt7925_mcu_sta_update for broadcast (BC) in the ASSOC state. Fixes: 86c051f2c418 ("wifi: mt76: mt7925: enabling MLO when the firmware supports it") Signed-off-by: Ming Yen Hsieh <[email protected]> Signed-off-by: Sean Wang <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Felix Fietkau <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Ming Yen Hsieh <[email protected]> Date: Tue Dec 10 17:19:24 2024 -0800 wifi: mt76: mt7925: Update mt7925_mcu_uni_[tx,rx]_ba for MLO [ Upstream commit eb2a9a12c6092a26f632468d6610497d4f0e40da ] Update mt7925_mcu_uni_[tx,rx]_ba for MLO support in firmware. Fixes: 86c051f2c418 ("wifi: mt76: mt7925: enabling MLO when the firmware supports it") Signed-off-by: Ming Yen Hsieh <[email protected]> Signed-off-by: Sean Wang <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Felix Fietkau <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Ming Yen Hsieh <[email protected]> Date: Tue Dec 10 17:19:21 2024 -0800 wifi: mt76: mt7925: Update mt7925_unassign_vif_chanctx for per-link BSS [ Upstream commit 30b721467c9c2510e26af6e78e92d7cc08a14bc4 ] Update mt7925_unassign_vif_chanctx to support per-link BSS. Fixes: 86c051f2c418 ("wifi: mt76: mt7925: enabling MLO when the firmware supports it") Signed-off-by: Ming Yen Hsieh <[email protected]> Signed-off-by: Sean Wang <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Felix Fietkau <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Ming Yen Hsieh <[email protected]> Date: Tue Dec 10 17:19:20 2024 -0800 wifi: mt76: mt7925: Update mt792x_rx_get_wcid for per-link STA [ Upstream commit 90c10286b176421068b136da51ed83059a68e322 ] Update mt792x_rx_get_wcid to support per-link STA. Fixes: 86c051f2c418 ("wifi: mt76: mt7925: enabling MLO when the firmware supports it") Signed-off-by: Ming Yen Hsieh <[email protected]> Signed-off-by: Sean Wang <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Felix Fietkau <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Ming Yen Hsieh <[email protected]> Date: Tue Dec 10 17:19:22 2024 -0800 wifi: mt76: mt7925: Update secondary link PS flow [ Upstream commit 8dafab9c4116a6a4fd870be03a3d9b66771dc5a8 ] Update the power-saving flow for secondary links. Fixes: 86c051f2c418 ("wifi: mt76: mt7925: enabling MLO when the firmware supports it") Signed-off-by: Ming Yen Hsieh <[email protected]> Signed-off-by: Sean Wang <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Felix Fietkau <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Peter Chiu <[email protected]> Date: Tue Jan 14 18:10:18 2025 +0800 wifi: mt76: mt7996: add max mpdu len capability [ Upstream commit 1816ad9381e0c150e4c44ce6dd6ee2c52008a052 ] Set max mpdu len to 11454 according to hardware capability. Without this patch, the max ampdu length would be 3895 and count not get expected performance. Fixes: 348533eb968d ("wifi: mt76: mt7996: add EHT capability init") Signed-off-by: Peter Chiu <[email protected]> Signed-off-by: Shayne Chen <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Felix Fietkau <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Benjamin Lin <[email protected]> Date: Tue Jan 14 18:10:23 2025 +0800 wifi: mt76: mt7996: fix definition of tx descriptor [ Upstream commit 14749fe2ed360c92c1a2a76dac0b77f759234981 ] For mt7992 chipsets, the definition of TXD.DW6.BIT10~15 has different interpretations on different frame types. Driver only needs to fill MSDU_CNT for non-management frames. Fixes: 408566db8cad ("wifi: mt76: connac: add new definition of tx descriptor") Co-developed-by: Shayne Chen <[email protected]> Signed-off-by: Shayne Chen <[email protected]> Signed-off-by: Benjamin Lin <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Felix Fietkau <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Howard Hsu <[email protected]> Date: Tue Jan 14 18:10:20 2025 +0800 wifi: mt76: mt7996: fix HE Phy capability [ Upstream commit 7e3aef59a403ade5dd4ea02edc2d7138a66d74b6 ] Set HE SU PPDU And HE MU PPDU With 4x HE-LTF And 0.8 us GI within HE PHY Capabilities element as 1 since hardware can support. Fixes: 98686cd21624 ("wifi: mt76: mt7996: add driver for MediaTek Wi-Fi 7 (802.11be) devices") Signed-off-by: Howard Hsu <[email protected]> Signed-off-by: Shayne Chen <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Felix Fietkau <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Benjamin Lin <[email protected]> Date: Tue Jan 14 18:10:21 2025 +0800 wifi: mt76: mt7996: fix incorrect indexing of MIB FW event [ Upstream commit 5c2a25a1ab76a2976dddc5ffd58498866f3ef7c2 ] Fix wrong calculation of the channel times due to incorrect interpretation from the FW event. Fixes: 98686cd21624 ("wifi: mt76: mt7996: add driver for MediaTek Wi-Fi 7 (802.11be) devices") Signed-off-by: Benjamin Lin <[email protected]> Signed-off-by: Shayne Chen <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Felix Fietkau <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Shayne Chen <[email protected]> Date: Mon Oct 7 21:51:33 2024 +0800 wifi: mt76: mt7996: fix invalid interface combinations [ Upstream commit 89aca45f26879dfbbf8374c425c4811f69cfc2df ] Setting beacon_int_min_gcd and NL80211_IFTYPE_ADHOC in the same interface combination is invalid, which will trigger the following warning trace and get error returned from wiphy_register(). [ 10.080325] Call trace: [ 10.082761] wiphy_register+0xc4/0x76c [cfg80211] [ 10.087465] ieee80211_register_hw+0x800/0xac4 [mac80211] [ 10.092868] mt76_register_device+0x16c/0x2c0 [mt76] [ 10.097829] mt7996_register_device+0x740/0x844 [mt7996e] Fix this by removing unused adhoc iftype. Fixes: 948f65249868 ("wifi: mt76: mt7996: advertize beacon_int_min_gcd") Reported-by: Frank Wunderlich <[email protected]> Signed-off-by: Shayne Chen <[email protected]> Tested-By: Frank Wunderlich <[email protected]> Signed-off-by: Kalle Valo <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Peter Chiu <[email protected]> Date: Tue Jan 14 18:10:24 2025 +0800 wifi: mt76: mt7996: fix ldpc setting [ Upstream commit da8352da1e4f476fdbf549a4efce4f3c618fde3b ] The non-AP interfaces would not use conf->vht_ldpc so they never set STA_CAP_VHT_LDPC even if peer-station support LDPC. Check conf->vht_ldpc only for AP interface. Without this patch, station only uses BCC to transmit packet in VHT mode. Fixes: dda423dd65c3 ("wifi: mt76: mt7996: remove mt7996_mcu_beacon_check_caps()") Signed-off-by: Peter Chiu <[email protected]> Signed-off-by: Shayne Chen <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Felix Fietkau <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: xueqin Luo <[email protected]> Date: Mon Dec 2 11:19:16 2024 +0800 wifi: mt76: mt7996: fix overflows seen when writing limit attributes [ Upstream commit 5adbc8ce5bbe7e311e2600b7d7d998a958873e98 ] DIV_ROUND_CLOSEST() after kstrtoul() results in an overflow if a large number such as 18446744073709551615 is provided by the user. Fix it by reordering clamp_val() and DIV_ROUND_CLOSEST() operations. This commit was inspired by commit: 57ee12b6c514. Fixes: 6879b2e94172 ("wifi: mt76: mt7996: add thermal sensor device support") Signed-off-by: xueqin Luo <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Felix Fietkau <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Peter Chiu <[email protected]> Date: Thu Jan 9 19:04:36 2025 +0800 wifi: mt76: mt7996: fix register mapping [ Upstream commit d07ecb4f7070e84de49e8fa4e5a83dd52716d805 ] Bypass the entry when ofs is equal to dev->reg.map[i].size. Without this patch, it would get incorrect register mapping when the CR address is located at the boundary of an entry. Fixes: 98686cd21624 ("wifi: mt76: mt7996: add driver for MediaTek Wi-Fi 7 (802.11be) devices") Signed-off-by: Peter Chiu <[email protected]> Signed-off-by: Shengyu Qu <[email protected]> Link: https://patch.msgid.link/OSZPR01MB84344FEFF53004B5CF40BCC198132@OSZPR01MB8434.jpnprd01.prod.outlook.com Signed-off-by: Felix Fietkau <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Felix Fietkau <[email protected]> Date: Mon Dec 30 20:41:53 2024 +0100 wifi: mt76: mt7996: fix rx filter setting for bfee functionality [ Upstream commit 858fd2a53877b2e8b1d991a5a861ac34a0f55ef8 ] Fix rx filter setting to prevent dropping NDPA frames. Without this change, bfee functionality may behave abnormally. Fixes: 98686cd21624 ("wifi: mt76: mt7996: add driver for MediaTek Wi-Fi 7 (802.11be) devices") Link: https://patch.msgid.link/[email protected] Signed-off-by: Felix Fietkau <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Howard Hsu <[email protected]> Date: Tue Jan 14 18:10:19 2025 +0800 wifi: mt76: mt7996: fix the capability of reception of EHT MU PPDU [ Upstream commit 2ffbdfc1bd78ba944c5754791c84f32232b513c6 ] This commit includes two changes. First, enable "EHT MU PPDU With 4x EHT-LTF And 0.8us GI" in EHT Phy capabilities element since hardware can support. Second, fix the value of "Maximum number of supported EHT LTFs" in the same element, where the previous setting of 3 in Bit 3-4 was incorrect. Fixes: 348533eb968d ("wifi: mt76: mt7996: add EHT capability init") Signed-off-by: Howard Hsu <[email protected]> Signed-off-by: Shayne Chen <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Felix Fietkau <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Felix Fietkau <[email protected]> Date: Mon Dec 30 20:41:56 2024 +0100 wifi: mt76: only enable tx worker after setting the channel [ Upstream commit 228bc0e79c85269d36cc81e0288e95f2f9ba7ae1 ] Avoids sending packets too early Fixes: 0b3be9d1d34e ("wifi: mt76: add separate tx scheduling queue for off-channel tx") Link: https://patch.msgid.link/[email protected] Signed-off-by: Felix Fietkau <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Thadeu Lima de Souza Cascardo <[email protected]> Date: Fri Dec 6 14:37:11 2024 -0300 wifi: rtlwifi: destroy workqueue at rtl_deinit_core [ Upstream commit d8ece6fc3694657e4886191b32ca1690af11adda ] rtl_wq is allocated at rtl_init_core, so it makes more sense to destroy it at rtl_deinit_core. In the case of USB, where _rtl_usb_init does not require anything to be undone, that is fine. But for PCI, rtl_pci_init, which is called after rtl_init_core, needs to deallocate data, but only if it has been called. That means that destroying the workqueue needs to be done whether rtl_pci_init has been called or not. And since rtl_pci_deinit was doing it, it has to be moved out of there. It makes more sense to move it to rtl_deinit_core and have it done in both cases, USB and PCI. Since this is a requirement for a followup memory leak fix, mark this as fixing such memory leak. Fixes: 0c8173385e54 ("rtl8192ce: Add new driver") Signed-off-by: Thadeu Lima de Souza Cascardo <[email protected]> Signed-off-by: Ping-Ke Shih <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Thadeu Lima de Souza Cascardo <[email protected]> Date: Thu Nov 7 10:33:18 2024 -0300 wifi: rtlwifi: do not complete firmware loading needlessly [ Upstream commit e73e11d303940119e41850a0452a0deda2cc4eb5 ] The only code waiting for completion is driver removal, which will not be called when probe returns a failure. So this completion is unnecessary. Fixes: b0302aba812b ("rtlwifi: Convert to asynchronous firmware load") Signed-off-by: Thadeu Lima de Souza Cascardo <[email protected]> Acked-by: Ping-Ke Shih <[email protected]> Signed-off-by: Ping-Ke Shih <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Thadeu Lima de Souza Cascardo <[email protected]> Date: Thu Nov 7 10:33:21 2024 -0300 wifi: rtlwifi: fix init_sw_vars leak when probe fails [ Upstream commit 00260350aed80c002df270c805ca443ec9a719a6 ] If ieee80211_register_hw fails, the memory allocated for the firmware will not be released. Call deinit_sw_vars as the function that undoes the allocationes done by init_sw_vars. Fixes: cefe3dfdb9f5 ("rtl8192cu: Call ieee80211_register_hw from rtl_usb_probe") Signed-off-by: Thadeu Lima de Souza Cascardo <[email protected]> Signed-off-by: Ping-Ke Shih <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Thadeu Lima de Souza Cascardo <[email protected]> Date: Fri Dec 6 14:37:12 2024 -0300 wifi: rtlwifi: fix memory leaks and invalid access at probe error path [ Upstream commit e7ceefbfd8d447abc8aca8ab993a942803522c06 ] Deinitialize at reverse order when probe fails. When init_sw_vars fails, rtl_deinit_core should not be called, specially now that it destroys the rtl_wq workqueue. And call rtl_pci_deinit and deinit_sw_vars, otherwise, memory will be leaked. Remove pci_set_drvdata call as it will already be cleaned up by the core driver code and could lead to memory leaks too. cf. commit 8d450935ae7f ("wireless: rtlwifi: remove unnecessary pci_set_drvdata()") and commit 3d86b93064c7 ("rtlwifi: Fix PCI probe error path orphaned memory"). Fixes: 0c8173385e54 ("rtl8192ce: Add new driver") Signed-off-by: Thadeu Lima de Souza Cascardo <[email protected]> Signed-off-by: Ping-Ke Shih <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Thadeu Lima de Souza Cascardo <[email protected]> Date: Fri Dec 6 14:37:13 2024 -0300 wifi: rtlwifi: pci: wait for firmware loading before releasing memory [ Upstream commit b59b86c5d08be7d761c04affcbcec8184738c200 ] At probe error path, the firmware loading work may have already been queued. In such a case, it will try to access memory allocated by the probe function, which is about to be released. In such paths, wait for the firmware worker to finish before releasing memory. Fixes: 3d86b93064c7 ("rtlwifi: Fix PCI probe error path orphaned memory") Signed-off-by: Thadeu Lima de Souza Cascardo <[email protected]> Signed-off-by: Ping-Ke Shih <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Thadeu Lima de Souza Cascardo <[email protected]> Date: Fri Dec 6 14:37:10 2024 -0300 wifi: rtlwifi: remove unused check_buddy_priv [ Upstream commit 2fdac64c3c35858aa8ac5caa70b232e03456e120 ] Commit 2461c7d60f9f ("rtlwifi: Update header file") introduced a global list of private data structures. Later on, commit 26634c4b1868 ("rtlwifi Modify existing bits to match vendor version 2013.02.07") started adding the private data to that list at probe time and added a hook, check_buddy_priv to find the private data from a similar device. However, that function was never used. Besides, though there is a lock for that list, it is never used. And when the probe fails, the private data is never removed from the list. This would cause a second probe to access freed memory. Remove the unused hook, structures and members, which will prevent the potential race condition on the list and its corruption during a second probe when probe fails. Fixes: 26634c4b1868 ("rtlwifi Modify existing bits to match vendor version 2013.02.07") Signed-off-by: Thadeu Lima de Souza Cascardo <[email protected]> Signed-off-by: Ping-Ke Shih <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Thadeu Lima de Souza Cascardo <[email protected]> Date: Thu Nov 7 10:33:19 2024 -0300 wifi: rtlwifi: rtl8192se: rise completion of firmware loading as last step [ Upstream commit 8559a9e0c457729fe3edb3176bbf7c7874f482b0 ] Just like in commit 4dfde294b979 ("rtlwifi: rise completion at the last step of firmware callback"), only signal completion once the function is finished. Otherwise, the module removal waiting for the completion could free the memory that the callback will still use before returning. Fixes: b0302aba812b ("rtlwifi: Convert to asynchronous firmware load") Signed-off-by: Thadeu Lima de Souza Cascardo <[email protected]> Acked-by: Ping-Ke Shih <[email protected]> Signed-off-by: Ping-Ke Shih <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Colin Ian King <[email protected]> Date: Wed Nov 6 15:46:42 2024 +0000 wifi: rtlwifi: rtl8821ae: phy: restore removed code to fix infinite loop [ Upstream commit 5e5903a442bb889a62a0f5d89ac33e53ab08592c ] A previous clean-up fix removed the assignment of v2 inside a while loop that turned it into an infinite loop. Fix this by restoring the assignment of v2 from array[] so that v2 is updated inside the loop. Fixes: cda37445718d ("wifi: rtlwifi: rtl8821ae: phy: remove some useless code") Signed-off-by: Colin Ian King <[email protected]> Tested-by: Ping-Ke Shih <[email protected]> Reviewed-by: Su Hui <[email protected]> Signed-off-by: Ping-Ke Shih <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Thadeu Lima de Souza Cascardo <[email protected]> Date: Thu Nov 7 10:33:22 2024 -0300 wifi: rtlwifi: usb: fix workqueue leak when probe fails [ Upstream commit f79bc5c67867c19ce2762e7934c20dbb835ed82c ] rtl_init_core creates a workqueue that is then assigned to rtl_wq. rtl_deinit_core does not destroy it. It is left to rtl_usb_deinit, which must be called in the probe error path. Fixes: 2ca20f79e0d8 ("rtlwifi: Add usb driver") Fixes: 851639fdaeac ("rtlwifi: Modify some USB de-initialize code.") Signed-off-by: Thadeu Lima de Souza Cascardo <[email protected]> Signed-off-by: Ping-Ke Shih <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Thadeu Lima de Souza Cascardo <[email protected]> Date: Thu Nov 7 10:33:20 2024 -0300 wifi: rtlwifi: wait for firmware loading before releasing memory [ Upstream commit b4b26642b31ef282df6ff7ea8531985edfdef12a ] At probe error path, the firmware loading work may have already been queued. In such a case, it will try to access memory allocated by the probe function, which is about to be released. In such paths, wait for the firmware worker to finish before releasing memory. Fixes: a7f7c15e945a ("rtlwifi: rtl8192cu: Free ieee80211_hw if probing fails") Signed-off-by: Thadeu Lima de Souza Cascardo <[email protected]> Signed-off-by: Ping-Ke Shih <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Chih-Kang Chang <[email protected]> Date: Fri Jan 3 10:45:00 2025 +0800 wifi: rtw89: avoid to init mgnt_entry list twice when WoWLAN failed [ Upstream commit 2f7667675df1b40b73ecc53b4b8c3189b1e5f2c1 ] If WoWLAN failed in resume flow, the rtw89_ops_add_interface() triggered without removing the interface first. Then the mgnt_entry list init again, causing the list_empty() check in rtw89_chanctx_ops_assign_vif() useless, and list_add_tail() again. Therefore, we have added a check to prevent double adding of the list. rtw89_8852ce 0000:01:00.0: failed to check wow status disabled rtw89_8852ce 0000:01:00.0: wow: failed to check disable fw ready rtw89_8852ce 0000:01:00.0: wow: failed to swap to normal fw rtw89_8852ce 0000:01:00.0: failed to disable wow rtw89_8852ce 0000:01:00.0: failed to resume for wow -110 rtw89_8852ce 0000:01:00.0: MAC has already powered on i2c_hid_acpi i2c-ILTK0001:00: PM: acpi_subsys_resume+0x0/0x60 returned 0 after 284705 usecs list_add corruption. prev->next should be next (ffff9d9719d82228), but was ffff9d9719f96030. (prev=ffff9d9719f96030). ------------[ cut here ]------------ kernel BUG at lib/list_debug.c:34! invalid opcode: 0000 [#1] PREEMPT SMP NOPTI CPU: 2 PID: 6918 Comm: kworker/u8:19 Tainted: G U O Hardware name: Google Anraggar/Anraggar, BIOS Google_Anraggar.15217.514.0 03/25/2024 Workqueue: events_unbound async_run_entry_fn RIP: 0010:__list_add_valid_or_report+0x9f/0xb0 Code: e8 56 89 ff ff 0f 0b 48 c7 c7 3e fc e0 96 48 89 c6 e8 45 89 ff ... RSP: 0018:ffffa51b42bbbaf0 EFLAGS: 00010246 RAX: 0000000000000075 RBX: ffff9d9719d82ab0 RCX: 13acb86e047a4400 RDX: 3fffffffffffffff RSI: 0000000000000000 RDI: 00000000ffffdfff RBP: ffffa51b42bbbb28 R08: ffffffff9768e250 R09: 0000000000001fff R10: ffffffff9765e250 R11: 0000000000005ffd R12: ffff9d9719f95c40 R13: ffff9d9719f95be8 R14: ffff9d97081bfd78 R15: ffff9d9719d82060 FS: 0000000000000000(0000) GS:ffff9d9a6fb00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007e7d029a4060 CR3: 0000000345e38000 CR4: 0000000000750ee0 PKRU: 55555554 Call Trace: <TASK> ? __die_body+0x68/0xb0 ? die+0xaa/0xd0 ? do_trap+0x9f/0x170 ? __list_add_valid_or_report+0x9f/0xb0 ? __list_add_valid_or_report+0x9f/0xb0 ? handle_invalid_op+0x69/0x90 ? __list_add_valid_or_report+0x9f/0xb0 ? exc_invalid_op+0x3c/0x50 ? asm_exc_invalid_op+0x16/0x20 ? __list_add_valid_or_report+0x9f/0xb0 rtw89_chanctx_ops_assign_vif+0x1f9/0x210 [rtw89_core cbb375c44bf28564ce479002bff66617a25d9ac1] ? __mutex_unlock_slowpath+0xa0/0xf0 rtw89_ops_assign_vif_chanctx+0x4b/0x90 [rtw89_core cbb375c44bf28564ce479002bff66617a25d9ac1] drv_assign_vif_chanctx+0xa7/0x1f0 [mac80211 6efaad16237edaaea0868b132d4f93ecf918a8b6] ieee80211_reconfig+0x9cb/0x17b0 [mac80211 6efaad16237edaaea0868b132d4f93ecf918a8b6] ? __pfx_wiphy_resume+0x10/0x10 [cfg80211 572d03acaaa933fe38251be7fce3b3675284b8ed] ? dev_printk_emit+0x51/0x70 ? _dev_info+0x6e/0x90 wiphy_resume+0x89/0x180 [cfg80211 572d03acaaa933fe38251be7fce3b3675284b8ed] ? __pfx_wiphy_resume+0x10/0x10 [cfg80211 572d03acaaa933fe38251be7fce3b3675284b8ed] dpm_run_callback+0x37/0x1e0 device_resume+0x26d/0x4b0 ? __pfx_dpm_watchdog_handler+0x10/0x10 async_resume+0x1d/0x30 async_run_entry_fn+0x29/0xd0 worker_thread+0x397/0x970 kthread+0xed/0x110 ? __pfx_worker_thread+0x10/0x10 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x38/0x50 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1b/0x30 </TASK> Fixes: 68ec751b2881 ("wifi: rtw89: chan: manage active interfaces") Signed-off-by: Chih-Kang Chang <[email protected]> Signed-off-by: Ping-Ke Shih <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Zong-Zhe Yang <[email protected]> Date: Tue Dec 31 08:48:09 2024 +0800 wifi: rtw89: chan: fix soft lockup in rtw89_entity_recalc_mgnt_roles() [ Upstream commit e4790b3e314a4814f1680a5dc552031fb199b878 ] During rtw89_entity_recalc_mgnt_roles(), there is a normalizing process which will re-order the list if an entry with target pattern is found. And once one is found, should have aborted the list_for_each_entry. But, `break` just aborted the inner for-loop. The outer list_for_each_entry still continues. Normally, only the first entry will match the target pattern, and the re-ordering will change nothing, so there won't be soft lockup. However, in some special cases, soft lockup would happen. Fix it by `goto fill` to break from the list_for_each_entry. The following is a sample of kernel log for this problem. watchdog: BUG: soft lockup - CPU#1 stuck for 26s! [wpa_supplicant:2055] [...] RIP: 0010:rtw89_entity_recalc ([...] chan.c:392 chan.c:479) rtw89_core [...] Fixes: 68ec751b2881 ("wifi: rtw89: chan: manage active interfaces") Signed-off-by: Zong-Zhe Yang <[email protected]> Signed-off-by: Ping-Ke Shih <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Po-Hao Huang <[email protected]> Date: Tue Dec 31 08:48:10 2024 +0800 wifi: rtw89: correct header conversion rule for MLO only [ Upstream commit b2658bf4d7f2f2e37ae9d2463ecc40618f587834 ] Header conversion should only be used with MLO connections. Otherwise P2P connection fails due to wrong probe responses sent. Fix it accordingly. Fixes: b8499664fca9 ("wifi: rtw89: Add header conversion for MLO connections") Signed-off-by: Po-Hao Huang <[email protected]> Signed-off-by: Ping-Ke Shih <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Zong-Zhe Yang <[email protected]> Date: Tue Dec 31 08:48:08 2024 +0800 wifi: rtw89: fix proceeding MCC with wrong scanning state after sequence changes [ Upstream commit e47f0a5898540eb19b953708707887d4b3020645 ] When starting/proceeding MCC, it will abort an ongoing hw scan process. In the proceeding cases, it unexpectedly tries to abort a non-exist hw scan process. Then, a trace shown at the bottom will happen. This problem is caused by a previous commit which changed some call sequence inside rtw89_hw_scan_complete() to fix some coex problems. These changes lead to our scanning flag was not cleared when proceeding MCC. To keep the fixes on coex, and resolve the problem here, re-consider the related call sequence. The known sequence requirements are listed below. * the old sequence: A. notify coex B. clear scanning flag C. proceed chanctx C-1. set channel C-2. proceed MCC (the problem: A needs to be after C-1) * the current sequence: C. proceed chanctx C-1. set channel C-2. proceed MCC A. notify coex B. clear scanning flag (the problem: C-2 needs to be after B) So, now let hw scan caller pass a callback to proceed chanctx if needed. Then, the new sequence will be like the below. C-1. set channel A. notify coex B. clear scanning flag C-2. proceed MCC The following is the kernel log for the problem in current sequence. rtw89_8852be 0000:04:00.0: rtw89_hw_scan_offload failed ret -110 ------------[ cut here ]------------ [...] CPU: 2 PID: 3991 Comm: kworker/u16:0 Tainted: G OE 6.6.17 #3 Hardware name: LENOVO 2356AD1/2356AD1, BIOS G7ETB3WW (2.73 ) 11/28/2018 Workqueue: events_unbound wiphy_work_cancel [cfg80211] RIP: 0010:ieee80211_sched_scan_stopped+0xaea/0xd80 [mac80211] Code: 9c 24 d0 11 00 00 49 39 dd 0f 85 46 ff ff ff 4c 89 e7 e8 09 2d RSP: 0018:ffffb27783643d48 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000 RDX: ffff8a2280964bc0 RSI: 0000000000000000 RDI: ffff8a23df580900 RBP: ffffb27783643d88 R08: 0000000000000001 R09: 0000000000000400 R10: 0000000000000000 R11: 0000000000008268 R12: ffff8a23df580900 R13: ffff8a23df581b00 R14: 0000000000000000 R15: 0000000000000000 FS: 0000000000000000(0000) GS:ffff8a258e680000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f26a0654000 CR3: 000000002ea2e002 CR4: 00000000001706e0 Call Trace: <TASK> ? show_regs+0x68/0x70 ? ieee80211_sched_scan_stopped+0xaea/0xd80 [mac80211] ? __warn+0x8f/0x150 ? ieee80211_sched_scan_stopped+0xaea/0xd80 [mac80211] ? report_bug+0x1f5/0x200 ? handle_bug+0x46/0x80 ? exc_invalid_op+0x19/0x70 ? asm_exc_invalid_op+0x1b/0x20 ? ieee80211_sched_scan_stopped+0xaea/0xd80 [mac80211] ieee80211_scan_work+0x14a/0x650 [mac80211] ? __queue_work+0x10f/0x410 wiphy_work_cancel+0x2fb/0x310 [cfg80211] process_scheduled_works+0x9d/0x390 ? __pfx_worker_thread+0x10/0x10 worker_thread+0x15b/0x2d0 ? __pfx_worker_thread+0x10/0x10 kthread+0x108/0x140 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x3c/0x60 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1b/0x30 </TASK> ---[ end trace 0000000000000000 ]--- Fixes: f16c40acd319 ("wifi: rtw89: Fix TX fail with A2DP after scanning") Signed-off-by: Zong-Zhe Yang <[email protected]> Signed-off-by: Ping-Ke Shih <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Ping-Ke Shih <[email protected]> Date: Tue Jan 7 19:42:54 2025 +0800 wifi: rtw89: fix race between cancel_hw_scan and hw_scan completion [ Upstream commit ba4bb0402c60e945c4c396c51f0acac3c3e3ea5c ] The rtwdev->scanning flag isn't protected by mutex originally, so cancel_hw_scan can pass the condition, but suddenly hw_scan completion unset the flag and calls ieee80211_scan_completed() that will free local->hw_scan_req. Then, cancel_hw_scan raises null-ptr-deref and use-after-free. Fix it by moving the check condition to where protected by mutex. KASAN: null-ptr-deref in range [0x0000000000000088-0x000000000000008f] CPU: 2 PID: 6922 Comm: kworker/2:2 Tainted: G OE Hardware name: LENOVO 2356AD1/2356AD1, BIOS G7ETB6WW (2.76 ) 09/10/2019 Workqueue: events cfg80211_conn_work [cfg80211] RIP: 0010:rtw89_fw_h2c_scan_offload_be+0xc33/0x13c3 [rtw89_core] Code: 00 45 89 6c 24 1c 0f 85 23 01 00 00 48 8b 85 20 ff ff ff 48 8d RSP: 0018:ffff88811fd9f068 EFLAGS: 00010206 RAX: dffffc0000000000 RBX: ffff88811fd9f258 RCX: 0000000000000001 RDX: 0000000000000011 RSI: 0000000000000001 RDI: 0000000000000089 RBP: ffff88811fd9f170 R08: 0000000000000000 R09: 0000000000000000 R10: ffff88811fd9f108 R11: 0000000000000000 R12: ffff88810e47f960 R13: 0000000000000000 R14: 000000000000ffff R15: 0000000000000000 FS: 0000000000000000(0000) GS:ffff8881d6f00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007531dfca55b0 CR3: 00000001be296004 CR4: 00000000001706e0 Call Trace: <TASK> ? show_regs+0x61/0x73 ? __die_body+0x20/0x73 ? die_addr+0x4f/0x7b ? exc_general_protection+0x191/0x1db ? asm_exc_general_protection+0x27/0x30 ? rtw89_fw_h2c_scan_offload_be+0xc33/0x13c3 [rtw89_core] ? rtw89_fw_h2c_scan_offload_be+0x458/0x13c3 [rtw89_core] ? __pfx_rtw89_fw_h2c_scan_offload_be+0x10/0x10 [rtw89_core] ? do_raw_spin_lock+0x75/0xdb ? __pfx_do_raw_spin_lock+0x10/0x10 rtw89_hw_scan_offload+0xb5e/0xbf7 [rtw89_core] ? _raw_spin_unlock+0xe/0x24 ? __mutex_lock.constprop.0+0x40c/0x471 ? __pfx_rtw89_hw_scan_offload+0x10/0x10 [rtw89_core] ? __mutex_lock_slowpath+0x13/0x1f ? mutex_lock+0xa2/0xdc ? __pfx_mutex_lock+0x10/0x10 rtw89_hw_scan_abort+0x58/0xb7 [rtw89_core] rtw89_ops_cancel_hw_scan+0x120/0x13b [rtw89_core] ieee80211_scan_cancel+0x468/0x4d0 [mac80211] ieee80211_prep_connection+0x858/0x899 [mac80211] ieee80211_mgd_auth+0xbea/0xdde [mac80211] ? __pfx_ieee80211_mgd_auth+0x10/0x10 [mac80211] ? cfg80211_find_elem+0x15/0x29 [cfg80211] ? is_bss+0x1b7/0x1d7 [cfg80211] ieee80211_auth+0x18/0x27 [mac80211] cfg80211_mlme_auth+0x3bb/0x3e7 [cfg80211] cfg80211_conn_do_work+0x410/0xb81 [cfg80211] ? __pfx_cfg80211_conn_do_work+0x10/0x10 [cfg80211] ? __kasan_check_read+0x11/0x1f ? psi_group_change+0x8bc/0x944 ? __kasan_check_write+0x14/0x22 ? mutex_lock+0x8e/0xdc ? __pfx_mutex_lock+0x10/0x10 ? __pfx___radix_tree_lookup+0x10/0x10 cfg80211_conn_work+0x245/0x34d [cfg80211] ? __pfx_cfg80211_conn_work+0x10/0x10 [cfg80211] ? update_cfs_rq_load_avg+0x3bc/0x3d7 ? sched_clock_noinstr+0x9/0x1a ? sched_clock+0x10/0x24 ? sched_clock_cpu+0x7e/0x42e ? newidle_balance+0x796/0x937 ? __pfx_sched_clock_cpu+0x10/0x10 ? __pfx_newidle_balance+0x10/0x10 ? __kasan_check_read+0x11/0x1f ? psi_group_change+0x8bc/0x944 ? _raw_spin_unlock+0xe/0x24 ? raw_spin_rq_unlock+0x47/0x54 ? raw_spin_rq_unlock_irq+0x9/0x1f ? finish_task_switch.isra.0+0x347/0x586 ? __schedule+0x27bf/0x2892 ? mutex_unlock+0x80/0xd0 ? do_raw_spin_lock+0x75/0xdb ? __pfx___schedule+0x10/0x10 process_scheduled_works+0x58c/0x821 worker_thread+0x4c7/0x586 ? __kasan_check_read+0x11/0x1f kthread+0x285/0x294 ? __pfx_worker_thread+0x10/0x10 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x29/0x6f ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1b/0x30 </TASK> Fixes: 895907779752 ("rtw89: 8852a: add ieee80211_ops::hw_scan") Signed-off-by: Ping-Ke Shih <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Zong-Zhe Yang <[email protected]> Date: Fri Jan 3 15:44:12 2025 +0800 wifi: rtw89: mcc: consider time limits not divisible by 1024 [ Upstream commit 35642ba31dc4a1816a20191e90156a9e329beb10 ] For each MCC role, time limits, including max_tob_us, max_toa_us, and mac_dur_us, are calculated if there are NoA attributes. The relation between these time limits is "max_dur_us = max_tob_us + max_toa_us". Then, the unit is converted from us to TU. However, originally, each time limit was divided by 1024 independently. It missed to consider the cases that max_tob_us or max_toa_us is not divisible by 1024. It causes the result breaks "max_dur (TU) = max_tob (TU) + max_toa (TU)". Finally, when MCC calculates pattern parameters based on these kinds of time limits, it might not perform well. Fixes: b09df09b55fb ("wifi: rtw89: mcc: initialize start flow") Signed-off-by: Zong-Zhe Yang <[email protected]> Signed-off-by: Ping-Ke Shih <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Barnabás Czémán <[email protected]> Date: Mon Nov 4 21:00:35 2024 +0100 wifi: wcn36xx: fix channel survey memory allocation size [ Upstream commit 6200d947f050efdba4090dfefd8a01981363d954 ] KASAN reported a memory allocation issue in wcn->chan_survey due to incorrect size calculation. This commit uses kcalloc to allocate memory for wcn->chan_survey, ensuring proper initialization and preventing the use of uninitialized values when there are no frames on the channel. Fixes: 29696e0aa413 ("wcn36xx: Track SNR and RSSI for each RX frame") Signed-off-by: Barnabás Czémán <[email protected]> Acked-by: Loic Poulain <[email protected]> Reviewed-by: Bryan O'Donoghue <[email protected]> Link: https://patch.msgid.link/20241104-wcn36xx-memory-allocation-v1-1-5ec901cf37b6@mainlining.org Signed-off-by: Jeff Johnson <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Alexis Lothoré <[email protected]> Date: Tue Jan 14 11:45:34 2025 +0100 wifi: wilc1000: unregister wiphy only after netdev registration [ Upstream commit 208dea9107e80a33dfeb029bdb93cb53eccf005d ] wiphy_unregister()/wiphy_free() has been recently decoupled from wilc_netdev_cleanup() to fix a faulty error path in sdio/spi probe functions. However this change introduced a new failure when simply loading then unloading the driver: $ modprobe wilc1000-sdio; modprobe -r wilc1000-sdio WARNING: CPU: 0 PID: 115 at net/wireless/core.c:1145 wiphy_unregister+0x904/0xc40 [cfg80211] Modules linked in: wilc1000_sdio(-) wilc1000 cfg80211 bluetooth ecdh_generic ecc CPU: 0 UID: 0 PID: 115 Comm: modprobe Not tainted 6.13.0-rc6+ #45 Hardware name: Atmel SAMA5 Call trace: unwind_backtrace from show_stack+0x18/0x1c show_stack from dump_stack_lvl+0x44/0x70 dump_stack_lvl from __warn+0x118/0x27c __warn from warn_slowpath_fmt+0xcc/0x140 warn_slowpath_fmt from wiphy_unregister+0x904/0xc40 [cfg80211] wiphy_unregister [cfg80211] from wilc_sdio_remove+0xb0/0x15c [wilc1000_sdio] wilc_sdio_remove [wilc1000_sdio] from sdio_bus_remove+0x104/0x3f0 sdio_bus_remove from device_release_driver_internal+0x424/0x5dc device_release_driver_internal from driver_detach+0x120/0x224 driver_detach from bus_remove_driver+0x17c/0x314 bus_remove_driver from sys_delete_module+0x310/0x46c sys_delete_module from ret_fast_syscall+0x0/0x1c Exception stack(0xd0acbfa8 to 0xd0acbff0) bfa0: 0044b210 0044b210 0044b24c 00000800 00000000 00000000 bfc0: 0044b210 0044b210 00000000 00000081 00000000 0044b210 00000000 00000000 bfe0: 00448e24 b6af99c4 0043ea0d aea2e12c irq event stamp: 0 hardirqs last enabled at (0): [<00000000>] 0x0 hardirqs last disabled at (0): [<c01588f0>] copy_process+0x1c4c/0x7bec softirqs last enabled at (0): [<c0158944>] copy_process+0x1ca0/0x7bec softirqs last disabled at (0): [<00000000>] 0x0 The warning is triggered by the fact that there is still a wireless_device linked to the wiphy we are unregistering, due to wiphy_unregister() now being called after net device unregister (performed in wilc_netdev_cleanup()). Fix this warning by moving wiphy_unregister() after wilc_netdev_cleanup() is nominal paths (ie: driver removal). wilc_netdev_cleanup() ordering is left untouched in error paths in probe function because net device is not registered in those paths (so the warning can not trigger), yet the wiphy can still be registered, and we still some cleanup steps from wilc_netdev_cleanup(). Fixes: 1be94490b6b8 ("wifi: wilc1000: unregister wiphy only if it has been registered") Signed-off-by: Alexis Lothoré <[email protected]> Signed-off-by: Kalle Valo <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Alexis Lothoré <[email protected]> Date: Mon Dec 23 16:46:48 2024 +0100 wifi: wilc1000: unregister wiphy only if it has been registered [ Upstream commit 1be94490b6b8a06ff14cd23fda8714e6ec37cdfb ] There is a specific error path in probe functions in wilc drivers (both sdio and spi) which can lead to kernel panic, as this one for example when using SPI: Unable to handle kernel paging request at virtual address 9f000000 when read [9f000000] *pgd=00000000 Internal error: Oops: 5 [#1] ARM Modules linked in: wilc1000_spi(+) crc_itu_t crc7 wilc1000 cfg80211 bluetooth ecdh_generic ecc CPU: 0 UID: 0 PID: 106 Comm: modprobe Not tainted 6.13.0-rc3+ #22 Hardware name: Atmel SAMA5 PC is at wiphy_unregister+0x244/0xc40 [cfg80211] LR is at wiphy_unregister+0x1c0/0xc40 [cfg80211] [...] wiphy_unregister [cfg80211] from wilc_netdev_cleanup+0x380/0x494 [wilc1000] wilc_netdev_cleanup [wilc1000] from wilc_bus_probe+0x360/0x834 [wilc1000_spi] wilc_bus_probe [wilc1000_spi] from spi_probe+0x15c/0x1d4 spi_probe from really_probe+0x270/0xb2c really_probe from __driver_probe_device+0x1dc/0x4e8 __driver_probe_device from driver_probe_device+0x5c/0x140 driver_probe_device from __driver_attach+0x220/0x540 __driver_attach from bus_for_each_dev+0x13c/0x1a8 bus_for_each_dev from bus_add_driver+0x2a0/0x6a4 bus_add_driver from driver_register+0x27c/0x51c driver_register from do_one_initcall+0xf8/0x564 do_one_initcall from do_init_module+0x2e4/0x82c do_init_module from load_module+0x59a0/0x70c4 load_module from init_module_from_file+0x100/0x148 init_module_from_file from sys_finit_module+0x2fc/0x924 sys_finit_module from ret_fast_syscall+0x0/0x1c The issue can easily be reproduced, for example by not wiring correctly a wilc device through SPI (and so, make it unresponsive to early SPI commands). It is due to a recent change decoupling wiphy allocation from wiphy registration, however wilc_netdev_cleanup has not been updated accordingly, letting it possibly call wiphy unregister on a wiphy which has never been registered. Fix this crash by moving wiphy_unregister/wiphy_free out of wilc_netdev_cleanup, and by adjusting error paths in both drivers Fixes: fbdf0c5248dc ("wifi: wilc1000: Register wiphy after reading out chipid") Signed-off-by: Alexis Lothoré <[email protected]> Reviewed-by: Marek Vasut <[email protected]> Signed-off-by: Kalle Valo <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Andreas Kemnade <[email protected]> Date: Sat Jan 4 20:55:07 2025 +0100 wifi: wlcore: fix unbalanced pm_runtime calls [ Upstream commit 996c934c8c196144af386c4385f61fcd5349af28 ] If firmware boot failes, runtime pm is put too often: [12092.708099] wlcore: ERROR firmware boot failed despite 3 retries [12092.708099] wl18xx_driver wl18xx.1.auto: Runtime PM usage count underflow! Fix that by redirecting all error gotos before runtime_get so that runtime is not put. Fixes: c40aad28a3cf ("wlcore: Make sure firmware is initialized in wl1271_op_add_interface()") Signed-off-by: Andreas Kemnade <[email protected]> Reviewed-by: Michael Nemanov <[email protected]> Signed-off-by: Kalle Valo <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: K Prateek Nayak <[email protected]> Date: Mon Dec 23 04:34:04 2024 +0000 x86/topology: Use x86_sched_itmt_flags for PKG domain unconditionally [ Upstream commit e1bc02646527fc1ed74f00eb599b2b74d49671c7 ] x86_sched_itmt_flags() returns SD_ASYM_PACKING if ITMT support is enabled by the system. Without ITMT support being enabled, it returns 0 similar to current x86_die_flags() on non-Hybrid systems (!X86_HYBRID_CPU and !X86_FEATURE_AMD_HETEROGENEOUS_CORES) On Intel systems that enable ITMT support, either the MC domain coincides with the PKG domain, or in case of multiple MC groups within a PKG domain, either Sub-NUMA Cluster (SNC) is enabled or the processor features Hybrid core layout (X86_HYBRID_CPU) which leads to three distinct possibilities: o If PKG and MC domains coincide, PKG domain is degenerated by sd_parent_degenerate() when building sched domain topology. o If SNC is enabled, PKG domain is never added since "x86_has_numa_in_package" is set and the topology will instead contain NODE and NUMA domains. o On X86_HYBRID_CPU which contains multiple MC groups within the PKG, the PKG domain requires x86_sched_itmt_flags(). Thus, on Intel systems that contains multiple MC groups within the PKG and enables ITMT support, the PKG domain requires x86_sched_itmt_flags(). In all other cases PKG domain is either never added or is degenerated. Thus, returning x86_sched_itmt_flags() unconditionally at PKG domain on Intel systems should not lead to any functional changes. On AMD systems with multiple LLCs (MC groups) within a PKG domain, enabling ITMT support requires setting SD_ASYM_PACKING to the PKG domain since the core rankings are assigned PKG-wide. Core rankings on AMD processors is currently set by the amd-pstate driver when Preferred Core feature is supported. A subset of systems that support Preferred Core feature can be detected using X86_FEATURE_AMD_HETEROGENEOUS_CORES however, this does not cover all the systems that support Preferred Core ranking. Detecting Preferred Core support on AMD systems requires inspecting CPPC Highest Perf on all present CPUs and checking if it differs on at least one CPU. Previous suggestion to use a synthetic feature to detect Preferred Core support [1] was found to be non-trivial to implement since BSP alone cannot detect if Preferred Core is supported and by the time AP comes up, alternatives are patched and setting a X86_FEATURE_* then is not possible. Since x86 processors enabling ITMT support that consists multiple non-NUMA MC groups within a PKG requires SD_ASYM_PACKING flag set at the PKG domain, return x86_sched_itmt_flags unconditionally for the PKG domain. Since x86_die_flags() would have just returned x86_sched_itmt_flags() after the change, remove the unnecessary wrapper and pass x86_sched_itmt_flags() directly as the flags function. Fixes: f3a052391822 ("cpufreq: amd-pstate: Enable amd-pstate preferred core support") Signed-off-by: K Prateek Nayak <[email protected]> Signed-off-by: Peter Zijlstra (Intel) <[email protected]> Reviewed-by: Tim Chen <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Alexandre Cassen <[email protected]> Date: Thu Jan 2 12:11:11 2025 +0200 xfrm: delete intermediate secpath entry in packet offload mode [ Upstream commit 600258d555f0710b9c47fb78d2d80a4aecd608cc ] Packets handled by hardware have added secpath as a way to inform XFRM core code that this path was already handled. That secpath is not needed at all after policy is checked and it is removed later in the stack. However, in the case of IP forwarding is enabled (/proc/sys/net/ipv4/ip_forward), that secpath is not removed and packets which already were handled are reentered to the driver TX path with xfrm_offload set. The following kernel panic is observed in mlx5 in such case: mlx5_core 0000:04:00.0 enp4s0f0np0: Link up mlx5_core 0000:04:00.1 enp4s0f1np1: Link up Initializing XFRM netlink socket IPsec XFRM device driver BUG: kernel NULL pointer dereference, address: 0000000000000000 #PF: supervisor instruction fetch in kernel mode #PF: error_code(0x0010) - not-present page PGD 0 P4D 0 Oops: Oops: 0010 [#1] PREEMPT SMP CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.13.0-rc1-alex #3 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.13.0-1ubuntu1.1 04/01/2014 RIP: 0010:0x0 Code: Unable to access opcode bytes at 0xffffffffffffffd6. RSP: 0018:ffffb87380003800 EFLAGS: 00010206 RAX: ffff8df004e02600 RBX: ffffb873800038d8 RCX: 00000000ffff98cf RDX: ffff8df00733e108 RSI: ffff8df00521fb80 RDI: ffff8df001661f00 RBP: ffffb87380003850 R08: ffff8df013980000 R09: 0000000000000010 R10: 0000000000000002 R11: 0000000000000002 R12: ffff8df001661f00 R13: ffff8df00521fb80 R14: ffff8df00733e108 R15: ffff8df011faf04e FS: 0000000000000000(0000) GS:ffff8df46b800000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffffffffffffd6 CR3: 0000000106384000 CR4: 0000000000350ef0 Call Trace: <IRQ> ? show_regs+0x63/0x70 ? __die_body+0x20/0x60 ? __die+0x2b/0x40 ? page_fault_oops+0x15c/0x550 ? do_user_addr_fault+0x3ed/0x870 ? exc_page_fault+0x7f/0x190 ? asm_exc_page_fault+0x27/0x30 mlx5e_ipsec_handle_tx_skb+0xe7/0x2f0 [mlx5_core] mlx5e_xmit+0x58e/0x1980 [mlx5_core] ? __fib_lookup+0x6a/0xb0 dev_hard_start_xmit+0x82/0x1d0 sch_direct_xmit+0xfe/0x390 __dev_queue_xmit+0x6d8/0xee0 ? __fib_lookup+0x6a/0xb0 ? internal_add_timer+0x48/0x70 ? mod_timer+0xe2/0x2b0 neigh_resolve_output+0x115/0x1b0 __neigh_update+0x26a/0xc50 neigh_update+0x14/0x20 arp_process+0x2cb/0x8e0 ? __napi_build_skb+0x5e/0x70 arp_rcv+0x11e/0x1c0 ? dev_gro_receive+0x574/0x820 __netif_receive_skb_list_core+0x1cf/0x1f0 netif_receive_skb_list_internal+0x183/0x2a0 napi_complete_done+0x76/0x1c0 mlx5e_napi_poll+0x234/0x7a0 [mlx5_core] __napi_poll+0x2d/0x1f0 net_rx_action+0x1a6/0x370 ? atomic_notifier_call_chain+0x3b/0x50 ? irq_int_handler+0x15/0x20 [mlx5_core] handle_softirqs+0xb9/0x2f0 ? handle_irq_event+0x44/0x60 irq_exit_rcu+0xdb/0x100 common_interrupt+0x98/0xc0 </IRQ> <TASK> asm_common_interrupt+0x27/0x40 RIP: 0010:pv_native_safe_halt+0xb/0x10 Code: 09 c3 66 66 2e 0f 1f 84 00 00 00 00 00 66 90 0f 22 0f 1f 84 00 00 00 00 00 90 eb 07 0f 00 2d 7f e9 36 00 fb 40 00 83 ff 07 77 21 89 ff ff 24 fd 88 3d a1 bd 0f 21 f8 RSP: 0018:ffffffffbe603de8 EFLAGS: 00000202 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000f92f46680 RDX: 0000000000000037 RSI: 00000000ffffffff RDI: 00000000000518d4 RBP: ffffffffbe603df0 R08: 000000cd42e4dffb R09: ffffffffbe603d70 R10: 0000004d80d62680 R11: 0000000000000001 R12: ffffffffbe60bf40 R13: 0000000000000000 R14: 0000000000000000 R15: ffffffffbe60aff8 ? default_idle+0x9/0x20 arch_cpu_idle+0x9/0x10 default_idle_call+0x29/0xf0 do_idle+0x1f2/0x240 cpu_startup_entry+0x2c/0x30 rest_init+0xe7/0x100 start_kernel+0x76b/0xb90 x86_64_start_reservations+0x18/0x30 x86_64_start_kernel+0xc0/0x110 ? setup_ghcb+0xe/0x130 common_startup_64+0x13e/0x141 </TASK> Modules linked in: esp4_offload esp4 xfrm_interface xfrm6_tunnel tunnel4 tunnel6 xfrm_user xfrm_algo binfmt_misc intel_rapl_msr intel_rapl_common kvm_amd ccp kvm input_leds serio_raw qemu_fw_cfg sch_fq_codel dm_multipath scsi_dh_rdac scsi_dh_emc scsi_dh_alua efi_pstore ip_tables x_tables autofs4 raid10 raid456 async_raid6_recov async_memcpy async_pq raid6_pq async_xor xor async_tx libcrc32c raid1 raid0 mlx5_core crct10dif_pclmul crc32_pclmul polyval_clmulni polyval_generic ghash_clmulni_intel sha256_ssse3 sha1_ssse3 ahci mlxfw i2c_i801 libahci i2c_mux i2c_smbus psample virtio_rng pci_hyperv_intf aesni_intel crypto_simd cryptd CR2: 0000000000000000 ---[ end trace 0000000000000000 ]--- RIP: 0010:0x0 Code: Unable to access opcode bytes at 0xffffffffffffffd6. RSP: 0018:ffffb87380003800 EFLAGS: 00010206 RAX: ffff8df004e02600 RBX: ffffb873800038d8 RCX: 00000000ffff98cf RDX: ffff8df00733e108 RSI: ffff8df00521fb80 RDI: ffff8df001661f00 RBP: ffffb87380003850 R08: ffff8df013980000 R09: 0000000000000010 R10: 0000000000000002 R11: 0000000000000002 R12: ffff8df001661f00 R13: ffff8df00521fb80 R14: ffff8df00733e108 R15: ffff8df011faf04e FS: 0000000000000000(0000) GS:ffff8df46b800000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffffffffffffd6 CR3: 0000000106384000 CR4: 0000000000350ef0 Kernel panic - not syncing: Fatal exception in interrupt Kernel Offset: 0x3b800000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff) ---[ end Kernel panic - not syncing: Fatal exception in interrupt ]--- Fixes: 5958372ddf62 ("xfrm: add RX datapath protection for IPsec packet offload mode") Signed-off-by: Alexandre Cassen <[email protected]> Signed-off-by: Leon Romanovsky <[email protected]> Signed-off-by: Steffen Klassert <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Sebastian Sewior <[email protected]> Date: Thu Jan 23 17:20:45 2025 +0100 xfrm: Don't disable preemption while looking up cache state. [ Upstream commit 6c9b7db96db62ee9ad8d359d90ff468d462518c4 ] For the state cache lookup xfrm_input_state_lookup() first disables preemption, to remain on the CPU and then retrieves a per-CPU pointer. Within the preempt-disable section it also acquires netns_xfrm::xfrm_state_lock, a spinlock_t. This lock must not be acquired with explicit disabled preemption (such as by get_cpu()) because this lock becomes a sleeping lock on PREEMPT_RT. To remain on the same CPU is just an optimisation for the CPU local lookup. The actual modification of the per-CPU variable happens with netns_xfrm::xfrm_state_lock acquired. Remove get_cpu() and use the state_cache_input on the current CPU. Reported-by: Alexei Starovoitov <[email protected]> Closes: https://lore.kernel.org/all/CAADnVQKkCLaj=roayH=Mjiiqz_svdf1tsC3OE4EC0E=mAD+L1A@mail.gmail.com/ Fixes: 81a331a0e72dd ("xfrm: Add an inbound percpu state cache.") Signed-off-by: Sebastian Andrzej Siewior <[email protected]> Signed-off-by: Steffen Klassert <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Jianbo Liu <[email protected]> Date: Tue Nov 12 14:10:31 2024 +0200 xfrm: replay: Fix the update of replay_esn->oseq_hi for GSO [ Upstream commit c05c5e5aa163f4682ca97a2f0536575fc7dbdecb ] When skb needs GSO and wrap around happens, if xo->seq.low (seqno of the first skb segment) is before the last seq number but oseq (seqno of the last segment) is after it, xo->seq.low is still bigger than replay_esn->oseq while oseq is smaller than it, so the update of replay_esn->oseq_hi is missed for this case wrap around because of the change in the cited commit. For example, if sending a packet with gso_segs=3 while old replay_esn->oseq=0xfffffffe, we calculate: xo->seq.low = 0xfffffffe + 1 = 0x0xffffffff oseq = 0xfffffffe + 3 = 0x1 (oseq < replay_esn->oseq) is true, but (xo->seq.low < replay_esn->oseq) is false, so replay_esn->oseq_hi is not incremented. To fix this issue, change the outer checking back for the update of replay_esn->oseq_hi. And add new checking inside for the update of packet's oseq_hi. Fixes: 4b549ccce941 ("xfrm: replay: Fix ESN wrap around for GSO") Signed-off-by: Jianbo Liu <[email protected]> Reviewed-by: Patrisious Haddad <[email protected]> Signed-off-by: Leon Romanovsky <[email protected]> Signed-off-by: Steffen Klassert <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Florian Westphal <[email protected]> Date: Thu Nov 28 15:26:25 2024 +0100 xfrm: state: fix out-of-bounds read during lookup [ Upstream commit e952837f3ddb0ff726d5b582aa1aad9aa38d024d ] lookup and resize can run in parallel. The xfrm_state_hash_generation seqlock ensures a retry, but the hash functions can observe a hmask value that is too large for the new hlist array. rehash does: rcu_assign_pointer(net->xfrm.state_bydst, ndst) [..] net->xfrm.state_hmask = nhashmask; While state lookup does: h = xfrm_dst_hash(net, daddr, saddr, tmpl->reqid, encap_family); hlist_for_each_entry_rcu(x, net->xfrm.state_bydst + h, bydst) { This is only safe in case the update to state_bydst is larger than net->xfrm.xfrm_state_hmask (or if the lookup function gets serialized via state spinlock again). Fix this by prefetching state_hmask and the associated pointers. The xfrm_state_hash_generation seqlock retry will ensure that the pointer and the hmask will be consistent. The existing helpers, like xfrm_dst_hash(), are now unsafe for RCU side, add lockdep assertions to document that they are only safe for insert side. xfrm_state_lookup_byaddr() uses the spinlock rather than RCU. AFAICS this is an oversight from back when state lookup was converted to RCU, this lock should be replaced with RCU in a future patch. Reported-by: [email protected] Closes: https://lore.kernel.org/netdev/CACT4Y+azwfrE3uz6A5ZErov5YN2LYBN5KrsymBerT36VU8qzBA@mail.gmail.com/ Diagnosed-by: Dmitry Vyukov <[email protected]> Fixes: c2f672fc9464 ("xfrm: state lookup can be lockless") Signed-off-by: Florian Westphal <[email protected]> Signed-off-by: Steffen Klassert <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Christoph Hellwig <[email protected]> Date: Thu Jan 16 07:01:41 2025 +0100 xfs: check for dead buffers in xfs_buf_find_insert commit 07eae0fa67ca4bbb199ad85645e0f9dfaef931cd upstream. Commit 32dd4f9c506b ("xfs: remove a superflous hash lookup when inserting new buffers") converted xfs_buf_find_insert to use rhashtable_lookup_get_insert_fast and thus an operation that returns the existing buffer when an insert would duplicate the hash key. But this code path misses the check for a buffer with a reference count of zero, which could lead to reusing an about to be freed buffer. Fix this by using the same atomic_inc_not_zero pattern as xfs_buf_insert. Fixes: 32dd4f9c506b ("xfs: remove a superflous hash lookup when inserting new buffers") Signed-off-by: Christoph Hellwig <[email protected]> Reviewed-by: Dave Chinner <[email protected]> Reviewed-by: Darrick J. Wong <[email protected]> Cc: [email protected] # v6.0 Signed-off-by: Carlos Maiolino <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Darrick J. Wong <[email protected]> Date: Thu Dec 12 14:37:56 2024 -0800 xfs: don't over-report free space or inodes in statvfs commit 4b8d867ca6e2fc6d152f629fdaf027053b81765a upstream. Emmanual Florac reports a strange occurrence when project quota limits are enabled, free space is lower than the remaining quota, and someone runs statvfs: # mkfs.xfs -f /dev/sda # mount /dev/sda /mnt -o prjquota # xfs_quota -x -c 'limit -p bhard=2G 55' /mnt # mkdir /mnt/dir # xfs_io -c 'chproj 55' -c 'chattr +P' -c 'stat -vvvv' /mnt/dir # fallocate -l 19g /mnt/a # df /mnt /mnt/dir Filesystem Size Used Avail Use% Mounted on /dev/sda 20G 20G 345M 99% /mnt /dev/sda 2.0G 0 2.0G 0% /mnt I think the bug here is that xfs_fill_statvfs_from_dquot unconditionally assigns to f_bfree without checking that the filesystem has enough free space to fill the remaining project quota. However, this is a longstanding behavior of xfs so it's unclear what to do here. Cc: <[email protected]> # v2.6.18 Fixes: 932f2c323196c2 ("[XFS] statvfs component of directory/project quota support, code originally by Glen.") Reported-by: Emmanuel Florac <[email protected]> Signed-off-by: "Darrick J. Wong" <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Darrick J. Wong <[email protected]> Date: Tue Dec 17 13:43:06 2024 -0800 xfs: don't shut down the filesystem for media failures beyond end of log commit f4ed93037966aea07ae6b10ab208976783d24e2e upstream. If the filesystem has an external log device on pmem and the pmem reports a media error beyond the end of the log area, don't shut down the filesystem because we don't use that space. Cc: <[email protected]> # v6.0 Fixes: 6f643c57d57c56 ("xfs: implement ->notify_failure() for XFS") Signed-off-by: "Darrick J. Wong" <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Long Li <[email protected]> Date: Sat Jan 11 15:05:44 2025 +0800 xfs: fix mount hang during primary superblock recovery failure commit efebe42d95fbba91dca6e3e32cb9e0612eb56de5 upstream. When mounting an image containing a log with sb modifications that require log replay, the mount process hang all the time and stack as follows: [root@localhost ~]# cat /proc/557/stack [<0>] xfs_buftarg_wait+0x31/0x70 [<0>] xfs_buftarg_drain+0x54/0x350 [<0>] xfs_mountfs+0x66e/0xe80 [<0>] xfs_fs_fill_super+0x7f1/0xec0 [<0>] get_tree_bdev_flags+0x186/0x280 [<0>] get_tree_bdev+0x18/0x30 [<0>] xfs_fs_get_tree+0x1d/0x30 [<0>] vfs_get_tree+0x2d/0x110 [<0>] path_mount+0xb59/0xfc0 [<0>] do_mount+0x92/0xc0 [<0>] __x64_sys_mount+0xc2/0x160 [<0>] x64_sys_call+0x2de4/0x45c0 [<0>] do_syscall_64+0xa7/0x240 [<0>] entry_SYSCALL_64_after_hwframe+0x76/0x7e During log recovery, while updating the in-memory superblock from the primary SB buffer, if an error is encountered, such as superblock corruption occurs or some other reasons, we will proceed to out_release and release the xfs_buf. However, this is insufficient because the xfs_buf's log item has already been initialized and the xfs_buf is held by the buffer log item as follows, the xfs_buf will not be released, causing the mount thread to hang. xlog_recover_do_primary_sb_buffer xlog_recover_do_reg_buffer xlog_recover_validate_buf_type xfs_buf_item_init(bp, mp) The solution is straightforward, we simply need to allow it to be handled by the normal buffer write process. The filesystem will be shutdown before the submission of buffer_list in xlog_do_recovery_pass(), ensuring the correct release of the xfs_buf as follows: xlog_do_recovery_pass error = xlog_recover_process xlog_recover_process_data xlog_recover_process_ophdr xlog_recovery_process_trans ... xlog_recover_buf_commit_pass2 error = xlog_recover_do_primary_sb_buffer //Encounter error and return if (error) goto out_writebuf ... out_writebuf: xfs_buf_delwri_queue(bp, buffer_list) //add bp to list return error ... if (!list_empty(&buffer_list)) if (error) xlog_force_shutdown(log, SHUTDOWN_LOG_IO_ERROR); //shutdown first xfs_buf_delwri_submit(&buffer_list); //submit buffers in list __xfs_buf_submit if (bp->b_mount->m_log && xlog_is_shutdown(bp->b_mount->m_log)) xfs_buf_ioend_fail(bp) //release bp correctly Fixes: 6a18765b54e2 ("xfs: update the file system geometry after recoverying superblock buffers") Cc: [email protected] # v6.12 Signed-off-by: Long Li <[email protected]> Reviewed-by: Darrick J. Wong <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]> Signed-off-by: Carlos Maiolino <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Darrick J. Wong <[email protected]> Date: Tue Dec 17 15:00:49 2024 -0800 xfs: release the dquot buf outside of qli_lock commit 1aacd3fac248902ea1f7607f2d12b93929a4833b upstream. Lai Yi reported a lockdep complaint about circular locking: Chain exists of: &lp->qli_lock --> &bch->bc_lock --> &l->lock Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&l->lock); lock(&bch->bc_lock); lock(&l->lock); lock(&lp->qli_lock); I /think/ the problem here is that xfs_dquot_attach_buf during quotacheck will release the buffer while it's holding the qli_lock. Because this is a cached buffer, xfs_buf_rele_cached takes b_lock before decrementing b_hold. Other threads have taught lockdep that a locking dependency chain is bp->b_lock -> bch->bc_lock -> l(ru)->lock; and that another chain is l(ru)->lock -> lp->qli_lock. Hence we do not want to take b_lock while holding qli_lock. Reported-by: [email protected] Cc: <[email protected]> # v6.13-rc3 Fixes: ca378189fdfa89 ("xfs: convert quotacheck to attach dquot buffers") Tested-by: [email protected] Signed-off-by: "Darrick J. Wong" <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>