- Linux-stable-mirror - lists.linaro.org

[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>

2 days, 15 hours

2
2
0 0

[REGRESSION][BISECTED] Commit 60e3318e3e900 in stable/linux-6.1.y breaks cifs client failover to another server in DFS namespace

by Andrew Paniakin

Commit 60e3318e3e900 ("cifs: use fs_context for automounts") was released in v6.1.54 and broke the failover when one of the servers inside DFS becomes unavailable. We reproduced the problem on the EC2 instances of different types. Reverting aforementioned commint on top of the latest stable verison v6.1.94 helps to resolve the problem. Earliest working version is v6.2-rc1. There were two big merges of CIFS fixes: [1] and [2]. We would like to ask for the help to investigate this problem and if some of those patches need to be backported. Also, is it safe to just revert problematic commit until proper fixes/backports will be available? We will help to do testing and confirm if fix works, but let me also list the steps we used to reproduce the problem if it will help to identify the problem: 1. Create Active Directory domain eg. 'corp.fsxtest.local' in AWS Directory Service with: - three AWS FSX file systems filesystem1..filesystem3 - three Windows servers; They have DFS installed as per https://learn.microsoft.com/en-us/windows-server/storage/dfs-namespaces/dfs…: - dfs-srv1: EC2AMAZ-2EGTM59 - dfs-srv2: EC2AMAZ-1N36PRD - dfs-srv3: EC2AMAZ-0PAUH2U 2. Create DFS namespace eg. 'dfs-namespace' in Windows server 2008 mode and three folders targets in it: - referral-a mapped to filesystem1.corp.local - referral-b mapped to filesystem2.corp.local - referral-c mapped to filesystem3.corp.local - local folders dfs-srv1..dfs-srv3 in C:\DFSRoots\dfs-namespace of every Windows server. This helps to quickly define underlying server when DFS is mounted. 3. Enabled cifs debug logs: ``` echo 'module cifs +p' > /sys/kernel/debug/dynamic_debug/control echo 'file fs/cifs/* +p' > /sys/kernel/debug/dynamic_debug/control echo 7 > /proc/fs/cifs/cifsFYI ``` 4. Mount DFS namespace on Amazon Linux 2023 instance running any vanilla kernel v6.1.54+: ``` dmesg -c &>/dev/null cd /mnt mount -t cifs -o cred=/mnt/creds,echo_interval=5 \ //corp.fsxtest.local/dfs-namespace \ ./dfs-namespace ``` 5. List DFS root, it's also required to avoid recursive mounts that happen during regular 'ls' run: ``` sh -c 'ls dfs-namespace' dfs-srv2 referral-a referral-b ``` The DFS server is EC2AMAZ-1N36PRD, it's also listed in mount: ``` [root@ip-172-31-2-82 mnt]# mount | grep dfs //corp.fsxtest.local/dfs-namespace on /mnt/dfs-namespace type cifs (rw,relatime,vers=3.1.1,cache=strict,username=Admin,domain=corp.fsxtest.local,uid=0,noforceuid,gid=0,noforcegid,addr=172.31.11.26,file_mode=0755,dir_mode=0755,soft,nounix,mapposix,rsize=4194304,wsize=4194304,bsize=1048576,echo_interval=5,actimeo=1,closetimeo=1) //EC2AMAZ-1N36PRD.corp.fsxtest.local/dfs-namespace/referral-a on /mnt/dfs-namespace/referral-a type cifs (rw,relatime,vers=3.1.1,cache=strict,username=Admin,domain=corp.fsxtest.local,uid=0,noforceuid,gid=0,noforcegid,addr=172.31.12.80,file_mode=0755,dir_mode=0755,soft,nounix,mapposix,rsize=4194304,wsize=4194304,bsize=1048576,echo_interval=5,actimeo=1,closetimeo=1) ``` List files in first folder: ``` sh -c 'ls dfs-namespace/referral-a' filea.txt.txt ``` 6. Shutdown DFS server-2. List DFS root again, server changed from dfs-srv2 to dfs-srv1 EC2AMAZ-2EGTM59: ``` sh -c 'ls dfs-namespace' dfs-srv1 referral-a referral-b ``` 7. Try to list files in another folder, this causes ls to fail with error: ``` sh -c 'ls dfs-namespace/referral-b' ls: cannot access 'dfs-namespace/referral-b': No route to host``` Sometimes it's also 'Operation now in progress' error. mount shows the same output: ``` //corp.fsxtest.local/dfs-namespace on /mnt/dfs-namespace type cifs (rw,relatime,vers=3.1.1,cache=strict,username=Admin,domain=corp.fsxtest.local,uid=0,noforceuid,gid=0,noforcegid,addr=172.31.11.26,file_mode=0755,dir_mode=0755,soft,nounix,mapposix,rsize=4194304,wsize=4194304,bsize=1048576,echo_interval=5,actimeo=1,closetimeo=1) //EC2AMAZ-1N36PRD.corp.fsxtest.local/dfs-namespace/referral-a on /mnt/dfs-namespace/referral-a type cifs (rw,relatime,vers=3.1.1,cache=strict,username=Admin,domain=corp.fsxtest.local,uid=0,noforceuid,gid=0,noforcegid,addr=172.31.12.80,file_mode=0755,dir_mode=0755,soft,nounix,mapposix,rsize=4194304,wsize=4194304,bsize=1048576,echo_interval=5,actimeo=1,closetimeo=1) ``` I also attached kernel debug logs from this test. [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… [2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… Reported-by: Andrei Paniakin <apanyaki(a)amazon.com> Bisected-by: Simba Bonga <simbarb(a)amazon.com> --- #regzbot introduced: v6.1.54..v6.2-rc1

2 days, 15 hours

3
9
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>

2 days, 16 hours

2
1
0 0

Re: [RFC PATCH] epoll: Add synchronous wakeup support for ep_poll_callback

by Brian Geffon

On Wed, Oct 16, 2024 at 03:10:34PM +0200, Christian Brauner wrote: > On Fri, 26 Apr 2024 16:05:48 +0800, Xuewen Yan wrote: > > Now, the epoll only use wake_up() interface to wake up task. > > However, sometimes, there are epoll users which want to use > > the synchronous wakeup flag to hint the scheduler, such as > > Android binder driver. > > So add a wake_up_sync() define, and use the wake_up_sync() > > when the sync is true in ep_poll_callback(). > > > > [...] > > Applied to the vfs.misc branch of the vfs/vfs.git tree. > Patches in the vfs.misc branch should appear in linux-next soon. > > Please report any outstanding bugs that were missed during review in a > new review to the original patch series allowing us to drop it. > > It's encouraged to provide Acked-bys and Reviewed-bys even though the > patch has now been applied. If possible patch trailers will be updated. > > Note that commit hashes shown below are subject to change due to rebase, > trailer updates or similar. If in doubt, please check the listed branch. > > tree: https://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs.git > branch: vfs.misc This is a bug that's been present for all of time, so I think we should: Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable(a)vger.kernel.org I sent a patch which adds a benchmark for nonblocking pipes using epoll: https://lore.kernel.org/lkml/20241016190009.866615-1-bgeffon@google.com/ Using this new benchmark I get the following results without this fix and with this fix: $ tools/perf/perf bench sched pipe -n # Running 'sched/pipe' benchmark: # Executed 1000000 pipe operations between two processes Total time: 12.194 [sec] 12.194376 usecs/op 82005 ops/sec $ tools/perf/perf bench sched pipe -n # Running 'sched/pipe' benchmark: # Executed 1000000 pipe operations between two processes Total time: 9.229 [sec] 9.229738 usecs/op 108345 ops/sec > > [1/1] epoll: Add synchronous wakeup support for ep_poll_callback > https://git.kernel.org/vfs/vfs/c/2ce0e17660a7

2 days, 17 hours

1
0
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>

2 days, 17 hours

3
7
0 0

[PATCH] riscv/entry: get correct syscall number from syscall_get_nr()

by Celeste Liu via B4 Relay

From: Celeste Liu <CoelacanthusHex(a)gmail.com> The return value of syscall_enter_from_user_mode() is always -1 when the syscall was filtered. We can't know whether syscall_nr is -1 when we get -1 from syscall_enter_from_user_mode(). And the old syscall variable is unusable because syscall_enter_from_user_mode() may change a7 register. So get correct syscall number from syscall_get_nr(). So syscall number part of return value of syscall_enter_from_user_mode() is completely useless. We can remove it from API and require caller to get syscall number from syscall_get_nr(). But this change affect more architectures and will block more time. So we split it into another patchset to avoid block this fix. (Other architectures can works without this change but riscv need it, see Link: tag below) Fixes: 61119394631f ("riscv: entry: always initialize regs->a0 to -ENOSYS") Reported-by: Andrea Bolognani <abologna(a)redhat.com> Closes: https://github.com/strace/strace/issues/315 Link: https://lore.kernel.org/all/59505464-c84a-403d-972f-d4b2055eeaac@gmail.com/ Signed-off-by: Celeste Liu <CoelacanthusHex(a)gmail.com> --- arch/riscv/kernel/traps.c | 13 ++++++++++--- 1 file changed, 10 insertions(+), 3 deletions(-) diff --git a/arch/riscv/kernel/traps.c b/arch/riscv/kernel/traps.c index 51ebfd23e0076447518081d137102a9a11ff2e45..3125fab8ee4af468ace9f692dd34e1797555cce3 100644 --- a/arch/riscv/kernel/traps.c +++ b/arch/riscv/kernel/traps.c @@ -316,18 +316,25 @@ void do_trap_ecall_u(struct pt_regs *regs) { if (user_mode(regs)) { long syscall = regs->a7; + long res; regs->epc += 4; regs->orig_a0 = regs->a0; - regs->a0 = -ENOSYS; riscv_v_vstate_discard(regs); - syscall = syscall_enter_from_user_mode(regs, syscall); + res = syscall_enter_from_user_mode(regs, syscall); + /* + * Call syscall_get_nr() again because syscall_enter_from_user_mode() + * may change a7 register. + */ + syscall = syscall_get_nr(current, regs); add_random_kstack_offset(); - if (syscall >= 0 && syscall < NR_syscalls) + if (syscall < 0 || syscall >= NR_syscalls) + regs->a0 = -ENOSYS; + else if (res != -1) syscall_handler(regs, syscall); /* --- base-commit: 2f87d0916ce0d2925cedbc9e8f5d6291ba2ac7b2 change-id: 20241016-fix-riscv-syscall-nr-917b566f97f3 Best regards, -- Celeste Liu <CoelacanthusHex(a)gmail.com>

2 days, 18 hours

2
1
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

2 days, 18 hours

1
0
0 0

[PATCH] iio: light: veml6030: fix microlux value calculation

by Javier Carrasco

The raw value conversion to obtain a measurement in lux as INT_PLUS_MICRO does not calculate the decimal part properly to display it as micro (in this case microlux). It only calculates the module to obtain the decimal part from a resolution that is 10000 times the provided in the datasheet (0.5376 lux/cnt for the veml6030). The resulting value must still be multiplied by 100 to make it micro. This bug was introduced with the original implementation of the driver. Cc: stable(a)vger.kernel.org Fixes: 7b779f573c48 ("iio: light: add driver for veml6030 ambient light sensor") Signed-off-by: Javier Carrasco <javier.carrasco.cruz(a)gmail.com> --- I found this almost by chance while testing new supported devices. The decimal part was always suspiciously small, and when I compared samples to the expected value according to the datasheet, it became clear what was going on. Example with a veml7700 (same resolution as the veml6030): Resolution for gain = 1/8, IT = 100 ms: 0.5736 lux/cnt. cat in_illuminance_raw in_illuminance_input 40 21.005040 -> wrong! 40 * 0.5736 is 21.504. Tested with a veml6035 and a veml7700, the same will happen with the original veml6030, as the operation is identical for all devices. --- drivers/iio/light/veml6030.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/iio/light/veml6030.c b/drivers/iio/light/veml6030.c index d6f3b104b0e6..a0bf03e37df7 100644 --- a/drivers/iio/light/veml6030.c +++ b/drivers/iio/light/veml6030.c @@ -691,7 +691,7 @@ static int veml6030_read_raw(struct iio_dev *indio_dev, } if (mask == IIO_CHAN_INFO_PROCESSED) { *val = (reg * data->cur_resolution) / 10000; - *val2 = (reg * data->cur_resolution) % 10000; + *val2 = (reg * data->cur_resolution) % 10000 * 100; return IIO_VAL_INT_PLUS_MICRO; } *val = reg; --- base-commit: 15e7d45e786a62a211dd0098fee7c57f84f8c681 change-id: 20241016-veml6030-fix-processed-micro-616d00d555dc Best regards, -- Javier Carrasco <javier.carrasco.cruz(a)gmail.com>

2 days, 19 hours

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; } /* --

2 days, 21 hours

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

2 days, 21 hours

3
4
0 0

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror