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]
Message-ID: <20090325183024.GA6746@Krystal>
Date:	Wed, 25 Mar 2009 14:30:24 -0400
From:	Mathieu Desnoyers <mathieu.desnoyers@...ymtl.ca>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	Peter Zijlstra <peterz@...radead.org>,
	Christoph Hellwig <hch@...radead.org>,
	Jason Baron <jbaron@...hat.com>, akpm@...ux-foundation.org,
	linux-kernel@...r.kernel.org, ltt-dev@...ts.casi.polymtl.ca,
	Frederic Weisbecker <fweisbec@...il.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Russell King <rmk+lkml@....linux.org.uk>,
	Masami Hiramatsu <mhiramat@...hat.com>,
	"Frank Ch. Eigler" <fche@...hat.com>,
	Hideo AOKI <haoki@...hat.com>,
	Takashi Nishiie <t-nishiie@...css.fujitsu.com>,
	Steven Rostedt <rostedt@...dmis.org>,
	Eduard - Gabriel Munteanu <eduard.munteanu@...ux360.ro>
Subject: Re: [patch 2/9] LTTng instrumentation - irq

* Ingo Molnar (mingo@...e.hu) wrote:
> 
> * Ingo Molnar <mingo@...e.hu> wrote:
> 
> > 
> > * Mathieu Desnoyers <mathieu.desnoyers@...ymtl.ca> wrote:
> > 
> > > If we want to do this logically, without thinking about tracer 
> > > performance impact, we could/should do :
> > > 
> > > trace_irq_entry(irqno, pt_regs)
> > >   for_each_handler() {
> > >     trace_irq_handler_entry(action)
> > >     action->handler()
> > >     trace_irq_handler_exit(ret)
> > >   }
> > > trace_irq_exit(retval)
> > 
> > Not really.
> 
> Put differently: we seem to agree on handler invocation entry/exit 
> events (and those are handled by Jason's patch already), and that's 
> good.
> 

Yes, we need to get this information into the trace stream somehow.

> I dont think we need two events for physical IRQ events though. One 
> is enough: entry event. What meaning does 'retval' have in your 
> pseudo-code above? None typically.
> 

Hrm, an event means more that the "payload" it has. Just saving "here is
a return from interrupt handler" without any return value is valuable
per se because it lets the trace analyzer know when the hardirq handler
ended.

e.g., if we instrument the x86 local apic irq handler only with an "irq
entry" event, we would not be able to detect if the following events are
nested on top of the IRQ handler or are executed in thread context.

Having those two hardirq entry/exit events is also especially useful to
figure out the maximum interrupt latency caused by long interrupt
handlers (or that could be many handlers hooked on the same interrupt
line).

Mathieu

-- 
Mathieu Desnoyers
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68
--
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