From: "K.Prasad" <prasad@linux.vnet.ibm.com>
To: Alan Stern <stern@rowland.harvard.edu>,
Steven Rostedt <rostedt@goodmis.org>,
Frederic Weisbecker <fweisbec@gmail.com>
Cc: Ingo Molnar <mingo@elte.hu>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
Benjamin Herrenschmidt <benh@au1.ibm.com>,
maneesh@linux.vnet.ibm.com, Roland McGrath <roland@redhat.com>,
Masami Hiramatsu <mhiramat@redhat.com>
Subject: [Patch 00/12] Hardware Breakpoint interfaces
Date: Mon, 11 May 2009 17:21:42 +0530 [thread overview]
Message-ID: <20090511115142.GA25673@in.ibm.com> (raw)
Hi Alan,
Please find the new set of patches with the changes mentioned below.
Kindly let me know your comments with respect to the same.
Hi Frederic/Steven,
Please find a few changes in the ftrace plugin code w.r.t.
synchronisation primitives (prefixed in the changelog with FTRACE). Kindly let
me know your comments.
Changelog
-----------
- on_each_cpu() call will now return only after all functions calls made through
IPI have finished (@wait parameter is set to 1). This is required since
changes made in code following on_each_cpu() [such as incrementing
hbp_kernel_pos] have side-effects on the execution of the functions invoked
through IPIs. It is also safe to make them wait inside spin_lock() context as
it does a busy wait using cpu_relax().
- Introduced a new per-cpu array of pointers to 'struct hw_breakpoint'
called 'this_hbp_kernel'. This per-cpu variable helps overcome any
side-effects in hbp_handler() due to parallel execution of
(un)register_kernel_hw_breakpoint() on other CPUs causing 'hbp_kernel' value
to change.
- Hardware Breakpoint exceptions due to lazy debug register switching is
now identified through the absence of TIF_DEBUG task flag in the current
process. This eliminates the need to store the process that last set the
debug register in 'last_debugged_task'.
- Converted spin_lock() in kernel/hw_breakpoint.c to spin_lock_bh(). This is
to ward-off potential circular dependancy over 'hw_breakpoint_lock' when
flush_thread_hw_breakpoint() is invoked in softIRQ context.
- Ptrace code now directly uses the exported interfaces
(un)register_user_hw_breakpoint() thereby addressing some of the issues
pointed out in code-review here:http://lkml.org/lkml/2009/5/4/367.
- An optimisation in arch_update_kernel_hw_breakpoints() code resulting in a
few modifications to the function and removal of kdr7_masks[] global array (as
pointed out by Alan Stern).
- [FTRACE] Implementation of RCU based locking mechanism in the ftrace plugin
code (kernel/trace/trace_ksym.c), specially to avoid the potential circular
dependancy through ksym_collect_stats() invoked in exception context (while
attempting to acquite a spin_lock() already used in control-plane). All
add/delete operations to the hlist pointed by 'ksym_filter_head' are now
protected by RCU.
- [FTRACE] Revert the spin_lock() based implementation in kernel/trace/trace_ksym.c
to mutex based one, as a result of the above change. These locks are no longer
required in preempt_disable() code due to RCU implementation in
ksym_collect_stats() and hence the change.
- The patches are now based on commit 5863f0756c57cc0ce23701138bfc88ab3d1f3721
of -tip tree.
Thanks,
K.Prasad
next reply other threads:[~2009-05-11 11:52 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-05-11 11:51 K.Prasad [this message]
-- strict thread matches above, loose matches on Subject: below --
2009-06-01 18:12 [Patch 00/12] Hardware Breakpoint interfaces K.Prasad
2009-05-30 10:47 K.Prasad
2009-05-21 14:00 K.Prasad
2009-05-16 0:23 K.Prasad
2009-05-15 10:53 K.Prasad
2009-05-13 16:12 K.Prasad
2009-05-14 20:02 ` Alan Stern
2009-05-14 20:08 ` K.Prasad
2009-05-14 20:45 ` K.Prasad
2009-04-24 6:13 [Patch 00/12] Hardware Breakpoint Interfaces K.Prasad
2009-05-04 20:55 ` Alan Stern
2009-05-11 11:36 ` K.Prasad
2009-05-11 14:50 ` Alan Stern
2009-05-11 17:20 ` K.Prasad
2009-05-11 18:09 ` Alan Stern
2009-05-12 14:05 ` K.Prasad
2009-05-12 14:55 ` Alan Stern
2009-05-12 17:12 ` K.Prasad
2009-05-12 20:39 ` Alan Stern
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20090511115142.GA25673@in.ibm.com \
--to=prasad@linux.vnet.ibm.com \
--cc=akpm@linux-foundation.org \
--cc=benh@au1.ibm.com \
--cc=fweisbec@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=maneesh@linux.vnet.ibm.com \
--cc=mhiramat@redhat.com \
--cc=mingo@elte.hu \
--cc=roland@redhat.com \
--cc=rostedt@goodmis.org \
--cc=stern@rowland.harvard.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.