Messages in this thread | | | Date | Sat, 21 Mar 2009 21:54:17 +0530 | From | "K.Prasad" <> | Subject | Re: [Patch 11/11] ftrace plugin for kernel symbol tracing using HW Breakpoint interfaces - v2 |
| |
On Fri, Mar 20, 2009 at 10:04:52AM +0100, Frederic Weisbecker wrote: > On Fri, Mar 20, 2009 at 05:20:32AM +0530, K.Prasad wrote: > > This patch adds an ftrace plugin to detect and profile memory access over > > kernel variables. It uses HW Breakpoint interfaces to 'watch memory > > addresses. > > > > Signed-off-by: K.Prasad <prasad@linux.vnet.ibm.com> > > --- > > kernel/trace/Kconfig | 21 + > > kernel/trace/Makefile | 1 > > kernel/trace/trace.h | 25 + > > kernel/trace/trace_ksym.c | 555 ++++++++++++++++++++++++++++++++++++++++++ > > kernel/trace/trace_selftest.c | 36 ++ > > 5 files changed, 638 insertions(+) > >
> > + > > +void ksym_collect_stats(unsigned long hbkpt_hit_addr) > > +{ > > + struct hlist_node *node; > > + struct trace_ksym *entry; > > + > > + spin_lock(&ksym_stat_lock); > > > I see that can be called from ksym_hbkpt_handler which in turn > can be called from interrupt context, right? > You can issue a deadlock if you don't disable interrupts here. > > Thanks, > Frederic. >
ksym_collect_stats<--ksym_hbkpt_handler<--hw_breakpoint_handler<--do_debug invocation happens with interrupts enabled (IF bit is set). I do find that a few plugins in kernel/trace enclose the trace_buffer_lock_reserve()--trace_buffer_unlock_commit() invocation within interrupt-disabled code. Is that a requirement there?
The potential deadlock scenario you foresee isn't obvious to me. Can you explain?
Thanks, K.Prasad
| |