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

[PATCH] LoongArch: Use correct accessor to read FWPC/MWPC

by Huacai Chen

CSR.FWPC and CSR.MWPC are 32bit registers, so use csr_read32() rather than csr_read64() to read the values of FWPC/MWPC. Cc: stable(a)vger.kernel.org Fixes: edffa33c7bb5a73 ("LoongArch: Add hardware breakpoints/watchpoints support") Signed-off-by: Huacai Chen <chenhuacai(a)loongson.cn> --- arch/loongarch/include/asm/hw_breakpoint.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/loongarch/include/asm/hw_breakpoint.h b/arch/loongarch/include/asm/hw_breakpoint.h index 13b2462f3d8c..5faa97a87a9e 100644 --- a/arch/loongarch/include/asm/hw_breakpoint.h +++ b/arch/loongarch/include/asm/hw_breakpoint.h @@ -134,13 +134,13 @@ static inline void hw_breakpoint_thread_switch(struct task_struct *next) /* Determine number of BRP registers available. */ static inline int get_num_brps(void) { - return csr_read64(LOONGARCH_CSR_FWPC) & CSR_FWPC_NUM; + return csr_read32(LOONGARCH_CSR_FWPC) & CSR_FWPC_NUM; } /* Determine number of WRP registers available. */ static inline int get_num_wrps(void) { - return csr_read64(LOONGARCH_CSR_MWPC) & CSR_MWPC_NUM; + return csr_read32(LOONGARCH_CSR_MWPC) & CSR_MWPC_NUM; } #endif /* __KERNEL__ */ -- 2.47.3

2 weeks

1
0
0 0

[PATCHv2 1/2] kernel/kexec: Change the prototype of kimage_map_segment()

by Pingfan Liu

The kexec segment index will be required to extract the corresponding information for that segment in kimage_map_segment(). Additionally, kexec_segment already holds the kexec relocation destination address and size. Therefore, the prototype of kimage_map_segment() can be changed. Fixes: 07d24902977e ("kexec: enable CMA based contiguous allocation") Signed-off-by: Pingfan Liu <piliu(a)redhat.com> Cc: Andrew Morton <akpm(a)linux-foundation.org> Cc: Baoquan He <bhe(a)redhat.com> Cc: Mimi Zohar <zohar(a)linux.ibm.com> Cc: Roberto Sassu <roberto.sassu(a)huawei.com> Cc: Alexander Graf <graf(a)amazon.com> Cc: Steven Chen <chenste(a)linux.microsoft.com> Cc: <stable(a)vger.kernel.org> To: kexec(a)lists.infradead.org To: linux-integrity(a)vger.kernel.org --- include/linux/kexec.h | 4 ++-- kernel/kexec_core.c | 9 ++++++--- security/integrity/ima/ima_kexec.c | 4 +--- 3 files changed, 9 insertions(+), 8 deletions(-) diff --git a/include/linux/kexec.h b/include/linux/kexec.h index ff7e231b0485..8a22bc9b8c6c 100644 --- a/include/linux/kexec.h +++ b/include/linux/kexec.h @@ -530,7 +530,7 @@ extern bool kexec_file_dbg_print; #define kexec_dprintk(fmt, arg...) \ do { if (kexec_file_dbg_print) pr_info(fmt, ##arg); } while (0) -extern void *kimage_map_segment(struct kimage *image, unsigned long addr, unsigned long size); +extern void *kimage_map_segment(struct kimage *image, int idx); extern void kimage_unmap_segment(void *buffer); #else /* !CONFIG_KEXEC_CORE */ struct pt_regs; @@ -540,7 +540,7 @@ static inline void __crash_kexec(struct pt_regs *regs) { } static inline void crash_kexec(struct pt_regs *regs) { } static inline int kexec_should_crash(struct task_struct *p) { return 0; } static inline int kexec_crash_loaded(void) { return 0; } -static inline void *kimage_map_segment(struct kimage *image, unsigned long addr, unsigned long size) +static inline void *kimage_map_segment(struct kimage *image, int idx) { return NULL; } static inline void kimage_unmap_segment(void *buffer) { } #define kexec_in_progress false diff --git a/kernel/kexec_core.c b/kernel/kexec_core.c index fa00b239c5d9..9a1966207041 100644 --- a/kernel/kexec_core.c +++ b/kernel/kexec_core.c @@ -960,17 +960,20 @@ int kimage_load_segment(struct kimage *image, int idx) return result; } -void *kimage_map_segment(struct kimage *image, - unsigned long addr, unsigned long size) +void *kimage_map_segment(struct kimage *image, int idx) { + unsigned long addr, size, eaddr; unsigned long src_page_addr, dest_page_addr = 0; - unsigned long eaddr = addr + size; kimage_entry_t *ptr, entry; struct page **src_pages; unsigned int npages; void *vaddr = NULL; int i; + addr = image->segment[idx].mem; + size = image->segment[idx].memsz; + eaddr = addr + size; + /* * Collect the source pages and map them in a contiguous VA range. */ diff --git a/security/integrity/ima/ima_kexec.c b/security/integrity/ima/ima_kexec.c index 7362f68f2d8b..5beb69edd12f 100644 --- a/security/integrity/ima/ima_kexec.c +++ b/security/integrity/ima/ima_kexec.c @@ -250,9 +250,7 @@ void ima_kexec_post_load(struct kimage *image) if (!image->ima_buffer_addr) return; - ima_kexec_buffer = kimage_map_segment(image, - image->ima_buffer_addr, - image->ima_buffer_size); + ima_kexec_buffer = kimage_map_segment(image, image->ima_segment_index); if (!ima_kexec_buffer) { pr_err("Could not map measurements buffer.\n"); return; -- 2.49.0

2 weeks

2
9
0 0

[PATCH] fsi: Fix error handling in fsi_slave_init

by Ma Ke

fsi_slave_init() calls device_initialize() for slave->dev unconditionally. However, in the error paths, put_device() is not called, leading to an imbalance in the device reference count. Although kfree(slave) eventually frees the memory, it does not properly release the device initialized by device_initialize(). For proper pairing of device_initialize()/put_device(), add put_device() calls in both error paths. Found by code review. Cc: stable(a)vger.kernel.org Fixes: d1dcd6782576 ("fsi: Add cfam char devices") Signed-off-by: Ma Ke <make24(a)iscas.ac.cn> --- drivers/fsi/fsi-core.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/drivers/fsi/fsi-core.c b/drivers/fsi/fsi-core.c index c6c115993ebc..0d45e4442ca9 100644 --- a/drivers/fsi/fsi-core.c +++ b/drivers/fsi/fsi-core.c @@ -1075,7 +1075,7 @@ static int fsi_slave_init(struct fsi_master *master, int link, uint8_t id) rc = __fsi_get_new_minor(slave, fsi_dev_cfam, &slave->dev.devt, &slave->cdev_idx); if (rc) - goto err_free; + goto err_put_device; trace_fsi_slave_init(slave); @@ -1112,6 +1112,9 @@ static int fsi_slave_init(struct fsi_master *master, int link, uint8_t id) err_free_ida: fsi_free_minor(slave->dev.devt); +err_put_device: + put_device(&slave->dev); + return rc; err_free: of_node_put(slave->dev.of_node); kfree(slave); -- 2.17.1

2 weeks

2
1
0 0

[PATCH] bpf: hashtab: fix 32-bit overflow in memory usage calculation

by Alexei Safin

The intermediate product value_size * num_possible_cpus() is evaluated in 32-bit arithmetic and only then promoted to 64 bits. On systems with large value_size and many possible CPUs this can overflow and lead to an underestimated memory usage. Cast value_size to u64 before multiplying. Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: 304849a27b34 ("bpf: hashtab memory usage") Cc: stable(a)vger.kernel.org Signed-off-by: Alexei Safin <a.safin(a)rosa.ru> --- kernel/bpf/hashtab.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/kernel/bpf/hashtab.c b/kernel/bpf/hashtab.c index 570e2f723144..7ad6b5137ba1 100644 --- a/kernel/bpf/hashtab.c +++ b/kernel/bpf/hashtab.c @@ -2269,7 +2269,7 @@ static u64 htab_map_mem_usage(const struct bpf_map *map) usage += htab->elem_size * num_entries; if (percpu) - usage += value_size * num_possible_cpus() * num_entries; + usage += (u64)value_size * num_possible_cpus() * num_entries; else if (!lru) usage += sizeof(struct htab_elem *) * num_possible_cpus(); } else { @@ -2281,7 +2281,7 @@ static u64 htab_map_mem_usage(const struct bpf_map *map) usage += (htab->elem_size + LLIST_NODE_SZ) * num_entries; if (percpu) { usage += (LLIST_NODE_SZ + sizeof(void *)) * num_entries; - usage += value_size * num_possible_cpus() * num_entries; + usage += (u64)value_size * num_possible_cpus() * num_entries; } } return usage; -- 2.50.1 (Apple Git-155)

