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

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

2 weeks, 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

2 weeks, 4 days

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, 4 days

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, 4 days

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, 4 days

3
4
0 0

[PATCH net] net: txgbe: remove wx_ptp_init() in device reset flow

by Jiawen Wu

The functions txgbe_up() and txgbe_down() are called in pairs to reset hardware configurations. PTP stop function is not called in txgbe_down(), so there is no need to call PTP init function in txgbe_up(). Fixes: 06e75161b9d4 ("net: wangxun: Add support for PTP clock") Cc: stable(a)vger.kernel.org Signed-off-by: Jiawen Wu <jiawenwu(a)trustnetic.com> --- drivers/net/ethernet/wangxun/txgbe/txgbe_main.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/net/ethernet/wangxun/txgbe/txgbe_main.c b/drivers/net/ethernet/wangxun/txgbe/txgbe_main.c index daa761e48f9d..114d6f46139b 100644 --- a/drivers/net/ethernet/wangxun/txgbe/txgbe_main.c +++ b/drivers/net/ethernet/wangxun/txgbe/txgbe_main.c @@ -297,7 +297,6 @@ void txgbe_down(struct wx *wx) void txgbe_up(struct wx *wx) { wx_configure(wx); - wx_ptp_init(wx); txgbe_up_complete(wx); } -- 2.48.1

2 weeks, 5 days

2
4
0 0

[to-be-updated] kernel-kexec-fix-ima-when-allocation-happens-in-cma-area.patch removed from -mm tree

by Andrew Morton

The quilt patch titled Subject: kernel/kexec: fix IMA when allocation happens in CMA area has been removed from the -mm tree. Its filename was kernel-kexec-fix-ima-when-allocation-happens-in-cma-area.patch This patch was dropped because an updated version will be issued ------------------------------------------------------ From: Pingfan Liu <piliu(a)redhat.com> Subject: kernel/kexec: fix IMA when allocation happens in CMA area Date: Wed, 5 Nov 2025 21:09:22 +0800 When I tested kexec with the latest kernel, I ran into the following warning: [ 40.712410] ------------[ cut here ]------------ [ 40.712576] WARNING: CPU: 2 PID: 1562 at kernel/kexec_core.c:1001 kimage_map_segment+0x144/0x198 [...] [ 40.816047] Call trace: [ 40.818498] kimage_map_segment+0x144/0x198 (P) [ 40.823221] ima_kexec_post_load+0x58/0xc0 [ 40.827246] __do_sys_kexec_file_load+0x29c/0x368 [...] [ 40.855423] ---[ end trace 0000000000000000 ]--- This is caused by the fact that kexec allocates the destination directly in the CMA area. In that case, the CMA kernel address should be exported directly to the IMA component, instead of using the vmalloc'd address. Link: https://lkml.kernel.org/r/20251105130922.13321-2-piliu@redhat.com Fixes: 0091d9241ea2 ("kexec: define functions to map and unmap segments") Signed-off-by: Pingfan Liu <piliu(a)redhat.com> 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> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- kernel/kexec_core.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) --- a/kernel/kexec_core.c~kernel-kexec-fix-ima-when-allocation-happens-in-cma-area +++ a/kernel/kexec_core.c @@ -967,6 +967,7 @@ void *kimage_map_segment(struct kimage * kimage_entry_t *ptr, entry; struct page **src_pages; unsigned int npages; + struct page *cma; void *vaddr = NULL; int i; @@ -974,6 +975,9 @@ void *kimage_map_segment(struct kimage * size = image->segment[idx].memsz; eaddr = addr + size; + cma = image->segment_cma[idx]; + if (cma) + return cma; /* * Collect the source pages and map them in a contiguous VA range. */ @@ -1014,7 +1018,8 @@ void *kimage_map_segment(struct kimage * void kimage_unmap_segment(void *segment_buffer) { - vunmap(segment_buffer); + if (is_vmalloc_addr(segment_buffer)) + vunmap(segment_buffer); } struct kexec_load_limit { _ Patches currently in -mm which might be from piliu(a)redhat.com are

2 weeks, 5 days

2
1
0 0

Kontoumstrukturierung für Kredite und Investitionen

by Gerald Johnson

2 weeks, 5 days

1
0
0 0

[to-be-updated] kernel-kexec-change-the-prototype-of-kimage_map_segment.patch removed from -mm tree

by Andrew Morton

The quilt patch titled Subject: kernel/kexec: change the prototype of kimage_map_segment() has been removed from the -mm tree. Its filename was kernel-kexec-change-the-prototype-of-kimage_map_segment.patch This patch was dropped because an updated version will be issued ------------------------------------------------------ From: Pingfan Liu <piliu(a)redhat.com> Subject: kernel/kexec: change the prototype of kimage_map_segment() Date: Wed, 5 Nov 2025 21:09:21 +0800 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. Link: https://lkml.kernel.org/r/20251105130922.13321-1-piliu@redhat.com Fixes: 0091d9241ea2 ("kexec: define functions to map and unmap segments") Signed-off-by: Pingfan Liu <piliu(a)redhat.com> 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> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.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(-) --- a/include/linux/kexec.h~kernel-kexec-change-the-prototype-of-kimage_map_segment +++ a/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 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 --- a/kernel/kexec_core.c~kernel-kexec-change-the-prototype-of-kimage_map_segment +++ a/kernel/kexec_core.c @@ -960,17 +960,20 @@ int kimage_load_segment(struct kimage *i 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. */ --- a/security/integrity/ima/ima_kexec.c~kernel-kexec-change-the-prototype-of-kimage_map_segment +++ a/security/integrity/ima/ima_kexec.c @@ -250,9 +250,7 @@ void ima_kexec_post_load(struct kimage * 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; _ Patches currently in -mm which might be from piliu(a)redhat.com are kernel-kexec-fix-ima-when-allocation-happens-in-cma-area.patch

2 weeks, 5 days

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror