public inbox for systemtap@sourceware.org
 help / color / mirror / Atom feed
From: Keshavamurthy Anil S <anil.s.keshavamurthy@intel.com>
To: Masami Hiramatsu <hiramatu@sdl.hitachi.co.jp>
Cc: Keshavamurthy Anil S <anil.s.keshavamurthy@intel.com>,
	        systemtap@sources.redhat.com,
	Yumiko Sugita <sugita@sdl.hitachi.co.jp>,
	        Satoshi Oshima <soshima@redhat.com>,
	Hideo Aoki <haoki@redhat.com>
Subject: Re: [RFC][Patch 2/2][take2]kprobe: kprobe-booster against 2.6.14-mm1 for i386
Date: Tue, 20 Dec 2005 19:38:00 -0000	[thread overview]
Message-ID: <20051220110138.A13946@unix-os.sc.intel.com> (raw)
In-Reply-To: <43A8054A.90901@sdl.hitachi.co.jp>; from hiramatu@sdl.hitachi.co.jp on Tue, Dec 20, 2005 at 10:21:14PM +0900

On Tue, Dec 20, 2005 at 10:21:14PM +0900, Masami Hiramatsu wrote:
> Hi, Anil
> 
> Masami Hiramatsu wrote:
> >>Issue No 1:
> >>	In the above code patch, once you call reset_current_kprobes() and
> >>preempt_enable_no_resched() ( I see preeempt_enable_no_resched()
> >>in your fix to this code), you are not suppose to relay on
> >>&p->ainsn.insn, the reason is that, on the other cpu technically
> >>this memory can get freed due to unregister_kprobe() call.
> >>In other words, by the time this cpu tries to execte the instruction
> >>at regs->eip, that memory might have gone and system is bound to crash.
> > 
> > I think old djprobe has the same issue. So, it will be solved by using
> > safety check routine after removing breakpoint. Current kprobe uses
> > synchronize_sched() for waiting rcu processing in unregister_kprobe().
> > In my opinion, the solution is that introducing safety check same as
> > djprobe instead of synchronize_sched() in unregister_kprobe().
> 
> I found the rcu_barrier() function that works similar to djprobe's
> safety check routine.
> 
> > The safety check routine of djprobe waits until all cpus execute the works,
> > and the works are executed from the keventd.
> 
> The rcu_barrier() function waits until all cpus have gone through a
> quiescent state.
> 
> - The CPU performs a process switch.
> - The CPU starts executing in User Mode.
> - The CPU executes the idle loop
> In each of these cases, We say that the CPU has gone through
> a quiescent state.
> 
> If we call rcu_barrier() after "int3" is removed, we can ensure
> followings after the rcu_barrier() called.
> - interrupt handlers are finished on all CPUs.
> - p->ainsn.insn is not executed on all CPUs.
> And we can remove a boosted kprobe safely.
> 
> Current kprobes uses synchronize_sched(). I think this function
> checks safety of only current CPU. So, it may not ensure above
> conditions. But rcu_barrier() checks safety of all CPUs. So, it
> can ensure above conditions.
> How would you think about this?

You are correct, we need to ensure safety of all CPUs.
rcu_barrier() will work.

> 
> > And also, on preemptible kernel, the booster is not enabled where the
> > kernel preemption is enabled. So, there are no preempted threads on
> > p->ainsn.insn.
Yes, this is also true, you have to disable booster when kernel
preemption is enabled. So in effect booster will work only when
kernel preemption is disabled.


> 
> 
> -- 
> Masami HIRAMATSU
> 2nd Research Dept.
> Hitachi, Ltd., Systems Development Laboratory
> E-mail: hiramatu@sdl.hitachi.co.jp
> 
- Anil

  parent reply	other threads:[~2005-12-20 19:02 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-11-25 13:13 [RFC][Patch 0/2]kprobe: " Masami Hiramatsu
2005-11-25 13:16 ` [RFC][Patch 1/2]kprobe: " Masami Hiramatsu
2005-11-25 13:19   ` [RFC][Patch 2/2]kprobe: " Masami Hiramatsu
2005-11-25 18:39 ` [RFC][Patch 0/2]kprobe: " Frank Ch. Eigler
2005-11-28 14:33   ` Masami Hiramatsu
2005-11-28 15:41     ` Frank Ch. Eigler
2005-11-29 14:14       ` Masami Hiramatsu
2005-11-28 14:29 ` [RFC][Patch 0/2][take2]kprobe: " Masami Hiramatsu
2005-11-28 14:30   ` [RFC][Patch 1/2][take2]kprobe: " Masami Hiramatsu
2005-11-28 14:32     ` [RFC][Patch 2/2][take2]kprobe: " Masami Hiramatsu
2005-12-06  5:27       ` Masami Hiramatsu
2005-12-12 19:49       ` Keshavamurthy Anil S
2005-12-14 14:19         ` Masami Hiramatsu
2005-12-20 13:45           ` Masami Hiramatsu
2005-12-20 17:27             ` Satoshi Oshima
2005-12-20 19:38             ` Keshavamurthy Anil S [this message]
2005-12-21  8:30               ` Ananth N Mavinakayanahalli
2005-12-21 17:39                 ` Masami Hiramatsu
2005-11-28 22:10 ` [RFC][Patch 0/2]kprobe: " Keshavamurthy Anil S
2005-11-29 14:14   ` Masami Hiramatsu
2005-11-30  2:25     ` SMP race [was: kprobe: kprobe-booster against 2.6.14-mm1 for i386] Jim Keniston
2005-12-21 18:11 [RFC][Patch 2/2][take2]kprobe: kprobe-booster against 2.6.14-mm1 for i386 Keshavamurthy, Anil S
2005-12-22  6:07 ` Masami Hiramatsu

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=20051220110138.A13946@unix-os.sc.intel.com \
    --to=anil.s.keshavamurthy@intel.com \
    --cc=haoki@redhat.com \
    --cc=hiramatu@sdl.hitachi.co.jp \
    --cc=soshima@redhat.com \
    --cc=sugita@sdl.hitachi.co.jp \
    --cc=systemtap@sources.redhat.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).