2 weeks

3
3
0 0

[linus:master] [cpuidle] db86f55bf8: lmbench3.PIPE.latency.us 11.5% improvement

by kernel test robot

Hello, kernel test robot noticed a 11.5% improvement of lmbench3.PIPE.latency.us on: commit: db86f55bf81a3a297be05ee8775ae9a8c6e3a599 ("cpuidle: governors: menu: Select polling state in some more cases") https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git master testcase: lmbench3 config: x86_64-rhel-9.4 compiler: gcc-14 test machine: 224 threads 2 sockets Intel(R) Xeon(R) Platinum 8480CTDX (Sapphire Rapids) with 512G memory parameters: test_memory_size: 50% nr_threads: 20% mode: development test: PIPE cpufreq_governor: performance In addition to that, the commit also has significant impact on the following tests: +------------------+---------------------------------------------------------------------------------------------+ | testcase: change | will-it-scale: will-it-scale.per_thread_ops 13.4% improvement | | test machine | 224 threads 2 sockets Intel(R) Xeon(R) Platinum 8480CTDX (Sapphire Rapids) with 512G memory | | test parameters | cpufreq_governor=performance | | | test=context_switch1 | +------------------+---------------------------------------------------------------------------------------------+ Details are as below: --------------------------------------------------------------------------------------------------> The kernel config and materials to reproduce are available at: https://download.01.org/0day-ci/archive/20251107/202511071439.d081322d-lkp@… ========================================================================================= compiler/cpufreq_governor/kconfig/mode/nr_threads/rootfs/tbox_group/test/test_memory_size/testcase: gcc-14/performance/x86_64-rhel-9.4/development/20%/debian-12-x86_64-20240206.cgz/lkp-spr-2sp4/PIPE/50%/lmbench3 commit: v6.18-rc3 db86f55bf8 ("cpuidle: governors: menu: Select polling state in some more cases") v6.18-rc3 db86f55bf81a3a297be05ee8775 ---------------- --------------------------- %stddev %change %stddev \ | \ 2.984e+08 ± 3% +13.0% 3.373e+08 ± 2% cpuidle..usage 3870548 ± 3% +8.9% 4215418 ± 3% vmstat.system.cs 5.11 -11.5% 4.52 lmbench3.PIPE.latency.us 2.949e+08 ± 3% +13.0% 3.334e+08 ± 2% lmbench3.time.voluntary_context_switches 1474808 ± 2% +13.7% 1676175 ± 2% sched_debug.cpu.nr_switches.avg 908098 ± 4% +11.5% 1012241 ± 5% sched_debug.cpu.nr_switches.stddev 35.76 ± 6% +70.7% 61.02 ± 36% perf-sched.wait_and_delay.avg.ms.schedule_hrtimeout_range_clock.poll_schedule_timeout.constprop.0.do_poll 438.60 ± 6% -42.6% 251.80 ± 28% perf-sched.wait_and_delay.count.schedule_hrtimeout_range_clock.poll_schedule_timeout.constprop.0.do_poll 35.75 ± 6% +70.7% 61.01 ± 36% perf-sched.wait_time.avg.ms.schedule_hrtimeout_range_clock.poll_schedule_timeout.constprop.0.do_poll 6.834e+09 ± 2% +8.8% 7.438e+09 ± 2% perf-stat.i.branch-instructions 4003246 ± 3% +9.0% 4365130 ± 4% perf-stat.i.context-switches 14211 ± 7% +30.7% 18567 ± 6% perf-stat.i.cycles-between-cache-misses 3.305e+10 +7.8% 3.563e+10 ± 2% perf-stat.i.instructions 17.81 ± 3% +9.1% 19.42 ± 4% perf-stat.i.metric.K/sec 6.738e+09 ± 2% +8.8% 7.328e+09 ± 2% perf-stat.ps.branch-instructions 3917194 ± 3% +9.0% 4267905 ± 4% perf-stat.ps.context-switches 3.257e+10 +7.8% 3.51e+10 ± 2% perf-stat.ps.instructions 4.907e+12 ± 5% +11.7% 5.481e+12 ± 3% perf-stat.total.instructions *************************************************************************************************** lkp-spr-2sp4: 224 threads 2 sockets Intel(R) Xeon(R) Platinum 8480CTDX (Sapphire Rapids) with 512G memory ========================================================================================= compiler/cpufreq_governor/kconfig/rootfs/tbox_group/test/testcase: gcc-14/performance/x86_64-rhel-9.4/debian-13-x86_64-20250902.cgz/lkp-spr-2sp4/context_switch1/will-it-scale commit: v6.18-rc3 db86f55bf8 ("cpuidle: governors: menu: Select polling state in some more cases") v6.18-rc3 db86f55bf81a3a297be05ee8775 ---------------- --------------------------- %stddev %change %stddev \ | \ 8360618 ± 14% +37.6% 11502592 ± 9% meminfo.DirectMap2M 0.52 ± 4% +0.2 0.68 ± 2% mpstat.cpu.all.irq% 0.07 ± 2% +0.0 0.08 ± 2% mpstat.cpu.all.soft% 24410019 +11.1% 27123411 sched_debug.cpu.nr_switches.avg 56464105 ± 3% +17.9% 66574674 ± 5% sched_debug.cpu.nr_switches.max 473411 +2.6% 485915 proc-vmstat.nr_active_anon 1205948 +1.0% 1218407 proc-vmstat.nr_file_pages 292446 +4.3% 304940 proc-vmstat.nr_shmem 473411 +2.6% 485915 proc-vmstat.nr_zone_active_anon 4.03 ± 3% -2.5 1.49 ± 21% turbostat.C1% 4.83 ± 9% -1.0 3.86 ± 13% turbostat.C1E% 1.087e+08 ± 3% +59.1% 1.729e+08 ± 3% turbostat.IRQ 0.03 ± 13% +2.0 2.03 turbostat.POLL% 4.745e+10 +8.5% 5.147e+10 perf-stat.i.branch-instructions 0.94 -0.0 0.90 ± 3% perf-stat.i.branch-miss-rate% 2.567e+08 +9.1% 2.8e+08 perf-stat.i.branch-misses 48551481 +8.1% 52493759 perf-stat.i.context-switches 2.76 -4.8% 2.63 ± 2% perf-stat.i.cpi 593.92 +5.6% 627.34 perf-stat.i.cpu-migrations 2.367e+11 +8.2% 2.561e+11 perf-stat.i.instructions 0.62 +9.8% 0.68 perf-stat.i.ipc 216.75 +8.1% 234.36 perf-stat.i.metric.K/sec 1.85 -7.0% 1.73 perf-stat.overall.cpi 0.54 +7.5% 0.58 perf-stat.overall.ipc 204618 +2.0% 208750 perf-stat.overall.path-length 4.674e+10 +8.4% 5.066e+10 perf-stat.ps.branch-instructions 2.532e+08 +9.0% 2.76e+08 perf-stat.ps.branch-misses 47800355 +8.1% 51652366 perf-stat.ps.context-switches 591.27 +5.5% 623.50 perf-stat.ps.cpu-migrations 2.332e+11 +8.1% 2.521e+11 perf-stat.ps.instructions 7.417e+13 +8.1% 8.019e+13 perf-stat.total.instructions 534510 ± 9% +24.8% 666973 ± 8% will-it-scale.1.linear 471854 ± 2% +26.9% 598959 ± 13% will-it-scale.1.processes 534510 ± 9% +24.8% 666973 ± 8% will-it-scale.1.threads 59865194 ± 9% +24.8% 74700994 ± 8% will-it-scale.112.linear 52446572 ± 3% +17.2% 61467049 will-it-scale.112.processes 52.12 ± 2% -11.2% 46.28 will-it-scale.112.processes_idle 89797792 ± 9% +24.8% 1.121e+08 ± 8% will-it-scale.168.linear 90159107 +5.3% 94951409 will-it-scale.168.processes 23.53 -8.4% 21.56 will-it-scale.168.processes_idle 1.197e+08 ± 9% +24.8% 1.494e+08 ± 8% will-it-scale.224.linear 29932597 ± 9% +24.8% 37350497 ± 8% will-it-scale.56.linear 24228097 ± 2% +22.6% 29712218 ± 2% will-it-scale.56.processes 80.80 -3.6% 77.89 will-it-scale.56.processes_idle 495994 +13.5% 562996 ± 2% will-it-scale.per_process_ops 211008 ± 5% +13.4% 239359 ± 4% will-it-scale.per_thread_ops 5748 +1.7% 5848 will-it-scale.time.percent_of_cpu_this_job_got 16823 +1.5% 17082 will-it-scale.time.system_time 1410 +4.2% 1469 will-it-scale.time.user_time 3.625e+08 +6.0% 3.842e+08 will-it-scale.workload 6.75 ± 9% -3.4 3.33 ± 4% perf-profile.calltrace.cycles-pp.intel_idle.cpuidle_enter_state.cpuidle_enter.cpuidle_idle_call.do_idle 8.01 ± 8% -1.7 6.26 ± 6% perf-profile.calltrace.cycles-pp.cpuidle_enter.cpuidle_idle_call.do_idle.cpu_startup_entry.start_secondary 7.89 ± 8% -1.7 6.14 ± 6% perf-profile.calltrace.cycles-pp.cpuidle_enter_state.cpuidle_enter.cpuidle_idle_call.do_idle.cpu_startup_entry 10.30 ± 6% -1.7 8.60 ± 4% perf-profile.calltrace.cycles-pp.cpuidle_idle_call.do_idle.cpu_startup_entry.start_secondary.common_startup_64 4.36 ± 2% -0.4 3.99 ± 5% perf-profile.calltrace.cycles-pp.ksys_write.do_syscall_64.entry_SYSCALL_64_after_hwframe 3.59 ± 2% -0.4 3.23 ± 5% perf-profile.calltrace.cycles-pp.anon_pipe_write.vfs_write.ksys_write.do_syscall_64.entry_SYSCALL_64_after_hwframe 3.91 ± 2% -0.4 3.55 ± 5% perf-profile.calltrace.cycles-pp.vfs_write.ksys_write.do_syscall_64.entry_SYSCALL_64_after_hwframe 2.75 ± 2% -0.4 2.39 ± 6% perf-profile.calltrace.cycles-pp.__wake_up_sync_key.anon_pipe_write.vfs_write.ksys_write.do_syscall_64 2.50 ± 2% -0.4 2.14 ± 6% perf-profile.calltrace.cycles-pp.autoremove_wake_function.__wake_up_common.__wake_up_sync_key.anon_pipe_write.vfs_write 2.44 ± 2% -0.4 2.09 ± 6% perf-profile.calltrace.cycles-pp.try_to_wake_up.autoremove_wake_function.__wake_up_common.__wake_up_sync_key.anon_pipe_write 2.56 ± 2% -0.4 2.21 ± 6% perf-profile.calltrace.cycles-pp.__wake_up_common.__wake_up_sync_key.anon_pipe_write.vfs_write.ksys_write 1.73 ± 2% -0.3 1.39 ± 8% perf-profile.calltrace.cycles-pp.ttwu_queue_wakelist.try_to_wake_up.autoremove_wake_function.__wake_up_common.__wake_up_sync_key 1.48 ± 2% -0.3 1.14 ± 10% perf-profile.calltrace.cycles-pp.__smp_call_single_queue.ttwu_queue_wakelist.try_to_wake_up.autoremove_wake_function.__wake_up_common 1.35 ± 2% -0.3 1.02 ± 11% perf-profile.calltrace.cycles-pp.call_function_single_prep_ipi.__smp_call_single_queue.ttwu_queue_wakelist.try_to_wake_up.autoremove_wake_function 61.64 +1.2 62.81 perf-profile.calltrace.cycles-pp.__schedule.schedule.anon_pipe_read.vfs_read.ksys_read 62.24 +1.2 63.45 perf-profile.calltrace.cycles-pp.schedule.anon_pipe_read.vfs_read.ksys_read.do_syscall_64 0.00 +1.7 1.72 ± 23% perf-profile.calltrace.cycles-pp.poll_idle.cpuidle_enter_state.cpuidle_enter.cpuidle_idle_call.do_idle 6.82 ± 9% -3.5 3.36 ± 4% perf-profile.children.cycles-pp.intel_idle 8.10 ± 8% -1.8 6.34 ± 6% perf-profile.children.cycles-pp.cpuidle_enter 8.04 ± 8% -1.8 6.28 ± 6% perf-profile.children.cycles-pp.cpuidle_enter_state 10.45 ± 6% -1.7 8.72 ± 4% perf-profile.children.cycles-pp.cpuidle_idle_call 4.41 ± 2% -0.4 4.04 ± 5% perf-profile.children.cycles-pp.ksys_write 2.76 ± 2% -0.4 2.40 ± 5% perf-profile.children.cycles-pp.__wake_up_sync_key 3.63 ± 2% -0.4 3.27 ± 5% perf-profile.children.cycles-pp.anon_pipe_write 2.51 ± 2% -0.4 2.15 ± 6% perf-profile.children.cycles-pp.autoremove_wake_function 2.47 ± 2% -0.4 2.11 ± 6% perf-profile.children.cycles-pp.try_to_wake_up 3.94 ± 2% -0.4 3.58 ± 5% perf-profile.children.cycles-pp.vfs_write 2.57 ± 2% -0.4 2.22 ± 6% perf-profile.children.cycles-pp.__wake_up_common 1.74 ± 2% -0.3 1.40 ± 8% perf-profile.children.cycles-pp.ttwu_queue_wakelist 1.49 ± 2% -0.3 1.15 ± 10% perf-profile.children.cycles-pp.__smp_call_single_queue 1.36 ± 3% -0.3 1.03 ± 11% perf-profile.children.cycles-pp.call_function_single_prep_ipi 0.22 ± 2% +0.0 0.25 ± 8% perf-profile.children.cycles-pp.switch_mm_irqs_off 0.23 ± 4% +0.0 0.28 ± 3% perf-profile.children.cycles-pp.local_clock_noinstr 62.26 +1.2 63.47 perf-profile.children.cycles-pp.schedule 66.06 +1.4 67.43 perf-profile.children.cycles-pp.__schedule 0.00 +1.8 1.75 ± 23% perf-profile.children.cycles-pp.poll_idle 6.82 ± 9% -3.5 3.36 ± 4% perf-profile.self.cycles-pp.intel_idle 1.35 ± 3% -0.3 1.02 ± 11% perf-profile.self.cycles-pp.call_function_single_prep_ipi 0.26 ± 4% -0.1 0.16 ± 4% perf-profile.self.cycles-pp.flush_smp_call_function_queue 0.24 ± 3% -0.0 0.20 ± 3% perf-profile.self.cycles-pp.set_next_entity 0.05 +0.0 0.06 perf-profile.self.cycles-pp.local_clock_noinstr 0.00 +1.7 1.66 ± 23% perf-profile.self.cycles-pp.poll_idle Disclaimer: Results have been estimated based on internal Intel analysis and are provided for informational purposes only. Any difference in system hardware or software design or configuration may affect actual performance. -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki

2 weeks

1
0
0 0

[PATCH 2/4] ALSA: wavefront: use scnprintf_append for longname construction

by Junrui Luo

Replace sprintf() calls with scnprintf() and the new scnprintf_append() helper function when constructing card->longname. This improves code readability and provides bounds checking. Cc: stable(a)vger.kernel.org Signed-off-by: Junrui Luo <moonafterrain(a)outlook.com> --- sound/isa/wavefront/wavefront.c | 37 +++++++++++++++++---------------- 1 file changed, 19 insertions(+), 18 deletions(-) diff --git a/sound/isa/wavefront/wavefront.c b/sound/isa/wavefront/wavefront.c index 07c68568091d..eec4be5c3217 100644 --- a/sound/isa/wavefront/wavefront.c +++ b/sound/isa/wavefront/wavefront.c @@ -492,26 +492,27 @@ snd_wavefront_probe (struct snd_card *card, int dev) length restrictions */ - sprintf(card->longname, "%s PCM 0x%lx irq %d dma %d", - card->driver, - chip->port, - cs4232_pcm_irq[dev], - dma1[dev]); + scnprintf(card->longname, sizeof(card->longname), + "%s PCM 0x%lx irq %d dma %d", + card->driver, + chip->port, + cs4232_pcm_irq[dev], + dma1[dev]); if (dma2[dev] >= 0 && dma2[dev] < 8) - sprintf(card->longname + strlen(card->longname), "&%d", dma2[dev]); - - if (cs4232_mpu_port[dev] > 0 && cs4232_mpu_port[dev] != SNDRV_AUTO_PORT) { - sprintf (card->longname + strlen (card->longname), - " MPU-401 0x%lx irq %d", - cs4232_mpu_port[dev], - cs4232_mpu_irq[dev]); - } - - sprintf (card->longname + strlen (card->longname), - " SYNTH 0x%lx irq %d", - ics2115_port[dev], - ics2115_irq[dev]); + scnprintf_append(card->longname, sizeof(card->longname), + "&%d", dma2[dev]); + + if (cs4232_mpu_port[dev] > 0 && cs4232_mpu_port[dev] != SNDRV_AUTO_PORT) + scnprintf_append(card->longname, sizeof(card->longname), + " MPU-401 0x%lx irq %d", + cs4232_mpu_port[dev], + cs4232_mpu_irq[dev]); + + scnprintf_append(card->longname, sizeof(card->longname), + " SYNTH 0x%lx irq %d", + ics2115_port[dev], + ics2115_irq[dev]); return snd_card_register(card); } -- 2.51.1.dirty

