| 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
| ||
|
Date: Thu, 9 May 2013 14:25:44 +0000
From: Seiji Aguchi <seiji.aguchi@....com>
To: "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"x86@...nel.org" <x86@...nel.org>,
"rostedt@...dmis.org" <rostedt@...dmis.org>,
"hpa@...or.com" <hpa@...or.com>
CC: "Thomas Gleixner (tglx@...utronix.de)" <tglx@...utronix.de>,
"'mingo@...e.hu' (mingo@...e.hu)" <mingo@...e.hu>,
"Borislav Petkov (bp@...en8.de)" <bp@...en8.de>,
"linux-edac@...r.kernel.org" <linux-edac@...r.kernel.org>,
"Luck, Tony (tony.luck@...el.com)" <tony.luck@...el.com>,
"dle-develop@...ts.sourceforge.net"
<dle-develop@...ts.sourceforge.net>,
Tomoki Sekiyama <tomoki.sekiyama@....com>
Subject: RE: [PATCH v12 0/3] trace,x86: irq vector tracepoint support
Steven, Peter
When can I get feedback?
Seiji
> -----Original Message-----
> From: Seiji Aguchi
> Sent: Friday, April 05, 2013 3:16 PM
> To: linux-kernel@...r.kernel.org; x86@...nel.org; rostedt@...dmis.org; hpa@...or.com
> Cc: Thomas Gleixner (tglx@...utronix.de); 'mingo@...e.hu' (mingo@...e.hu); Borislav Petkov (bp@...en8.de); linux-
> edac@...r.kernel.org; Luck, Tony (tony.luck@...el.com); dle-develop@...ts.sourceforge.net; Tomoki Sekiyama
> Subject: [PATCH v12 0/3] trace,x86: irq vector tracepoint support
>
> Change log
> v11 -> v12
> - Rebase to 3.9-rc5
>
> v10 -> v11
> - Rebase to 3.9-rc2
> - Add a modification for hyperv_callback vector. (patch 2/3)
> - Change a way to switch idt to check the table in use instead of saving/restoring it,
> because saving/restoring functions will break if we have to add another one. (patch 2/3)
>
> v9 -> v10
> - Add an explanation the reason why tracepoints has to place inside irq enter/exit handling. (patch 3/3)
>
> v8 -> v9
> - Rebase to 3.8-rc6
> - Add Steven's email address at the top of the message and
> move my signed-off-by below Steven's one because it is
> originally created by Steven. (patch 1/3)
> - Introduce a irq_vector_mutex to avoid a race at registering/unregistering
> time. (patch 2/3)
> - Use a per_cpu data to orig_idt_descr because IDT descritor is needed to each cpu
> and the appropriate data type is per_cpu data. It is suggested by Steven.
> (patch 2/3)
>
> v7 -> v8
> - Rebase to 3.8-rc4
> - Add a patch 1 introducing DEFINE_EVENT_FN() macro.
> - Rename original patches 1 and 2 to 2 and 3.
> - Change a definition of tracepoint to use DEFINE_EVENT_FN(). (patch 2)
> - Change alloc_intr_gate() to use do{}while(0) to avoid a warning
> of checkpatch.pl. (patch 2)
> - Move entering_irq()/exiting_irq() to arch/x86/include/asm/apic.h (patch 3)
>
> v6 -> v7
> - Divide into two patches to make a code review easier.
> Summery of each patch is as follows.
> - Patch 1/2
> - Add an irq_vector tracing infrastructure.
> - Create idt_table for tracing. It is refactored to avoid duplicating
> existing logic.
> - Duplicate new irq handlers inserted tracepoints.
>
> - Patch 2/2
> - Share a common logic among irq handlers to make them
> manageable and readable.
>
> v5 -> v6
> - Rebased to 3.7
>
> v4 -> v5
> - Rebased to 3.6.0
>
> - Introduce a logic switching IDT at enabling/disabling TP time
> so that a time penalty makes a zero when tracepoints are disabled.
> This IDT is created only when CONFIG_TRACEPOINTS is enabled.
>
> - Remove arch_irq_vector_entry/exit and add followings again
> so that we can add each tracepoint in a generic way.
> - error_apic_vector
> - thermal_apic_vector
> - threshold_apic_vector
> - spurious_apic_vector
> - x86_platform_ipi_vector
>
> - Drop nmi tracepoints to begin with apic interrupts and discuss a logic switching
> IDT first.
>
> - Move irq_vectors.h in the directory of arch/x86/include/asm/trace because
> I'm not sure if a logic switching IDT is sharable with other architectures.
>
> v3 -> v4
> - Add a latency measurement of each tracepoint
> - Rebased to 3.6-rc6
>
> v2 -> v3
> - Remove an invalidate_tlb_vector event because it was replaced by a call function vector
> in a following commit.
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commit;h=52aec3308db85f4e9f5c8b9f5dc4fbd0138c6fa4
>
> v1 -> v2
> - Modify variable name from irq to vector.
> - Merge arch-specific tracepoints below to an arch_irq_vector_entry/exit.
> - error_apic_vector
> - thermal_apic_vector
> - threshold_apic_vector
> - spurious_apic_vector
> - x86_platform_ipi_vector
>
> [Purpose of this patch]
>
> As Vaibhav explained in the thread below, tracepoints for irq vectors are useful.
>
> http://www.spinics.net/lists/mm-commits/msg85707.html
>
> <snip>
> The current interrupt traces from irq_handler_entry and irq_handler_exit provide when an interrupt is handled.
> They provide good data about when the system has switched to kernel space and how it affects the currently running processes.
>
> There are some IRQ vectors which trigger the system into kernel space, which are not handled in generic IRQ handlers.
> Tracing such events gives us the information about IRQ interaction with other system events.
>
> The trace also tells where the system is spending its time. We want to know which cores are handling interrupts and
> how they are affecting other processes in the system. Also, the trace provides information about when the cores are
> idle and which interrupts are changing that state.
> <snip>
>
> On the other hand, my usecase is tracing just local timer event and getting a value of instruction pointer.
>
> I suggested to add an argument local timer event to get instruction pointer before.
> But there is another way to get it with external module like systemtap.
> So, I don't need to add any argument to irq vector tracepoints now.
>
> [Patch Description]
>
> Vaibhav's patch shared a trace point ,irq_vector_entry/irq_vector_exit, in all events.
> But there is an above use case to trace specific irq_vector rather than tracing all events.
> In this case, we are concerned about overhead due to unwanted events.
>
> This patch adds following tracepoints instead of introducing irq_vector_entry/exit.
> so that we can enable them independently.
> - local_timer_vector
> - reschedule_vector
> - call_function_vector
> - call_function_single_vector
> - irq_work_entry_vector
> - error_apic_vector
> - thermal_apic_vector
> - threshold_apic_vector
> - spurious_apic_vector
> - x86_platform_ipi_vector
>
> Please see descriptions in each patch.
>
> Seiji Aguchi (2):
> trace,x86: add x86 irq vector tracepoints
> trace,x86: code-sharing between non-trace and trace irq handlers
>
> Steven Rostedt (1):
> tracing: Add DEFINE_EVENT_FN() macro
>
> arch/x86/include/asm/apic.h | 27 +++++
> arch/x86/include/asm/desc.h | 36 +++++++-
> arch/x86/include/asm/entry_arch.h | 5 +-
> arch/x86/include/asm/hw_irq.h | 16 +++
> arch/x86/include/asm/mshyperv.h | 1 +
> arch/x86/include/asm/trace/irq_vectors.h | 159 ++++++++++++++++++++++++++++++
> arch/x86/kernel/Makefile | 1 +
> arch/x86/kernel/apic/apic.c | 71 +++++++++++---
> arch/x86/kernel/cpu/common.c | 12 ++-
> arch/x86/kernel/cpu/mcheck/therm_throt.c | 24 ++++-
> arch/x86/kernel/cpu/mcheck/threshold.c | 24 ++++-
> arch/x86/kernel/entry_32.S | 12 ++-
> arch/x86/kernel/entry_64.S | 29 +++++-
> arch/x86/kernel/head_64.S | 6 +
> arch/x86/kernel/irq.c | 31 ++++--
> arch/x86/kernel/irq_work.c | 24 ++++-
> arch/x86/kernel/smp.c | 65 +++++++++++--
> arch/x86/kernel/tracepoint.c | 71 +++++++++++++
> include/linux/tracepoint.h | 2 +
> include/trace/define_trace.h | 5 +
> include/trace/ftrace.h | 4 +
> include/xen/events.h | 3 +
> 22 files changed, 570 insertions(+), 58 deletions(-)
> create mode 100644 arch/x86/include/asm/trace/irq_vectors.h
> create mode 100644 arch/x86/kernel/tracepoint.c
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists