[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1205198417.24178.10.camel@sli10-desk.sh.intel.com>
Date: Tue, 11 Mar 2008 09:20:17 +0800
From: Shaohua Li <shaohua.li@...el.com>
To: Masami Hiramatsu <mhiramat@...hat.com>
Cc: Andrew Morton <akpm@...ux-foundation.org>,
LKML <linux-kernel@...r.kernel.org>,
ia64 <linux-ia64@...r.kernel.org>,
"Luck, Tony" <tony.luck@...el.com>,
Ananth N Mavinakayanahalli <ananth@...ibm.com>,
Jim Keniston <jkenisto@...ibm.com>,
systemtap-ml <systemtap@...rces.redhat.com>
Subject: Re: [PATCH -mm] kprobes: kprobe-booster for ia64
Hi,
On Tue, 2008-03-11 at 02:25 +0800, Masami Hiramatsu wrote:
> Shaohua Li wrote:
> > On Sat, 2008-03-08 at 00:01 +0800, Masami Hiramatsu wrote:
> >> From: Masami Hiramatsu <mhiramat@...hat.com>
> >> +
> >> +/* Prepare long jump bundle and disables other boosters if need */
> >> +static void __kprobes prepare_booster(struct kprobe *p)
> >> +{
> >> + unsigned long addr = (unsigned long)p->addr & ~0xFULL;
> >> + unsigned int slot = addr & 0xf;
> > slot = (unsigned long)p->addr & 0xf ?
>
> You are correct. I'll fix that.
>
> >
> >> + struct kprobe *other_kp;
> >> +
> >> + if (can_boost(&p->ainsn.insn[0].bundle, slot, addr)) {
> >> + set_brl_inst(&p->ainsn.insn[1].bundle, (bundle_t
> >> *)addr + 1);
> >> + p->ainsn.inst_flag |= INST_FLAG_BOOSTABLE;
> >> + }
> >> +
> >> + /* disables boosters in previous slots */
> >> + for (; addr < (unsigned long)p->addr; addr++) {
> >> + other_kp = get_kprobe((void *)addr);
> >> + if (other_kp)
> >> + other_kp->ainsn.inst_flag &=
> >> ~INST_FLAG_BOOSTABLE;
> >> + }
> >> +}
> >> +
> > There is no lock to protect the flag. If one cpu invokes other_kp
> and
> > the other cpu is changing the flag, what's the result?
>
> I think that other cpu never change the flag, because the caller of
> this
> function(__register_kprobe) locks kprobe_mutex in kernel/kprobes.c.
I mean if one cpu is doing register_kprobe, which will change other_kp's
flag. Another cpu is running into other_kp's break point, which will
look at the flag, there is a window (between the second cpu looks at the
flag and doing boost) the first cpu can change the flag in the window.
It appears we will lose one probe, but not sure if this is over
thinking.
Thanks,
Shaohua
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists