linux-kernel - Re: Will smp_call_function_single(cpu, ...) broadcast IPI to all other cpus?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Fri, 28 Jun 2024 09:57:04 +0800
From: richard clark <richard.xnu.clark@...il.com>
To: Steven Rostedt <rostedt@...dmis.org>
Cc: Marc Zyngier <maz@...nel.org>, Mark Rutland <mark.rutland@....com>, will@...nel.org, 
	linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org, 
	"Russell King (Oracle)" <linux@...linux.org.uk>, Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: Will smp_call_function_single(cpu, ...) broadcast IPI to all
 other cpus?

Hi M. & Steve:

On Thu, Jun 27, 2024 at 10:12 PM Steven Rostedt <rostedt@...dmis.org> wrote:
>
> On Thu, 27 Jun 2024 11:38:58 +0100
> Marc Zyngier <maz@...nel.org> wrote:
>
> > You may want to enable stack trace recording and find out for yourself
> > where these ipi_raise() calls are coming from.
>
> Try trace-cmd:
>
>   # trace-cmd start -e ipi_raise -R 'stacktrace if reason=="Function call interrupts"'
>   # taskset -c 0 insmod /kmods/ipi_test.ko
>   # trace-cmd stop
>   # trace-cmd show
>
          insmod-3169    [000] ....1.. 51869.953886: ipi_raise:
target_mask=00000000,00000ffe (Function call interrupts)
          insmod-3169    [000] ....2.. 51869.953887: <stack trace>
 => trace_event_raw_event_ipi_raise
 => smp_cross_call
 => arch_send_call_function_ipi_mask
 => smp_call_function_many_cond
 => kick_all_cpus_sync
 => load_module
 => __do_sys_finit_module
 => __arm64_sys_finit_module
 => invoke_syscall
 => el0_svc_common.constprop.0
 => do_el0_svc
 => el0_svc
 => el0t_64_sync_handler
 => el0t_64_sync
          insmod-3169    [000] ....1.. 51869.953897: ipi_raise:
target_mask=00000000,00000ffe (Function call interrupts)
          insmod-3169    [000] ....2.. 51869.953898: <stack trace>
 => trace_event_raw_event_ipi_raise
 => smp_cross_call
 => arch_send_call_function_ipi_mask
 => smp_call_function_many_cond
 => kick_all_cpus_sync
 => load_module
 => __do_sys_finit_module
 => __arm64_sys_finit_module
 => invoke_syscall
 => el0_svc_common.constprop.0
 => do_el0_svc
 => el0_svc
 => el0t_64_sync_handler
 => el0t_64_sync
          insmod-3169    [000] ....1.. 51869.954145: ipi_raise:
target_mask=00000000,00000080 (Function call interrupts)
          insmod-3169    [000] ....2.. 51869.954146: <stack trace>
 => trace_event_raw_event_ipi_raise
 => smp_cross_call
 => arch_send_call_function_single_ipi
 => send_call_function_single_ipi
 => generic_exec_single
 => smp_call_function_single
 => run_smp_call_function_test
 => ipi_lat_init
 => do_one_initcall
 => do_init_module
 => load_module

Ah, the first two IPIs raised from the load_module() ->
flush_module_icache() -> flush_icache_range() -> kick_all_cpus_sync()
-> smp_call_function(do_nothing, NULL, 1) chain.
Very powerful and great tool :) Thanks guys!

> -- Steve