ernel.org;
> t...@linutronix.de; mi...@elte.hu; b...@alien8.de; linux-
> e...@vger.kernel.org; tony.l...@intel.com; dle-deve...@lists.sourceforge.net;
> Tomoki Sekiyama
> Subject: Re: [PATCH v13 3/3] trace,x86: Add irq vector tracepoints
>
> On Tue, 2013-06-04 at 20:20 +000
On Tue, 2013-06-04 at 20:20 +, Seiji Aguchi wrote:
> Steven,
>
> >
> > Hmm, maybe we can do it. Have two counters, a debug_idt_ctr and a
> > trace_idt_ctr, then have a function that basically does this:
> >
> > if (this_cpu_read(debug_idt_ctr))
>
> I think we can use "debug_stack_use_ct
Steven,
>
> Hmm, maybe we can do it. Have two counters, a debug_idt_ctr and a
> trace_idt_ctr, then have a function that basically does this:
>
> if (this_cpu_read(debug_idt_ctr))
I think we can use "debug_stack_use_ctr" for the checking.
Is it correct?
Or, do I need to introduce a new d
> > The point is that the IDT address itself should not be mutable state if
> > it can be at all avoided.
>
> Hmm, maybe we can do it. Have two counters, a debug_idt_ctr and a
> trace_idt_ctr, then have a function that basically does this:
>
> if (this_cpu_read(debug_idt_ctr))
>
On Tue, 2013-06-04 at 11:15 -0700, H. Peter Anvin wrote:
> On 06/03/2013 04:53 PM, Steven Rostedt wrote:
> >
> > This way we wont be opening up any easy root holes where if a process
> > finds a way to modify some arbitrary kernel memory, we can prevent it
> > from modifying the current_idt_descr_
On 06/03/2013 04:53 PM, Steven Rostedt wrote:
>
> This way we wont be opening up any easy root holes where if a process
> finds a way to modify some arbitrary kernel memory, we can prevent it
> from modifying the current_idt_descr_ptr and have a nice way to exploit
> the IDT. Sure, one can argue t
> Yeah, I believe this does work. But you probably should add a comment
> like the following:
OK. I will add some comment above " extern atomic_long_t
current_idt_descr_ptr;".
>
> /*
> * The current_idt_descr_ptr can only be set out of interrupt context
> * to avoid races.
I will introduc
On Mon, 2013-06-03 at 15:29 -0400, Seiji Aguchi wrote:
Yeah, I believe this does work. But you probably should add a comment
like the following:
/*
* The current_idt_descr_ptr can only be set out of interrupt context
* to avoid races. Once set, the load_current_idt() is called by
interrupt
* c
[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
The current interrupt traces from irq_handler_entry and irq_handler_exit
provide when an interrupt is handled. They provide good data
9 matches
Mail list logo
