[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <47D6CCAA.7020506@redhat.com>
Date: Tue, 11 Mar 2008 14:17:14 -0400
From: Masami Hiramatsu <mhiramat@...hat.com>
To: Shaohua Li <shaohua.li@...el.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 Shaohua,
Shaohua Li wrote:
> 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:
>>> 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.
Sure, it is possible to lose just one probe in that time, but in next time,
we do not lose it. So, I think it is not a problem.
Thanks,
--
Masami Hiramatsu
Software Engineer
Hitachi Computer Products (America) Inc.
Software Solutions Division
e-mail: mhiramat@...hat.com
--
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