[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <566AF556.6050704@redhat.com>
Date: Fri, 11 Dec 2015 11:09:58 -0500
From: William Cohen <wcohen@...hat.com>
To: David Long <dave.long@...aro.org>,
"Jon Medhurst (Tixy)" <tixy@...aro.org>,
masami.hiramatsu.pt@...achi.com,
Ananth N Mavinakayanahalli <ananth@...ibm.com>,
anil.s.keshavamurthy@...el.com, davem@...emloft.net,
Steve Capper <steve.capper@...aro.org>, will.deacon@....com
Cc: "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>,
Sandeepa Prabhu <sandeepa.s.prabhu@...il.com>,
Pratyush Anand <panand@...hat.com>
Subject: Re: [RFC] kprobe'ing conditionally executed instructions
On 12/11/2015 12:05 AM, David Long wrote:
> There is a moderate amount of code already in kprobes on ARM and the current ARMv8 patch to deal with conditional execution of instructions. One aspect of how this is handled is that instructions that fail their predicate and are not (technically) executed are also not treated as a hit kprobe. Steve Capper has suggested that the probe handling should still take place because we stepped through the instruction even if it was effectively a nop. This would be a significant change in how it currently works on 32-bit ARM, and a change in the patch for ARMv8 (although it's not likely to be much of a change in the kernel code).
>
> I need input on this. Do people have opinions?
>
> -dl
>
Hi Dave,
Conditionally executing the kprobes would violate the assumptions made for perf and systemtap collecting data. Even if the instruction is predicated and treated as a NOP it should still reliably trigger the kprobe. However, for efficiency the simulation/emulation/single-step of the instruction could be skipped if the instruction is known to have no change on the machine state other than changing the program counter.
-Will Cohen
--
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