All of lore.kernel.org
 help / color / mirror / Atom feed
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


             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.