2 weeks

1
0
0 0

[PATCH] kallsyms: fix symbol type for "big" symbols

by Miguel Ojeda

`kallsyms_get_symbol_type()` does not take into account the potential extra byte for "big" symbols. This makes `/proc/kallsyms` output the wrong symbol type for such "big" symbols, such as a bogus `1` symbol type, which in turn confused other tooling [1]. Thus fix it. Cc: stable(a)vger.kernel.org Link: https://lore.kernel.org/all/CANiq72ns1sRukpX-4L3FgqfJw4nXZ5AyqQKCEeQ=nhyERG… Fixes: 73bbb94466fd ("kallsyms: support "big" kernel symbols") Signed-off-by: Miguel Ojeda <ojeda(a)kernel.org> --- Somehow this went unnoticed so far... In Fedora 42 I compared the System.map with `/proc/kallsyms` and that was the only symbol with a different type -- Arnaldo, could you please confirm this makes it go away for you? Thanks! kernel/kallsyms.c | 12 +++++++++++- 1 file changed, 11 insertions(+), 1 deletion(-) diff --git a/kernel/kallsyms.c b/kernel/kallsyms.c index 1e7635864124..4f9b612d6bf2 100644 --- a/kernel/kallsyms.c +++ b/kernel/kallsyms.c @@ -101,11 +101,21 @@ static unsigned int kallsyms_expand_symbol(unsigned int off, */ static char kallsyms_get_symbol_type(unsigned int off) { + const u8 len = kallsyms_names[off]; + + off++; + + /* + * If MSB is 1, it is a "big" symbol, so we need to skip two bytes. + */ + if ((len & 0x80) != 0) + off++; + /* * Get just the first code, look it up in the token table, * and return the first char from this token. */ - return kallsyms_token_table[kallsyms_token_index[kallsyms_names[off + 1]]]; + return kallsyms_token_table[kallsyms_token_index[kallsyms_names[off]]]; } base-commit: dc77806cf3b4788d328fddf245e86c5b529f31a2 -- 2.51.2

2 weeks

1
0
0 0

[PATCH v3 2/2] Bluetooth: hci_qca: Convert timeout from jiffies to ms

by Shuai Zhang

Since the timer uses jiffies as its unit rather than ms, the timeout value must be converted from ms to jiffies when configuring the timer. Otherwise, the intended 8s timeout is incorrectly set to approximately 33s. Cc: stable(a)vger.kernel.org Fixes: d841502c79e3 ("Bluetooth: hci_qca: Collect controller memory dump during SSR") Signed-off-by: Shuai Zhang <quic_shuaz(a)quicinc.com> --- drivers/bluetooth/hci_qca.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/bluetooth/hci_qca.c b/drivers/bluetooth/hci_qca.c index fa6be1992..c14b2fa9d 100644 --- a/drivers/bluetooth/hci_qca.c +++ b/drivers/bluetooth/hci_qca.c @@ -1602,7 +1602,7 @@ static void qca_wait_for_dump_collection(struct hci_dev *hdev) struct qca_data *qca = hu->priv; wait_on_bit_timeout(&qca->flags, QCA_MEMDUMP_COLLECTION, - TASK_UNINTERRUPTIBLE, MEMDUMP_TIMEOUT_MS); + TASK_UNINTERRUPTIBLE, msecs_to_jiffies(MEMDUMP_TIMEOUT_MS)); clear_bit(QCA_MEMDUMP_COLLECTION, &qca->flags); } -- 2.34.1

