October 2024 - Linux-stable-mirror

[PATCH] kbuild: Fully disable -Wenum-{compare-conditional,enum-conversion}

by Nathan Chancellor

-Wenum-enum-conversion and -Wenum-compare-conditional were strengthened in clang-19 to warn in C mode, which caused the kernel to move them to W=1 in commit 75b5ab134bb5 ("kbuild: Move -Wenum-{compare-conditional,enum-conversion} into W=1") because there were numerous instances of each that would break builds with -Werror. Unfortunately, this is not a full solution, as more and more developers, subsystems, and distributors are building with W=1 as well, so they continue to see the numerous instances of these warnings. Since the move to W=1, there have not been many new instances that have appeared through various build reports and the ones that have appeared seem to be following similar existing patterns, suggesting that most instances of these warnings will not be real issues. The only alternatives for silencing these warnings are adding casts (which is generally seen as an ugly practice) or refactoring the enums to macro defines or a unified enum (which may be undesirable because of type safety in other parts of the code). Disable the warnings altogether so that W=1 users do not see them. Cc: stable(a)vger.kernel.org Fixes: 75b5ab134bb5 ("kbuild: Move -Wenum-{compare-conditional,enum-conversion} into W=1") Link: https://lore.kernel.org/ZwRA9SOcOjjLJcpi@google.com/ Signed-off-by: Nathan Chancellor <nathan(a)kernel.org> --- I am open to discussion around whether or not to disable this entirely but I think it needs to be out of W=1. --- scripts/Makefile.extrawarn | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/scripts/Makefile.extrawarn b/scripts/Makefile.extrawarn index 1d13cecc7cc7808610e635ddc03476cf92b3a8c1..3f124c80bee5133899047c07bc05e3173ee4c7f0 100644 --- a/scripts/Makefile.extrawarn +++ b/scripts/Makefile.extrawarn @@ -31,6 +31,8 @@ KBUILD_CFLAGS-$(CONFIG_CC_NO_ARRAY_BOUNDS) += -Wno-array-bounds ifdef CONFIG_CC_IS_CLANG # The kernel builds with '-std=gnu11' so use of GNU extensions is acceptable. KBUILD_CFLAGS += -Wno-gnu +KBUILD_CFLAGS += -Wno-enum-compare-conditional +KBUILD_CFLAGS += -Wno-enum-enum-conversion else # gcc inanely warns about local variables called 'main' @@ -129,8 +131,6 @@ endif KBUILD_CFLAGS += $(call cc-disable-warning, pointer-to-enum-cast) KBUILD_CFLAGS += -Wno-tautological-constant-out-of-range-compare KBUILD_CFLAGS += $(call cc-disable-warning, unaligned-access) -KBUILD_CFLAGS += -Wno-enum-compare-conditional -KBUILD_CFLAGS += -Wno-enum-enum-conversion endif endif --- base-commit: 8e929cb546ee42c9a61d24fae60605e9e3192354 change-id: 20241016-disable-two-clang-enum-warnings-e7994d44f948 Best regards, -- Nathan Chancellor <nathan(a)kernel.org>

1 year

2
2
0 0

[PATCH v2] arm64: dts: qcom: x1e80100: Add Broadcast_AND region in LLCC block

by Abel Vesa

Add missing Broadcast_AND region to the LLCC block for x1e80100, as the LLCC version on this platform is 4.1 and it provides the region. This also fixes the following error caused by the missing region: [ 3.797768] qcom-llcc 25000000.system-cache-controller: error -EINVAL: invalid resource (null) This error started showing up only after the new regmap region called Broadcast_AND that has been added to the llcc-qcom driver. Cc: stable(a)vger.kernel.org # 6.11: 055afc34fd21: soc: qcom: llcc: Add regmap for Broadcast_AND region Fixes: af16b00578a7 ("arm64: dts: qcom: Add base X1E80100 dtsi and the QCP dts") Signed-off-by: Abel Vesa <abel.vesa(a)linaro.org> --- Changes in v2: - fixed subject line to say x1e80100 instead of sm8450 - mentioned the reason why the new error is showing up and how it is related to the llcc-qcom driver - cc'ed stable with patch dependency for cherry-picking - Link to v1: https://lore.kernel.org/r/20240718-x1e80100-dts-llcc-add-broadcastand_regio… --- arch/arm64/boot/dts/qcom/x1e80100.dtsi | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/arch/arm64/boot/dts/qcom/x1e80100.dtsi b/arch/arm64/boot/dts/qcom/x1e80100.dtsi index 0e6802c1d2d8375987c614ec69c440e2f38d25c6..fbf1acf8b0d84a2d2c723785242a65f47e63340b 100644 --- a/arch/arm64/boot/dts/qcom/x1e80100.dtsi +++ b/arch/arm64/boot/dts/qcom/x1e80100.dtsi @@ -6093,7 +6093,8 @@ system-cache-controller@25000000 { <0 0x25a00000 0 0x200000>, <0 0x25c00000 0 0x200000>, <0 0x25e00000 0 0x200000>, - <0 0x26000000 0 0x200000>; + <0 0x26000000 0 0x200000>, + <0 0x26200000 0 0x200000>; reg-names = "llcc0_base", "llcc1_base", "llcc2_base", @@ -6102,7 +6103,8 @@ system-cache-controller@25000000 { "llcc5_base", "llcc6_base", "llcc7_base", - "llcc_broadcast_base"; + "llcc_broadcast_base", + "llcc_broadcast_and_base"; interrupts = <GIC_SPI 266 IRQ_TYPE_LEVEL_HIGH>; }; --- base-commit: d61a00525464bfc5fe92c6ad713350988e492b88 change-id: 20240718-x1e80100-dts-llcc-add-broadcastand_region-797413ee2a8f Best regards, -- Abel Vesa <abel.vesa(a)linaro.org>

1 year

2
1
0 0

[PATCH 0/2] Fix KASAN crash when using KASAN_VMALLOC

by Linus Walleij

This problem reported by Clement LE GOFFIC manifest when using CONFIG_KASAN_IN_VMALLOC and VMAP_STACK: https://lore.kernel.org/linux-arm-kernel/a1a1d062-f3a2-4d05-9836-3b098de9db… After some analysis it seems we are missing to sync the VMALLOC shadow memory in top level PGD to all CPUs. Add some code to perform this sync, and the bug appears to go away. As suggested by Ard, also perform a dummy read from the shadow memory of the new VMAP_STACK in the low level assembly. Signed-off-by: Linus Walleij <linus.walleij(a)linaro.org> --- Linus Walleij (2): ARM: ioremap: Flush PGDs for VMALLOC shadow ARM: entry: Do a dummy read from VMAP shadow arch/arm/kernel/entry-armv.S | 8 ++++++++ arch/arm/mm/ioremap.c | 7 +++++++ 2 files changed, 15 insertions(+) --- base-commit: 9852d85ec9d492ebef56dc5f229416c925758edc change-id: 20241015-arm-kasan-vmalloc-crash-fcbd51416457 Best regards, -- Linus Walleij <linus.walleij(a)linaro.org>

1 year

3
7
0 0

[PATCH] fs: don't try and remove empty rbtree node

by Christian Brauner

When copying a namespace we won't have added the new copy into the namespace rbtree until after the copy succeeded. Calling free_mnt_ns() will try to remove the copy from the rbtree which is invalid. Simply free the namespace skeleton directly. Fixes: 1901c92497bd ("fs: keep an index of current mount namespaces") Cc: stable(a)vger.kernel.org # v6.11+ Reported-by: Brad Spengler <spender(a)grsecurity.net> Tested-by: Brad Spengler <spender(a)grsecurity.net> Suggested-by: Brad Spengler <spender(a)grsecurity.net> Signed-off-by: Christian Brauner <brauner(a)kernel.org> --- In vfs.fixes unless I hear objections. --- fs/namespace.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/fs/namespace.c b/fs/namespace.c index 93c377816d75..d26f5e6d2ca3 100644 --- a/fs/namespace.c +++ b/fs/namespace.c @@ -3944,7 +3944,9 @@ struct mnt_namespace *copy_mnt_ns(unsigned long flags, struct mnt_namespace *ns, new = copy_tree(old, old->mnt.mnt_root, copy_flags); if (IS_ERR(new)) { namespace_unlock(); - free_mnt_ns(new_ns); + ns_free_inum(&new_ns->ns); + dec_mnt_namespaces(new_ns->ucounts); + mnt_ns_release(new_ns); return ERR_CAST(new); } if (user_ns != ns->user_ns) { -- 2.45.2

1 year

1
0
0 0

[PATCH v2] usb: using mutex lock and supporting O_NONBLOCK flag in iowarrior_read()

by Jeongjun Park

iowarrior_read() uses the iowarrior dev structure, but does not use any lock on the structure. This can cause various bugs including data-races, so it is more appropriate to use a mutex lock to safely protect the iowarrior dev structure. When using a mutex lock, you should split the branch to prevent blocking when the O_NONBLOCK flag is set. In addition, it is unnecessary to check for NULL on the iowarrior dev structure obtained by reading file->private_data. Therefore, it is better to remove the check. Cc: stable(a)vger.kernel.org Fixes: 946b960d13c1 ("USB: add driver for iowarrior devices.") Signed-off-by: Jeongjun Park <aha310510(a)gmail.com> --- v1 -> v2: Added cc tag and change log drivers/usb/misc/iowarrior.c | 46 ++++++++++++++++++++++++++++-------- 1 file changed, 36 insertions(+), 10 deletions(-) diff --git a/drivers/usb/misc/iowarrior.c b/drivers/usb/misc/iowarrior.c index 6d28467ce352..a513766b4985 100644 --- a/drivers/usb/misc/iowarrior.c +++ b/drivers/usb/misc/iowarrior.c @@ -277,28 +277,45 @@ static ssize_t iowarrior_read(struct file *file, char __user *buffer, struct iowarrior *dev; int read_idx; int offset; + int retval; dev = file->private_data; + if (file->f_flags & O_NONBLOCK) { + retval = mutex_trylock(&dev->mutex); + if (!retval) + return -EAGAIN; + } else { + retval = mutex_lock_interruptible(&dev->mutex); + if (retval) + return -ERESTARTSYS; + } + /* verify that the device wasn't unplugged */ - if (!dev || !dev->present) - return -ENODEV; + if (!dev->present) { + retval = -ENODEV; + goto exit; + } dev_dbg(&dev->interface->dev, "minor %d, count = %zd\n", dev->minor, count); /* read count must be packet size (+ time stamp) */ if ((count != dev->report_size) - && (count != (dev->report_size + 1))) - return -EINVAL; + && (count != (dev->report_size + 1))) { + retval = -EINVAL; + goto exit; + } /* repeat until no buffer overrun in callback handler occur */ do { atomic_set(&dev->overflow_flag, 0); if ((read_idx = read_index(dev)) == -1) { /* queue empty */ - if (file->f_flags & O_NONBLOCK) - return -EAGAIN; + if (file->f_flags & O_NONBLOCK) { + retval = -EAGAIN; + goto exit; + } else { //next line will return when there is either new data, or the device is unplugged int r = wait_event_interruptible(dev->read_wait, @@ -309,28 +326,37 @@ static ssize_t iowarrior_read(struct file *file, char __user *buffer, -1)); if (r) { //we were interrupted by a signal - return -ERESTART; + retval = -ERESTART; + goto exit; } if (!dev->present) { //The device was unplugged - return -ENODEV; + retval = -ENODEV; + goto exit; } if (read_idx == -1) { // Can this happen ??? - return 0; + retval = 0; + goto exit; } } } offset = read_idx * (dev->report_size + 1); if (copy_to_user(buffer, dev->read_queue + offset, count)) { - return -EFAULT; + retval = -EFAULT; + goto exit; } } while (atomic_read(&dev->overflow_flag)); read_idx = ++read_idx == MAX_INTERRUPT_BUFFER ? 0 : read_idx; atomic_set(&dev->read_idx, read_idx); + mutex_unlock(&dev->mutex); return count; + +exit: + mutex_unlock(&dev->mutex); + return retval; } /* --

1 year

2
2
0 0

Re: Bad commit backported on the v5.15.y branch ?

by Thorsten Leemhuis

On 11.10.24 10:48, Joel GUITTET wrote: > > I faced some issue related to scaling frequency on ZynqMP device > using v5.15.167 kernel. As an exemple setting the scaling frequency > below show it's not properly set: > > cat /sys/devices/system/cpu/cpufreq/policy0/ > scaling_available_frequencies 299999 399999 599999 1199999 > > echo 399999 > /sys/devices/system/cpu/cpufreq/policy0/ > scaling_setspeed > > cat /sys/devices/system/cpu/cpufreq/policy0/scaling_cur_freq 399999 > > cat /sys/devices/system/cpu/cpufreq/policy0/cpuinfo_cur_freq 299999 > ====> Should be 399999 > > After analysis of this issue with the help of Xilinx, it appears > that a commit was backported on the 5.15.y branch, but probably it > should not, or not as is. The commit is > 9117fc44fd3a9538261e530ba5a022dfc9519620 modifying drivers/clk/ > zynqmp/divider.c. FWIW, that is 1fe15be1fb6135 ("drivers: clk: zynqmp: update divider round rate logic") [v6.8-rc1]. > Is anybody reading this message able to answer why it was > backported ? Looks like because it fixes a bug. I CCed the original author and those that handled the patch, maybe they can help us out and tell us what's the best strategy forward here. > The information I have until now is that it is intended > recent kernel version. Dependencies for this modification is > currently under clarification with Xilinx (maybe another commit to > backport). > > By the way, reverting this commit fix the issue shown above. Does 6.12-rc work fine for you? Because if not, we should fix the problem there. Ciao, Thorsten

1 year

3
4
0 0

[PATCH 6/6] arm64: dts: qcom: x1e80100-qcp: fix nvme regulator boot glitch

by Johan Hovold

The NVMe regulator has been left enabled by the boot firmware. Mark it as such to avoid disabling the regulator temporarily during boot. Fixes: eb57cbe730d1 ("arm64: dts: qcom: x1e80100: Describe the PCIe 6a resources") Cc: stable(a)vger.kernel.org # 6.11 Cc: Abel Vesa <abel.vesa(a)linaro.org> Signed-off-by: Johan Hovold <johan+linaro(a)kernel.org> --- arch/arm64/boot/dts/qcom/x1e80100-qcp.dts | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm64/boot/dts/qcom/x1e80100-qcp.dts b/arch/arm64/boot/dts/qcom/x1e80100-qcp.dts index 1c3a6a7b3ed6..5ef030c60abe 100644 --- a/arch/arm64/boot/dts/qcom/x1e80100-qcp.dts +++ b/arch/arm64/boot/dts/qcom/x1e80100-qcp.dts @@ -253,6 +253,8 @@ vreg_nvme: regulator-nvme { pinctrl-names = "default"; pinctrl-0 = <&nvme_reg_en>; + + regulator-boot-on; }; }; -- 2.45.2

1 year

1
0
0 0

[PATCH 4/6] arm64: dts: qcom: x1e80100-yoga-slim7x: fix nvme regulator boot glitch

by Johan Hovold

The NVMe regulator has been left enabled by the boot firmware. Mark it as such to avoid disabling the regulator temporarily during boot. Fixes: 45247fe17db2 ("arm64: dts: qcom: x1e80100: add Lenovo Thinkpad Yoga slim 7x devicetree") Cc: stable(a)vger.kernel.org # 6.11 Cc: Srinivas Kandagatla <srinivas.kandagatla(a)linaro.org> Signed-off-by: Johan Hovold <johan+linaro(a)kernel.org> --- arch/arm64/boot/dts/qcom/x1e80100-lenovo-yoga-slim7x.dts | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm64/boot/dts/qcom/x1e80100-lenovo-yoga-slim7x.dts b/arch/arm64/boot/dts/qcom/x1e80100-lenovo-yoga-slim7x.dts index 3c13331a9ef4..0cdaff9c8cf0 100644 --- a/arch/arm64/boot/dts/qcom/x1e80100-lenovo-yoga-slim7x.dts +++ b/arch/arm64/boot/dts/qcom/x1e80100-lenovo-yoga-slim7x.dts @@ -205,6 +205,8 @@ vreg_nvme: regulator-nvme { pinctrl-0 = <&nvme_reg_en>; pinctrl-names = "default"; + + regulator-boot-on; }; }; -- 2.45.2

1 year

1
0
0 0

[PATCH 3/6] arm64: dts: qcom: x1e80100-vivobook-s15: fix nvme regulator boot glitch

by Johan Hovold

The NVMe regulator has been left enabled by the boot firmware. Mark it as such to avoid disabling the regulator temporarily during boot. Fixes: d0e2f8f62dff ("arm64: dts: qcom: Add device tree for ASUS Vivobook S 15") Cc: stable(a)vger.kernel.org # 6.11 Cc: Xilin Wu <wuxilin123(a)gmail.com> Signed-off-by: Johan Hovold <johan+linaro(a)kernel.org> --- arch/arm64/boot/dts/qcom/x1e80100-asus-vivobook-s15.dts | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm64/boot/dts/qcom/x1e80100-asus-vivobook-s15.dts b/arch/arm64/boot/dts/qcom/x1e80100-asus-vivobook-s15.dts index 20616bd4aa6c..fb4a48a1e2a8 100644 --- a/arch/arm64/boot/dts/qcom/x1e80100-asus-vivobook-s15.dts +++ b/arch/arm64/boot/dts/qcom/x1e80100-asus-vivobook-s15.dts @@ -134,6 +134,8 @@ vreg_nvme: regulator-nvme { pinctrl-0 = <&nvme_reg_en>; pinctrl-names = "default"; + + regulator-boot-on; }; }; -- 2.45.2

1 year

1
0
0 0

[PATCH 2/6] arm64: dts: qcom: x1e80100-crd: fix nvme regulator boot glitch

by Johan Hovold

The NVMe regulator has been left enabled by the boot firmware. Mark it as such to avoid disabling the regulator temporarily during boot. Fixes: eb57cbe730d1 ("arm64: dts: qcom: x1e80100: Describe the PCIe 6a resources") Cc: stable(a)vger.kernel.org # 6.11 Cc: Abel Vesa <abel.vesa(a)linaro.org> Signed-off-by: Johan Hovold <johan+linaro(a)kernel.org> --- arch/arm64/boot/dts/qcom/x1e80100-crd.dts | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm64/boot/dts/qcom/x1e80100-crd.dts b/arch/arm64/boot/dts/qcom/x1e80100-crd.dts index 10b28d870f08..5d2eec8590ce 100644 --- a/arch/arm64/boot/dts/qcom/x1e80100-crd.dts +++ b/arch/arm64/boot/dts/qcom/x1e80100-crd.dts @@ -300,6 +300,8 @@ vreg_nvme: regulator-nvme { pinctrl-names = "default"; pinctrl-0 = <&nvme_reg_en>; + + regulator-boot-on; }; vreg_wwan: regulator-wwan { -- 2.45.2

1 year

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror October 2024