Re: [RFC PATCH 5/5] treewide: Rename and trace arch-definitions of smp_send_reschedule()

On Fri, Oct 7, 2022 at 11:46 PM Valentin Schneider wrote: > > To be able to trace invocations of smp_send_reschedule(), rename the > arch-specific definitions of it to arch_smp_send_reschedule() and wrap it > into an smp_send_reschedule() that contains a tracepoint. > > Signed-off-by: Valentin Sch

Re: [PATCH] RISC-V: Add STACKLEAK erasing the kernel stack at the end of syscalls

On Fri, Oct 7, 2022 at 10:31 AM Palmer Dabbelt wrote: > > On Tue, 06 Sep 2022 10:35:10 PDT (-0700), conor.doo...@microchip.com wrote: > > On 03/09/2022 17:23, guo...@kernel.org wrote: > >> EXTERNAL EMAIL: Do not click links or open attachments unless you know the > >> content is safe > >> > >> Fr

Re: [RFC PATCH 0/5] Generic IPI sending tracepoint

Hi Valentin, On Fri, Oct 07, 2022 at 04:41:40PM +0100, Valentin Schneider wrote: > Background > == > > Detecting IPI *reception* is relatively easy, e.g. using > trace_irq_handler_{entry,exit} or even just function-trace > flush_smp_call_function_queue() for SMP calls. > > Figuring out

[RFC PATCH 5/5] treewide: Rename and trace arch-definitions of smp_send_reschedule()

To be able to trace invocations of smp_send_reschedule(), rename the arch-specific definitions of it to arch_smp_send_reschedule() and wrap it into an smp_send_reschedule() that contains a tracepoint. Signed-off-by: Valentin Schneider --- arch/alpha/kernel/smp.c | 2 +- arch/arc/kernel/

[RFC PATCH 3/5] smp: Add a multi-CPU variant to send_call_function_single_ipi()

This simply wraps around the arch function and prepends it with a tracepoint, bringing parity with send_call_function_single_ipi(). Signed-off-by: Valentin Schneider --- kernel/smp.c | 8 +++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/kernel/smp.c b/kernel/smp.c index 7a7a

[RFC PATCH 4/5] irq_work: Trace calls to arch_irq_work_raise()

Adding a tracepoint to send_call_function_single_ipi() covers irq_work_queue_on() when the CPU isn't the local one - add a tracepoint to irq_work_raise() to cover the other cases. Signed-off-by: Valentin Schneider --- kernel/irq_work.c | 12 +++- 1 file changed, 11 insertions(+), 1 delet

[RFC PATCH 2/5] sched, smp: Trace send_call_function_single_ipi()

send_call_function_single_ipi() is the thing that sends IPIs at the bottom of smp_call_function*() via either generic_exec_single() or smp_call_function_many_cond(). Give it an IPI-related tracepoint. Note that this ends up tracing any IPI sent via __smp_call_single_queue(), which covers __ttwu_qu

[RFC PATCH 1/5] trace: Add trace_ipi_send_{cpu, cpumask}

trace_ipi_raise is unsuitable for generically tracing IPI sources; add a variant of it that takes a callsite and a CPU. Define a macro helper for handling IPIs sent to multiple CPUs. Signed-off-by: Valentin Schneider --- include/trace/events/ipi.h | 27 +++ 1 file changed

[RFC PATCH 0/5] Generic IPI sending tracepoint

Background == Detecting IPI *reception* is relatively easy, e.g. using trace_irq_handler_{entry,exit} or even just function-trace flush_smp_call_function_queue() for SMP calls. Figuring out their *origin*, is trickier as there is no generic tracepoint tied to e.g. smp_call_function():

Re: [PATCH] RISC-V: Add STACKLEAK erasing the kernel stack at the end of syscalls

On Thu, Oct 06, 2022 at 07:31:01PM -0700, Palmer Dabbelt wrote: > On Tue, 06 Sep 2022 10:35:10 PDT (-0700), conor.doo...@microchip.com wrote: > > On 03/09/2022 17:23, guo...@kernel.org wrote: > > > EXTERNAL EMAIL: Do not click links or open attachments unless you know > > > the content is safe > >