2 weeks

1
0
0 0

[PATCH v3 1/2] Bluetooth: qca: Fix delayed hw_error handling due to missing wakeup during SSR

by Shuai Zhang

When Bluetooth controller encounters a coredump, it triggers the Subsystem Restart (SSR) mechanism. The controller first reports the coredump data, and once the data upload is complete, it sends a hw_error event. The host relies on this event to proceed with subsequent recovery actions. If the host has not finished processing the coredump data when the hw_error event is received, it sets a timer to wait until either the data processing is complete or the timeout expires before handling the event. The current implementation lacks a wakeup trigger. As a result, even if the coredump data has already been processed, the host continues to wait until the timer expires, causing unnecessary delays in handling the hw_error event. To fix this issue, adds a `wake_up_bit()` call after the host finishes processing the coredump data. This ensures that the waiting thread is promptly notified and can proceed to handle the hw_error event without waiting for the timeout. Test case: - Trigger controller coredump using the command: `hcitool cmd 0x3f 0c 26`. - Use `btmon` to capture HCI logs. - Observe the time interval between receiving the hw_error event and the execution of the power-off sequence in the HCI log. Cc: stable(a)vger.kernel.org Signed-off-by: Shuai Zhang <quic_shuaz(a)quicinc.com> --- drivers/bluetooth/hci_qca.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/bluetooth/hci_qca.c b/drivers/bluetooth/hci_qca.c index 888176b0f..fa6be1992 100644 --- a/drivers/bluetooth/hci_qca.c +++ b/drivers/bluetooth/hci_qca.c @@ -1103,7 +1103,7 @@ static void qca_controller_memdump(struct work_struct *work) qca->qca_memdump = NULL; qca->memdump_state = QCA_MEMDUMP_COLLECTED; cancel_delayed_work(&qca->ctrl_memdump_timeout); - clear_bit(QCA_MEMDUMP_COLLECTION, &qca->flags); + clear_and_wake_up_bit(QCA_MEMDUMP_COLLECTION, &qca->flags); clear_bit(QCA_IBS_DISABLED, &qca->flags); mutex_unlock(&qca->hci_memdump_lock); return; @@ -1181,7 +1181,7 @@ static void qca_controller_memdump(struct work_struct *work) kfree(qca->qca_memdump); qca->qca_memdump = NULL; qca->memdump_state = QCA_MEMDUMP_COLLECTED; - clear_bit(QCA_MEMDUMP_COLLECTION, &qca->flags); + clear_and_wake_up_bit(QCA_MEMDUMP_COLLECTION, &qca->flags); } mutex_unlock(&qca->hci_memdump_lock); -- 2.34.1

2 weeks

1
0
0 0

PROBLEM: hwclock busted w/ M48T59 RTC (regression)

by Nick Bowler

Hi, After a stable kernel update, the hwclock command seems no longer functional on my SPARC system with an ST M48T59Y-70PC1 RTC: # hwclock [...long delay...] hwclock: select() to /dev/rtc0 to wait for clock tick timed out On prior kernels, there is no problem: # hwclock 2025-10-22 22:21:04.806992-04:00 I reproduced the same failure on 6.18-rc2 and bisected to this commit: commit 795cda8338eab036013314dbc0b04aae728880ab Author: Esben Haabendal <esben(a)geanix.com> Date: Fri May 16 09:23:35 2025 +0200 rtc: interface: Fix long-standing race when setting alarm This commit was backported to all current 6.x stable branches, as well as 5.15.x, so they all have the same regression. Reverting this commit on top of 6.18-rc2 corrects the problem. Let me know if you need any more info! Thanks, Nick

2 weeks

3
4
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror