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

[for-linus][PATCH 1/3] ring-buffer: Do not warn in ring_buffer_map_get_reader() when reader catches up

by Steven Rostedt

From: Steven Rostedt <rostedt(a)goodmis.org> The function ring_buffer_map_get_reader() is a bit more strict than the other get reader functions, and except for certain situations the rb_get_reader_page() should not return NULL. If it does, it triggers a warning. This warning was triggering but after looking at why, it was because another acceptable situation was happening and it wasn't checked for. If the reader catches up to the writer and there's still data to be read on the reader page, then the rb_get_reader_page() will return NULL as there's no new page to get. In this situation, the reader page should not be updated and no warning should trigger. Cc: stable(a)vger.kernel.org Cc: Masami Hiramatsu <mhiramat(a)kernel.org> Cc: Mathieu Desnoyers <mathieu.desnoyers(a)efficios.com> Cc: Vincent Donnefort <vdonnefort(a)google.com> Reported-by: syzbot+92a3745cea5ec6360309(a)syzkaller.appspotmail.com Closes: https://lore.kernel.org/all/690babec.050a0220.baf87.0064.GAE@google.com/ Link: https://lore.kernel.org/20251016132848.1b11bb37@gandalf.local.home Fixes: 117c39200d9d7 ("ring-buffer: Introducing ring-buffer mapping functions") Signed-off-by: Steven Rostedt (Google) <rostedt(a)goodmis.org> --- kernel/trace/ring_buffer.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/kernel/trace/ring_buffer.c b/kernel/trace/ring_buffer.c index 1244d2c5c384..afcd3747264d 100644 --- a/kernel/trace/ring_buffer.c +++ b/kernel/trace/ring_buffer.c @@ -7344,6 +7344,10 @@ int ring_buffer_map_get_reader(struct trace_buffer *buffer, int cpu) goto out; } + /* Did the reader catch up with the writer? */ + if (cpu_buffer->reader_page == cpu_buffer->commit_page) + goto out; + reader = rb_get_reader_page(cpu_buffer); if (WARN_ON(!reader)) goto out; -- 2.51.0

1 week, 3 days

1
0
0 0

[PATCH v1] Bluetooth: btusb: add new custom firmwares

by Shuai Zhang

There are custom-made firmwares based on board ID for a given QCA BT chip sometimes, and they are different with existing firmwares and put in a separate subdirectory to avoid conflict, for example: QCA2066, as a variant of WCN6855, has firmwares under 'qca/QCA2066/' of linux-firmware repository. Cc: stable(a)vger.kernel.org Signed-off-by: Shuai Zhang <quic_shuaz(a)quicinc.com> --- drivers/bluetooth/btusb.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c index dcbff7641..7175e9b2d 100644 --- a/drivers/bluetooth/btusb.c +++ b/drivers/bluetooth/btusb.c @@ -3273,6 +3273,7 @@ static const struct qca_device_info qca_devices_table[] = { static const struct qca_custom_firmware qca_custom_btfws[] = { { 0x00130201, 0x030A, "QCA2066" }, + { 0x00130201, 0x030B, "QCA2066" }, { }, }; -- 2.34.1

1 week, 3 days

2
2
0 0

[PATCH v2] drivers/usb/dwc3: fix PCI parent check

by Punit Agrawal

From: Jamie Iles <jamie.iles(a)oss.qualcomm.com> The sysdev_is_parent check was being used to infer PCI devices that have the DMA mask set from the PCI capabilities, but sysdev_is_parent is also used for non-PCI ACPI devices in which case the DMA mask would be the bus default or as set by the _DMA method. Without this fix the DMA mask would default to 32-bits and so allocation would fail if there was no DRAM below 4GB. Fixes: 47ce45906ca9 ("usb: dwc3: leave default DMA for PCI devices") Cc: stable(a)vger.kernel.org Signed-off-by: Jamie Iles <jamie.iles(a)oss.qualcomm.com> Signed-off-by: Punit Agrawal <punit.agrawal(a)oss.qualcomm.com> Acked-by: Thinh Nguyen <Thinh.Nguyen(a)synopsys.com> --- v1[0] -> v2: * Added tags * Cc stable [0] https://lore.kernel.org/all/20251105145801.485371-1-punit.agrawal@oss.qualc… drivers/usb/dwc3/core.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c index ae140c356295..c2ce2f5e60a1 100644 --- a/drivers/usb/dwc3/core.c +++ b/drivers/usb/dwc3/core.c @@ -25,6 +25,7 @@ #include <linux/of.h> #include <linux/of_graph.h> #include <linux/acpi.h> +#include <linux/pci.h> #include <linux/pinctrl/consumer.h> #include <linux/pinctrl/devinfo.h> #include <linux/reset.h> @@ -2241,7 +2242,7 @@ int dwc3_core_probe(const struct dwc3_probe_data *data) dev_set_drvdata(dev, dwc); dwc3_cache_hwparams(dwc); - if (!dwc->sysdev_is_parent && + if (!dev_is_pci(dwc->sysdev) && DWC3_GHWPARAMS0_AWIDTH(dwc->hwparams.hwparams0) == 64) { ret = dma_set_mask_and_coherent(dwc->sysdev, DMA_BIT_MASK(64)); if (ret) -- 2.34.1

1 week, 3 days

1
0
0 0

[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

1 week, 3 days

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

1 week, 3 days

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

1 week, 4 days

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)

1 week, 4 days

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

1 week, 4 days

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

1 week, 4 days

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

1 week, 4 days

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror