[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4E0DB6FC.20904@hitachi.com>
Date: Fri, 01 Jul 2011 21:01:00 +0900
From: Masami Hiramatsu <masami.hiramatsu.pt@...achi.com>
To: ananth@...ibm.com
Cc: Steven Rostedt <rostedt@...dmis.org>,
LKML <linux-kernel@...r.kernel.org>,
Peter Zijlstra <a.p.zijlstra@...llo.nl>,
Frederic Weisbecker <fweisbec@...il.com>,
Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...e.hu>, yrl.pp-manager.tt@...achi.com
Subject: Re: [BUG] kprobes crashing because of preempt count
(2011/07/01 20:36), Ananth N Mavinakayanahalli wrote:
> On Fri, Jul 01, 2011 at 10:12:03AM +0900, Masami Hiramatsu wrote:
>> (2011/06/30 22:23), Steven Rostedt wrote:
>
> ...
>
>>> Do we really need to have preemption disabled throughout this? Is it
>>> because we don't want to migrate or call schedule? Not sure what the
>>> best way to fix this is. Perhaps we add a kprobe_preempt_disable() that
>>> is checked as well?
>>
>> I think the best way to do that is just removing preemption disabling
>> code, because
>> - breakpoint exception itself disables interrupt (at least on x86)
>> - While single stepping, interrupts also be disabled.
>
> On 64-bit powerpc, kprobe handlers are run with interrupts enabled
> (MSR_EE = 1), but most instructions (including loads/stores) are
> emulated, so for the most part, we don't take the sstep exception.
Yeah, it seems that same thing is done on arm too. And I'm sure that
However, I'm still not sure that entire int3 exec path can run without
calling inc_preempt_count.
It seems that the function is very primitive, and I doubt we can
allow to put kprobes on that...
Thank you,
>
> Ananth
--
Masami HIRAMATSU
Software Platform Research Dept. Linux Technology Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: masami.hiramatsu.pt@...achi.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