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
next prev 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).