summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2024-11-10powerpc/fadump: allocate memory for additional parameters earlyHari Bathini
Memory for passing additional parameters to fadump capture kernel is allocated during subsys_initcall level, using memblock. But as slab is already available by this time, allocation happens via the buddy allocator. This may work for radix MMU but is likely to fail in most cases for hash MMU as hash MMU needs this memory in the first memory block for it to be accessible in real mode in the capture kernel (second boot). So, allocate memory for additional parameters area as soon as MMU mode is obvious. Fixes: 683eab94da75 ("powerpc/fadump: setup additional parameters for dump capture kernel") Reported-by: Venkat Rao Bagalkote <venkat88@linux.vnet.ibm.com> Closes: https://lore.kernel.org/lkml/a70e4064-a040-447b-8556-1fd02f19383d@linux.vnet.ibm.com/T/#u Signed-off-by: Hari Bathini <hbathini@linux.ibm.com> Signed-off-by: Sourabh Jain <sourabhjain@linux.ibm.com> Tested-by: Venkat Rao Bagalkote <venkat88@linux.vnet.ibm.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://patch.msgid.link/20241107055817.489795-1-sourabhjain@linux.ibm.com
2024-11-10powerpc/ftrace: Fix ftrace bug with KASAN=yMichael Ellerman
Booting a KASAN=y kernel with the recently added ftrace out-of-line support causes a warning at boot: ------------[ cut here ]------------ Stub index overflow (1729 > 1728) WARNING: CPU: 0 PID: 0 at arch/powerpc/kernel/trace/ftrace.c:209 ftrace_init_nop+0x408/0x444 ... NIP ftrace_init_nop+0x408/0x444 LR ftrace_init_nop+0x404/0x444 Call Trace: ftrace_init_nop+0x404/0x444 (unreliable) ftrace_process_locs+0x544/0x8a0 ftrace_init+0xb4/0x22c start_kernel+0x1dc/0x4d4 start_here_common+0x1c/0x20 ... ftrace failed to modify [<c0000000030beddc>] _sub_I_65535_1+0x8/0x3c actual: 00:00:00:60 Initializing ftrace call sites ftrace record flags: 0 (0) expected tramp: c00000000008b418 ------------[ cut here ]------------ The function in question, _sub_I_65535_1 is some sort of trampoline generated for KASAN, and is in the .text.startup section. That section is part of INIT_TEXT, meaning is_kernel_inittext() returns true for it. But the script that determines how many out-of-line ftrace stubs are needed isn't doesn't consider .text.startup as inittext, leading to there not being enough space for the init stubs. Conversely the logic to calculate how many stubs are needed for the text section isn't filtering out the symbols in .text.startup and so ends up over counting. Fix both problems by calculating the total number of stubs first, then the number that count as inittext, and then subtract the latter from the former to get the count for the text section. Fixes: eec37961a56a ("powerpc64/ftrace: Move ftrace sequence out of line") Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://patch.msgid.link/20241107111630.31068-1-mpe@ellerman.id.au
2024-11-10usb: typec: ucsi: glink: be more precise on orientation-aware portsDmitry Baryshkov
Instead of checking if any of the USB-C ports have orientation GPIO and thus is orientation-aware, check for the GPIO for the port being registered. There are no boards that are affected by this change at this moment, so the patch is not marked as a fix, but it might affect other boards in future. Reviewed-by: Abel Vesa <abel.vesa@linaro.org> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Reviewed-by: Johan Hovold <johan+linaro@kernel.org> Tested-by: Johan Hovold <johan+linaro@kernel.org> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://lore.kernel.org/r/20241109-ucsi-glue-fixes-v2-2-8b21ff4f9fbe@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-11-10usb: typec: ucsi: glink: fix off-by-one in connector_statusDmitry Baryshkov
UCSI connector's indices start from 1 up to 3, PMIC_GLINK_MAX_PORTS. Correct the condition in the pmic_glink_ucsi_connector_status() callback, fixing Type-C orientation reporting for the third USB-C connector. Fixes: 76716fd5bf09 ("usb: typec: ucsi: glink: move GPIO reading into connector_status callback") Cc: stable@vger.kernel.org Reported-by: Abel Vesa <abel.vesa@linaro.org> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Reviewed-by: Johan Hovold <johan+linaro@kernel.org> Tested-by: Johan Hovold <johan+linaro@kernel.org> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://lore.kernel.org/r/20241109-ucsi-glue-fixes-v2-1-8b21ff4f9fbe@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-11-10usb: gadget: function: remove redundant else statementColin Ian King
After an initial range change on the insigned int alt being > 1 the only possible values for alt are 0 or 1. Therefore the else statement for values other than 0 or 1 is redundant and can be removed. Replace the else if (all == 1) check with just an else. Signed-off-by: Colin Ian King <colin.i.king@gmail.com> Reviewed-by: Takashi Iwai <tiwai@suse.de> Link: https://lore.kernel.org/5f54ffd0-b5fe-4203-a626-c166becad362@gmail.com Link: https://lore.kernel.org/r/20241107133348.22762-1-colin.i.king@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-11-10mei: vsc: Improve error logging in vsc_identify_silicon()Hans de Goede
vsc_identify_silicon() returns -EINVAL in various places without logging what is going on. And there are several bug reports about mei_vsc_hw_reset() failing with -EINVAL before the "silicon stepping version is %u:%u" message get logged, indicating this is coming from vsc_identify_silicon(): [ 10.949657] intel_vsc intel_vsc: hw_reset failed ret = -22 [ 10.988899] intel_vsc intel_vsc: hw_reset failed ret = -22 [ 11.027140] intel_vsc intel_vsc: hw_reset failed ret = -22 [ 11.027151] intel_vsc intel_vsc: reset: reached maximal consecutive resets: disabling the device [ 11.027155] intel_vsc intel_vsc: reset failed ret = -19 [ 11.027157] intel_vsc intel_vsc: link layer initialization failed. [ 11.027159] intel_vsc intel_vsc: error -ENODEV: init hw failed Add proper error logging to mei_vsc_hw_reset() so that it will be clear why it is failing when it fails. Link: https://github.com/intel/ivsc-driver/issues/51 Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20241108151234.36884-1-hdegoede@redhat.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-11-10mei: vsc: Do not re-enable interrupt from vsc_tp_reset()Hans de Goede
The only 2 callers of vsc_tp_reset() are: 1. mei_vsc_hw_reset(), which immediataly calls vsc_tp_intr_disable() afterwards. 2. vsc_tp_shutdown() which immediately calls free_irq() afterwards. So neither actually wants the interrupt to be enabled after resetting the chip and having the interrupt enabled for a short time afer the reset is undesirable. Drop the enable_irq() call from vsc_tp_reset(), so that the interrupt is left disabled after vsc_tp_reset(). Link: https://github.com/intel/ivsc-driver/issues/51 Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20241106220102.40549-1-hdegoede@redhat.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-11-10dt-bindings: spmi: qcom,x1e80100-spmi-pmic-arb: Add SAR2130P compatibleDmitry Baryshkov
SAR2130P has SPMI v7 arbiter. Although it has only a single bus configuration, use the new bindings for v7 platforms. Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://lore.kernel.org/r/20241017-sar2130p-spmi-v1-1-43ac741ee071@linaro.org Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Stephen Boyd <sboyd@kernel.org> Link: https://lore.kernel.org/r/20241109002829.160973-4-sboyd@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-11-10dt-bindings: spmi: spmi-mtk-pmif: Add compatible for MT8188Fei Shao
Add compatible string for the SPMI block on MT8188 SoC, which is compatible with the one used on MT8195. Acked-by: Rob Herring (Arm) <robh@kernel.org> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by: Fei Shao <fshao@chromium.org> Link: https://lore.kernel.org/r/20240911143429.850071-2-fshao@chromium.org Signed-off-by: Stephen Boyd <sboyd@kernel.org> Acked-by: Stephen Boyd <sboyd@kernel.org> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.dleregno@collabora.com> Link: https://lore.kernel.org/r/20241109002829.160973-3-sboyd@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-11-10spmi: pmic-arb: fix return path in for_each_available_child_of_node()Javier Carrasco
This loop requires explicit calls to of_node_put() upon early exits (break, goto, return) to decrement the child refcounter and avoid memory leaks if the child is not required out of the loop. A more robust solution is using the scoped variant of the macro, which automatically calls of_node_put() when the child goes out of scope. Cc: stable@vger.kernel.org Fixes: 979987371739 ("spmi: pmic-arb: Add multi bus support") Signed-off-by: Javier Carrasco <javier.carrasco.cruz@gmail.com> Link: https://lore.kernel.org/r/20241001-spmi-pmic-arb-scoped-v1-1-5872bab34ed6@gmail.com Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Signed-off-by: Stephen Boyd <sboyd@kernel.org> Link: https://lore.kernel.org/r/20241109002829.160973-2-sboyd@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-11-10cacheinfo: Use of_property_present() for non-boolean propertiesRob Herring (Arm)
The use of of_property_read_bool() for non-boolean properties is deprecated in favor of of_property_present() when testing for property presence. Signed-off-by: Rob Herring (Arm) <robh@kernel.org> Link: https://lore.kernel.org/r/20241104190342.270883-1-robh@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-11-10cdx: Fix cdx_mmap_resource() after constifying attr in ->mmap()Nathan Chancellor
Commit 94a20fb9af16 ("sysfs: treewide: constify attribute callback of bin_attribute::mmap()") missed updating the attr parameter of cdx_mmap_resource(), resulting in a build failure. drivers/cdx/cdx.c: In function 'cdx_create_res_attr': drivers/cdx/cdx.c:773:24: error: assignment to 'int (*)(struct file *, struct kobject *, const struct bin_attribute *, struct vm_area_struct *)' from incompatible pointer type 'int (*)(struct file *, struct kobject *, struct bin_attribute *, struct vm_area_struct *)' [-Wincompatible-pointer-types] 773 | res_attr->mmap = cdx_mmap_resource; | ^ Update cdx_mmap_resource() to match, resolving the build failure. Fixes: 94a20fb9af16 ("sysfs: treewide: constify attribute callback of bin_attribute::mmap()") Signed-off-by: Nathan Chancellor <nathan@kernel.org> Tested-by: Thorsten Leemhuis <linux@leemhuis.info> Reviewed-by: Thomas Weißschuu <linux@weissschuh.net> Link: https://lore.kernel.org/r/20241107-sysfs-const-mmap-fix-cdx-v1-1-2ed9b7cd5f8b@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-11-10arm64: dts: allwinner: a100: perf1: Add eMMC and MMC nodeYangtao Li
A100 perf1 hava MicroSD slot and on-board eMMC module, add support for them. Signed-off-by: Yangtao Li <frank@allwinnertech.com> Signed-off-by: Cody Eksal <masterr3c0rd@epochal.quest> Link: https://patch.msgid.link/20241031070232.1793078-11-masterr3c0rd@epochal.quest [wens@csie.org: cherry-picked out of series and GPIO header inclusion added] Signed-off-by: Chen-Yu Tsai <wens@csie.org>
2024-11-10arm64: dts: allwinner: pinephone: Add mount matrix to accelerometerDragan Simic
The way InvenSense MPU-6050 accelerometer is mounted on the user-facing side of the Pine64 PinePhone mainboard, which makes it rotated 90 degrees counter- clockwise, [1] requires the accelerometer's x- and y-axis to be swapped, and the direction of the accelerometer's y-axis to be inverted. Rectify this by adding a mount-matrix to the accelerometer definition in the Pine64 PinePhone dtsi file. [1] https://files.pine64.org/doc/PinePhone/PinePhone%20mainboard%20bottom%20placement%20v1.1%2020191031.pdf Fixes: 91f480d40942 ("arm64: dts: allwinner: Add initial support for Pine64 PinePhone") Cc: stable@vger.kernel.org Suggested-by: Ondrej Jirman <megi@xff.cz> Suggested-by: Andrey Skvortsov <andrej.skvortzov@gmail.com> Signed-off-by: Dragan Simic <dsimic@manjaro.org> Reviewed-by: Andrey Skvortsov <andrej.skvortzov@gmail.com> Link: https://patch.msgid.link/129f0c754d071cca1db5d207d9d4a7bd9831dff7.1726773282.git.dsimic@manjaro.org [wens@csie.org: Replaced Helped-by with Suggested-by] Signed-off-by: Chen-Yu Tsai <wens@csie.org>
2024-11-10Staging: gpib: gpib_os.c - Remove unnecessary OOM messageOmer Faruk BULUT
It dublicate the MM subsystem generic OOM message. This patch fixes the following checkpatch warning. WARNING: Possible unnecessary 'out of memory' message Signed-off-by: Omer Faruk BULUT <m.omerfarukbulut@gmail.com> Link: https://lore.kernel.org/r/20241109130554.3652-1-m.omerfarukbulut@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-11-10staging: gpib: avoid unintended sign extensionKees Bakker
The code was basically like this (assuming size_t can be u64) var_u64 |= var_u8 << 24 var_u8 is first promoted to i32 and then the shift is done. Next, it is promoted to u64 by first signextending to 64 bits. This is very unlikely what was intended. So now it is first forced to u32. var_u64 |= (u32)var_u8 << 24 This was detected by Coverity, CID 1600792. Fixes: 4c41fe886a56 ("staging: gpib: Add Agilent/Keysight 82357x USB GPIB driver") Signed-off-by: Kees Bakker <kees@ijzerbout.nl> Link: https://lore.kernel.org/r/20241108201207.1194F18DDF5@bout3.ijzerbout.nl Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-11-10staging: vchiq_debugfs: Use forward declarationsUmang Jain
Use forward declarations for struct vchiq_state and vchiq_instance. We can then drop the vchiq_core.h header from vchiq_debugfs.h. Signed-off-by: Umang Jain <umang.jain@ideasonboard.com> Link: https://lore.kernel.org/r/20241107194806.90408-4-umang.jain@ideasonboard.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-11-10staging: vchiq_core: Rectify header include for vchiq_dump_state()Umang Jain
The header vchiq_core.h does not need <linux/debugfs.h>. It needs the <linux/seq_file.h> for vchiq_dump_state() to dump the vchiq state through vchiq_debugfs.[ch]. Signed-off-by: Umang Jain <umang.jain@ideasonboard.com> Link: https://lore.kernel.org/r/20241107194806.90408-3-umang.jain@ideasonboard.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-11-10staging: vc04_services: Cleanup TODO entryUmang Jain
The TODO entry "Fix behvaiour of message handling" no longer applies due to killable completions [1]. Drop the entry from TODO list. [1] https://lore.kernel.org/all/20240918163100.870596-1-umang.jain@ideasonboard.com/ Signed-off-by: Umang Jain <umang.jain@ideasonboard.com> Link: https://lore.kernel.org/r/20241107194806.90408-2-umang.jain@ideasonboard.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-11-10staging: most: Remove TODO contact informationDominik Karol Piątkowski
Remove contact information from TODO file, as it is redundant and can get stale easily. Signed-off-by: Dominik Karol Piątkowski <dominik.karol.piatkowski@protonmail.com> Link: https://lore.kernel.org/r/20241107172908.95530-5-dominik.karol.piatkowski@protonmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-11-10staging: rtl8723bs: Remove TODO contact informationDominik Karol Piątkowski
Remove contact information from TODO file, as it is redundant and can get stale easily. Signed-off-by: Dominik Karol Piątkowski <dominik.karol.piatkowski@protonmail.com> Link: https://lore.kernel.org/r/20241107172908.95530-4-dominik.karol.piatkowski@protonmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-11-10staging: sm750fb: Remove TODO contact informationDominik Karol Piątkowski
Remove contact information from TODO file, as it is redundant and can get stale easily. Signed-off-by: Dominik Karol Piątkowski <dominik.karol.piatkowski@protonmail.com> Link: https://lore.kernel.org/r/20241107172908.95530-3-dominik.karol.piatkowski@protonmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-11-10staging: iio: Remove TODO fileDominik Karol Piątkowski
Remove TODO file, as it only contains contact information. Signed-off-by: Dominik Karol Piątkowski <dominik.karol.piatkowski@protonmail.com> Acked-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Link: https://lore.kernel.org/r/20241107172908.95530-2-dominik.karol.piatkowski@protonmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-11-10staging: greybus: uart: Fix atomicity violation in get_serial_info()Qiu-ji Chen
Our static checker found a bug where set_serial_info() uses a mutex, but get_serial_info() does not. Fortunately, the impact of this is relatively minor. It doesn't cause a crash or any other serious issues. However, if a race condition occurs between set_serial_info() and get_serial_info(), there is a chance that the data returned by get_serial_info() will be meaningless. Signed-off-by: Qiu-ji Chen <chenqiuji666@gmail.com> Fixes: 0aad5ad563c8 ("greybus/uart: switch to ->[sg]et_serial()") Reviewed-by: Johan Hovold <johan+linaro@kernel.org> Reviewed-by: Dan Carpenter <dan.carpenter@linaro.org> Reviewed-by: Alex Elder <elder@riscstar.com> Link: https://lore.kernel.org/r/20241107113337.402042-1-chenqiuji666@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-11-10hwrng: bcm74110 - Add Broadcom BCM74110 RNG driverMarkus Mayer
Add a driver for the random number generator present on the Broadcom BCM74110 SoC. Signed-off-by: Markus Mayer <mmayer@broadcom.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2024-11-10dt-bindings: rng: add binding for BCM74110 RNGMarkus Mayer
Add a binding for the random number generator used on the BCM74110. Signed-off-by: Markus Mayer <mmayer@broadcom.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2024-11-10padata: Clean up in padata_do_multithreaded()Zicheng Qu
In commit 24cc57d8faaa ("padata: Honor the caller's alignment in case of chunk_size 0"), the line 'ps.chunk_size = max(ps.chunk_size, 1ul)' was added, making 'ps.chunk_size = 1U' redundant and never executed. Signed-off-by: Zicheng Qu <quzicheng@huawei.com> Acked-by: Daniel Jordan <daniel.m.jordan@oracle.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2024-11-10crypto: inside-secure - Fix the return value of safexcel_xcbcmac_cra_init()Li Huafei
The commit 320406cb60b6 ("crypto: inside-secure - Replace generic aes with libaes") replaced crypto_alloc_cipher() with kmalloc(), but did not modify the handling of the return value. When kmalloc() returns NULL, PTR_ERR_OR_ZERO(NULL) returns 0, but in fact, the memory allocation has failed, and -ENOMEM should be returned. Fixes: 320406cb60b6 ("crypto: inside-secure - Replace generic aes with libaes") Signed-off-by: Li Huafei <lihuafei1@huawei.com> Acked-by: Antoine Tenart <atenart@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2024-11-10crypto: qat - Fix missing destroy_workqueue in adf_init_aer()Wang Hai
The adf_init_aer() won't destroy device_reset_wq when alloc_workqueue() for device_sriov_wq failed. Add destroy_workqueue for device_reset_wq to fix this issue. Fixes: 4469f9b23468 ("crypto: qat - re-enable sriov after pf reset") Signed-off-by: Wang Hai <wanghai38@huawei.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2024-11-10crypto: rsassa-pkcs1 - Reinstate support for legacy protocolsLukas Wunner
Commit 1e562deacecc ("crypto: rsassa-pkcs1 - Migrate to sig_alg backend") enforced that rsassa-pkcs1 sign/verify operations specify a hash algorithm. That is necessary because per RFC 8017 sec 8.2, a hash algorithm identifier must be prepended to the hash before generating or verifying the signature ("Full Hash Prefix"). However the commit went too far in that it changed user space behavior: KEYCTL_PKEY_QUERY system calls now return -EINVAL unless they specify a hash algorithm. Intel Wireless Daemon (iwd) is one application issuing such system calls (for EAP-TLS). Closer analysis of the Embedded Linux Library (ell) used by iwd reveals that the problem runs even deeper: When iwd uses TLS 1.1 or earlier, it not only queries for keys, but performs sign/verify operations without specifying a hash algorithm. These legacy TLS versions concatenate an MD5 to a SHA-1 hash and omit the Full Hash Prefix: https://git.kernel.org/pub/scm/libs/ell/ell.git/tree/ell/tls-suites.c#n97 TLS 1.1 was deprecated in 2021 by RFC 8996, but removal of support was inadvertent in this case. It probably should be coordinated with iwd maintainers first. So reinstate support for such legacy protocols by defaulting to hash algorithm "none" which uses an empty Full Hash Prefix. If it is later on decided to remove TLS 1.1 support but still allow KEYCTL_PKEY_QUERY without a hash algorithm, that can be achieved by reverting the present commit and replacing it with the following patch: https://lore.kernel.org/r/ZxalYZwH5UiGX5uj@wunner.de/ It's worth noting that Python's cryptography library gained support for such legacy use cases very recently, so they do seem to still be a thing. The Python developers identified IKE version 1 as another protocol omitting the Full Hash Prefix: https://github.com/pyca/cryptography/issues/10226 https://github.com/pyca/cryptography/issues/5495 The author of those issues, Zoltan Kelemen, spent considerable effort searching for test vectors but only found one in a 2019 blog post by Kevin Jones. Add it to testmgr.h to verify correctness of this feature. Examination of wpa_supplicant as well as various IKE daemons (libreswan, strongswan, isakmpd, raccoon) has determined that none of them seems to use the kernel's Key Retention Service, so iwd is the only affected user space application known so far. Fixes: 1e562deacecc ("crypto: rsassa-pkcs1 - Migrate to sig_alg backend") Reported-by: Klara Modin <klarasmodin@gmail.com> Tested-by: Klara Modin <klarasmodin@gmail.com> Closes: https://lore.kernel.org/r/2ed09a22-86c0-4cf0-8bda-ef804ccb3413@gmail.com/ Signed-off-by: Lukas Wunner <lukas@wunner.de> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2024-11-09s390/dasd: Fix typo in commentYu Jiaoliang
Fix typo in comment: requeust->request, Removve->Remove, notthing->nothing. Signed-off-by: Yu Jiaoliang <yujiaoliang@vivo.com> Signed-off-by: Stefan Haberland <sth@linux.ibm.com> Link: https://lore.kernel.org/r/20241108133913.3068782-3-sth@linux.ibm.com Signed-off-by: Jens Axboe <axboe@kernel.dk>
2024-11-09s390/dasd: fix redundant /proc/dasd* entries removalMiroslav Franc
In case of an early failure in dasd_init, dasd_proc_init is never called and /proc/dasd* files are never created. That can happen, for example, if an incompatible or incorrect argument is provided to the dasd_mod.dasd= kernel parameter. However, the attempted removal of /proc/dasd* files causes 8 warnings and backtraces in this case. 4 on the error path within dasd_init and 4 when the dasd module is unloaded. Notice the "removing permanent /proc entry 'devices'" message that is caused by the dasd_proc_exit function trying to remove /proc/devices instead of /proc/dasd/devices since dasd_proc_root_entry is NULL and /proc/devices is indeed permanent. Example: ------------[ cut here ]------------ removing permanent /proc entry 'devices' WARNING: CPU: 6 PID: 557 at fs/proc/generic.c:701 remove_proc_entry+0x22e/0x240 CPU: 6 PID: 557 Comm: modprobe Not tainted 6.10.5-1-default #1 openSUSE Tumbleweed f6917bfd6e5a5c7a7e900e0e3b517786fb5c6301 Hardware name: QEMU 8561 QEMU (KVM/Linux) Krnl PSW : 0704c00180000000 000003fffed0e9f2 (remove_proc_entry+0x232/0x240) R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:0 PM:0 RI:0 EA:3 Krnl GPRS: 000003ff00000027 000003ff00000023 0000000000000028 000002f200000000 000002f3f05bec20 0000037ffecfb7d0 000003ffffdabab0 000003ff7ee4ec72 000003ff7ee4ec72 0000000000000007 000002f280e22600 000002f280e22688 000003ffa252cfa0 0000000000010000 000003fffed0e9ee 0000037ffecfba38 Krnl Code: 000003fffed0e9e2: c020004e7017 larl %r2,000003ffff6dca10 000003fffed0e9e8: c0e5ffdfad24 brasl %r14,000003fffe904430 #000003fffed0e9ee: af000000 mc 0,0 >000003fffed0e9f2: a7f4ff4c brc 15,000003fffed0e88a 000003fffed0e9f6: 0707 bcr 0,%r7 000003fffed0e9f8: 0707 bcr 0,%r7 000003fffed0e9fa: 0707 bcr 0,%r7 000003fffed0e9fc: 0707 bcr 0,%r7 Call Trace: [<000003fffed0e9f2>] remove_proc_entry+0x232/0x240 ([<000003fffed0e9ee>] remove_proc_entry+0x22e/0x240) [<000003ff7ef5a084>] dasd_proc_exit+0x34/0x60 [dasd_mod] [<000003ff7ef560c2>] dasd_exit+0x22/0xc0 [dasd_mod] [<000003ff7ee5a26e>] dasd_init+0x26e/0x280 [dasd_mod] [<000003fffe8ac9d0>] do_one_initcall+0x40/0x220 [<000003fffe9bc758>] do_init_module+0x78/0x260 [<000003fffe9bf3a6>] __do_sys_init_module+0x216/0x250 [<000003ffff37ac9e>] __do_syscall+0x24e/0x2d0 [<000003ffff38cca8>] system_call+0x70/0x98 Last Breaking-Event-Address: [<000003fffef7ea20>] __s390_indirect_jump_r14+0x0/0x10 ---[ end trace 0000000000000000 ]--- ------------[ cut here ]------------ While the cause is a user failure, the dasd module should handle the situation more gracefully. One of the simplest solutions is to make removal of the /proc/dasd* entries idempotent. Signed-off-by: Miroslav Franc <mfranc@suse.cz> [ sth: shortened if clause ] Signed-off-by: Stefan Haberland <sth@linux.ibm.com> Link: https://lore.kernel.org/r/20241108133913.3068782-2-sth@linux.ibm.com Signed-off-by: Jens Axboe <axboe@kernel.dk>
2024-11-09Merge tag 'md-6.13-20241107' of ↵Jens Axboe
https://git.kernel.org/pub/scm/linux/kernel/git/song/md into for-6.13/block Pull raid5 fix from Song. * tag 'md-6.13-20241107' of https://git.kernel.org/pub/scm/linux/kernel/git/song/md: MAINTAINERS: Make Yu Kuai co-maintainer of md/raid subsystem md/raid5: Wait sync io to finish before changing group cnt
2024-11-09loop: fix type of block sizeLi Wang
PAGE_SIZE may be 64K, and the max block size can be PAGE_SIZE, so any variable for holding block size can't be defined as 'unsigned short'. Unfortunately commit 473516b36193 ("loop: use the atomic queue limits update API") passes 'bsize' with type of 'unsigned short' to loop_reconfigure_limits(), and causes LTP/ioctl_loop06 test failure: 12 ioctl_loop06.c:76: TINFO: Using LOOP_SET_BLOCK_SIZE with arg > PAGE_SIZE 13 ioctl_loop06.c:59: TFAIL: Set block size succeed unexpectedly ... 18 ioctl_loop06.c:76: TINFO: Using LOOP_CONFIGURE with block_size > PAGE_SIZE 19 ioctl_loop06.c:59: TFAIL: Set block size succeed unexpectedly Fixes the issue by defining 'block size' variable with 'unsigned int', which is aligned with block layer's definition. (improve commit log & add fixes tag) Fixes: 473516b36193 ("loop: use the atomic queue limits update API") Cc: John Garry <john.g.garry@oracle.com> Cc: Stefan Hajnoczi <stefanha@redhat.com> Cc: Christoph Hellwig <hch@lst.de> Reviewed-by: Damien Le Moal <dlemoal@kernel.org> Reviewed-by: Jan Stancek <jstancek@redhat.com> Signed-off-by: Li Wang <liwang@redhat.com> Signed-off-by: Ming Lei <ming.lei@redhat.com> Reviewed-by: John Garry <john.g.garry@oracle.com> Link: https://lore.kernel.org/r/20241109022744.1126003-1-ming.lei@redhat.com Signed-off-by: Jens Axboe <axboe@kernel.dk>
2024-11-09Revert "fs: nfs: fix missing refcnt by replacing folio_set_private by ↵Trond Myklebust
folio_attach_private" This reverts commit 03e02b94171b1985dd0aa184296fe94425b855a3. As was pointed out during code review, there is no need to use folio_attach_private()/folio_detach_private() when a refcount to the folio is already carried by the struct nfs_page. Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
2024-11-10power: supply: pmu_battery: Set power supply type to BATTERYEd Robbins
If the power supply type is not set it defaults to "Unknown" and upower does not recognise it. In turn battery monitor applications do not see a battery. Setting to POWER_SUPPLY_TYPE_BATTERY fixes this. Signed-off-by: Ed Robbins <edd.robbins@gmail.com> Link: https://lore.kernel.org/r/IOFJLS.120OJ5KJG9R72@googlemail.com Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2024-11-09nfs/localio: must clear res.replen in nfs_local_read_doneNeilBrown
Otherwise memory corruption can occur due to NFSv3 LOCALIO reads leaving garbage in res.replen: - nfs3_read_done() copies that into server->read_hdrsize; from there nfs3_proc_read_setup() copies it to args.replen in new requests. - nfs3_xdr_enc_read3args() passes that to rpc_prepare_reply_pages() which includes it in hdrsize for xdr_init_pages, so that rq_rcv_buf contains a ridiculous len. - This is copied to rq_private_buf and xs_read_stream_request() eventually passes the kvec to sock_recvmsg() which receives incoming data into entirely the wrong place. This is easily reproduced with NFSv3 LOCALIO that is servicing reads when it is made to pivot back to using normal RPC. This switch back to using normal NFSv3 with RPC can occur for a few reasons but this issue was exposed with a test that stops and then restarts the NFSv3 server while LOCALIO is performing heavy read IO. Fixes: 70ba381e1a43 ("nfs: add LOCALIO support") Reported-by: Mike Snitzer <snitzer@kernel.org> Signed-off-by: NeilBrown <neilb@suse.de> Co-developed-by: Mike Snitzer <snitzer@kernel.org> Signed-off-by: Mike Snitzer <snitzer@kernel.org> Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
2024-11-09bridge: Allow deleting FDB entries with non-existent VLANIdo Schimmel
It is currently impossible to delete individual FDB entries (as opposed to flushing) that were added with a VLAN that no longer exists: # ip link add name dummy1 up type dummy # ip link add name br1 up type bridge vlan_filtering 1 # ip link set dev dummy1 master br1 # bridge fdb add 00:11:22:33:44:55 dev dummy1 master static vlan 1 # bridge vlan del vid 1 dev dummy1 # bridge fdb get 00:11:22:33:44:55 br br1 vlan 1 00:11:22:33:44:55 dev dummy1 vlan 1 master br1 static # bridge fdb del 00:11:22:33:44:55 dev dummy1 master vlan 1 RTNETLINK answers: Invalid argument # bridge fdb get 00:11:22:33:44:55 br br1 vlan 1 00:11:22:33:44:55 dev dummy1 vlan 1 master br1 static This is in contrast to MDB entries that can be deleted after the VLAN was deleted: # bridge vlan add vid 10 dev dummy1 # bridge mdb add dev br1 port dummy1 grp 239.1.1.1 permanent vid 10 # bridge vlan del vid 10 dev dummy1 # bridge mdb get dev br1 grp 239.1.1.1 vid 10 dev br1 port dummy1 grp 239.1.1.1 permanent vid 10 # bridge mdb del dev br1 port dummy1 grp 239.1.1.1 permanent vid 10 # bridge mdb get dev br1 grp 239.1.1.1 vid 10 Error: bridge: MDB entry not found. Align the two interfaces and allow user space to delete FDB entries that were added with a VLAN that no longer exists: # ip link add name dummy1 up type dummy # ip link add name br1 up type bridge vlan_filtering 1 # ip link set dev dummy1 master br1 # bridge fdb add 00:11:22:33:44:55 dev dummy1 master static vlan 1 # bridge vlan del vid 1 dev dummy1 # bridge fdb get 00:11:22:33:44:55 br br1 vlan 1 00:11:22:33:44:55 dev dummy1 vlan 1 master br1 static # bridge fdb del 00:11:22:33:44:55 dev dummy1 master vlan 1 # bridge fdb get 00:11:22:33:44:55 br br1 vlan 1 Error: Fdb entry not found. Add a selftest to make sure this behavior does not regress: # ./rtnetlink.sh -t kci_test_fdb_del PASS: bridge fdb del Signed-off-by: Ido Schimmel <idosch@nvidia.com> Reviewed-by: Andy Roulin <aroulin@nvidia.com> Reviewed-by: Petr Machata <petrm@nvidia.com> Acked-by: Nikolay Aleksandrov <razor@blackwall.org> Link: https://patch.msgid.link/20241105133954.350479-1-idosch@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-11-09mlx5/core: Schedule EQ comp tasklet only if necessaryCaleb Sander Mateos
Currently, the mlx5_eq_comp_int() interrupt handler schedules a tasklet to call mlx5_cq_tasklet_cb() if it processes any completions. For CQs whose completions don't need to be processed in tasklet context, this adds unnecessary overhead. In a heavy TCP workload, we see 4% of CPU time spent on the tasklet_trylock() in tasklet_action_common(), with a smaller amount spent on the atomic operations in tasklet_schedule(), tasklet_clear_sched(), and locking the spinlock in mlx5_cq_tasklet_cb(). TCP completions are handled by mlx5e_completion_event(), which schedules NAPI to poll the queue, so they don't need tasklet processing. Schedule the tasklet in mlx5_add_cq_to_tasklet() instead to avoid this overhead. mlx5_add_cq_to_tasklet() is responsible for enqueuing the CQs to be processed in tasklet context, so it can schedule the tasklet. CQs that need tasklet processing have their interrupt comp handler set to mlx5_add_cq_to_tasklet(), so they will schedule the tasklet. CQs that don't need tasklet processing won't schedule the tasklet. To avoid scheduling the tasklet multiple times during the same interrupt, only schedule the tasklet in mlx5_add_cq_to_tasklet() if the tasklet work queue was empty before the new CQ was pushed to it. The additional branch in mlx5_add_cq_to_tasklet(), called for each EQE, may add a small cost for the userspace Infiniband CQs whose completions are processed in tasklet context. But this seems worth it to avoid the tasklet overhead for CQs that don't need it. Note that the mlx4 driver works the same way: it schedules the tasklet in mlx4_add_cq_to_tasklet() and only if the work queue was empty before. Signed-off-by: Caleb Sander Mateos <csander@purestorage.com> Reviewed-by: Parav Pandit <parav@nvidia.com> Acked-by: Tariq Toukan <tariqt@nvidia.com> Acked-by: Saeed Mahameed <saeedm@nvidia.com> Link: https://patch.msgid.link/20241105204000.1807095-1-csander@purestorage.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-11-09selftests: net: add netlink-dumps to .gitignoreJakub Kicinski
Commit 55d42a0c3f9c ("selftests: net: add a test for closing a netlink socket ith dump in progress") added a new test but did not add it to gitignore. Reviewed-by: Joe Damato <jdamato@fastly.com> Link: https://patch.msgid.link/20241108004731.2979878-1-kuba@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-11-09drm/rockchip: vop: Fix a dereferenced before check warningAndy Yan
The 'state' can't be NULL, we should check crtc_state. Fix warning: drivers/gpu/drm/rockchip/rockchip_drm_vop.c:1096 vop_plane_atomic_async_check() warn: variable dereferenced before check 'state' (see line 1077) Fixes: 5ddb0bd4ddc3 ("drm/atomic: Pass the full state to planes async atomic check and update") Signed-off-by: Andy Yan <andy.yan@rock-chips.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/20241021072818.61621-1-andyshrk@163.com
2024-11-09Merge tag 'i2c-host-fixes-6.12-rc7' of ↵Wolfram Sang
git://git.kernel.org/pub/scm/linux/kernel/git/andi.shyti/linux into i2c/for-current i2c-host fixes for v6.12-rc7 In designware an incorrect behavior has been fixes when concluding a transmission. Fixed return error value evaluation in the Mule multiplexer.
2024-11-09net: vertexcom: mse102x: Fix tx_bytes calculationStefan Wahren
The tx_bytes should consider the actual size of the Ethernet frames without the SPI encapsulation. But we still need to take care of Ethernet padding. Fixes: 2f207cbf0dd4 ("net: vertexcom: Add MSE102x SPI support") Signed-off-by: Stefan Wahren <wahrenst@gmx.net> Link: https://patch.msgid.link/20241108114343.6174-3-wahrenst@gmx.net Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-11-09Merge branch 'improve-neigh_flush_dev-performance'Jakub Kicinski
Gilad Naaman says: ==================== Improve neigh_flush_dev performance This patchsets improves the performance of neigh_flush_dev. Currently, the only way to implement it requires traversing all neighbours known to the kernel, across all network-namespaces. This means that some flows are slowed down as a function of neigh-scale, even if the specific link they're handling has little to no neighbours. In order to solve this, this patchset adds a netdev->neighbours list, as well as making the original linked-list doubly-, so that it is possible to unlink neighbours without traversing the hash-bucket to obtain the previous neighbour. The original use-case we encountered was mass-deletion of links (12K VLANs) while there are 50K ARPs and 50K NDPs in the system; though the slowdowns would also appear when the links are set down. ==================== Link: https://patch.msgid.link/20241107160444.2913124-1-gnaaman@drivenets.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-11-09neighbour: Create netdev->neighbour associationGilad Naaman
Create a mapping between a netdev and its neighoburs, allowing for much cheaper flushes. Signed-off-by: Gilad Naaman <gnaaman@drivenets.com> Reviewed-by: Eric Dumazet <edumazet@google.com> Reviewed-by: Kuniyuki Iwashima <kuniyu@amazon.com> Link: https://patch.msgid.link/20241107160444.2913124-7-gnaaman@drivenets.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-11-09neighbour: Remove bare neighbour::next pointerGilad Naaman
Remove the now-unused neighbour::next pointer, leaving struct neighbour solely with the hlist_node implementation. Signed-off-by: Gilad Naaman <gnaaman@drivenets.com> Reviewed-by: Kuniyuki Iwashima <kuniyu@amazon.com> Reviewed-by: Eric Dumazet <edumazet@google.com> Link: https://patch.msgid.link/20241107160444.2913124-6-gnaaman@drivenets.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-11-09neighbour: Convert iteration to use hlist+macroGilad Naaman
Remove all usage of the bare neighbour::next pointer, replacing them with neighbour::hash and its for_each macro. Signed-off-by: Gilad Naaman <gnaaman@drivenets.com> Reviewed-by: Kuniyuki Iwashima <kuniyu@amazon.com> Reviewed-by: Eric Dumazet <edumazet@google.com> Link: https://patch.msgid.link/20241107160444.2913124-5-gnaaman@drivenets.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-11-09neighbour: Convert seq_file functions to use hlistGilad Naaman
Convert seq_file-related neighbour functionality to use neighbour::hash and the related for_each macro. Signed-off-by: Gilad Naaman <gnaaman@drivenets.com> Reviewed-by: Kuniyuki Iwashima <kuniyu@amazon.com> Reviewed-by: Eric Dumazet <edumazet@google.com> Link: https://patch.msgid.link/20241107160444.2913124-4-gnaaman@drivenets.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-11-09neighbour: Define neigh_for_each_in_bucketGilad Naaman
Introduce neigh_for_each_in_bucket in neighbour.h, to help iterate over the neighbour table more succinctly. Signed-off-by: Gilad Naaman <gnaaman@drivenets.com> Reviewed-by: Kuniyuki Iwashima <kuniyu@amazon.com> Reviewed-by: Eric Dumazet <edumazet@google.com> Link: https://patch.msgid.link/20241107160444.2913124-3-gnaaman@drivenets.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-11-09neighbour: Add hlist_node to struct neighbourGilad Naaman
Add a doubly-linked node to neighbours, so that they can be deleted without iterating the entire bucket they're in. Signed-off-by: Gilad Naaman <gnaaman@drivenets.com> Reviewed-by: Kuniyuki Iwashima <kuniyu@amazon.com> Reviewed-by: Eric Dumazet <edumazet@google.com> Link: https://patch.msgid.link/20241107160444.2913124-2-gnaaman@drivenets.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
generated by cgit (git 2.34.1) at 2025-09-28 03:56:29 +0000