On Fri, 2014-10-24 at 09:52 +0900, Masami Hiramatsu wrote: > (2014/10/22 20:31), Wang Nan wrote: > > Previous 5 version of ARM OPTPROBES patches are unable to deal with > > stack storing instructions correctly. V5 patches disallow optimizing > > every protential stack store instructions based on pessimistic > > assumption. Which, as Tixy comments, 'excludes the main use of > > kprobes'. (https://lkml.org/lkml/2014/8/29/117 ) > > > > The main obstacle which prevents us from computing stack requirement is > > the missing of per-instruction decoder in probes_decode_insn() and its > > friends. Only part of instructions have their decoders (and not in > > each case). > > > > In this patch series, I propose 'checker', which allows us define > > functions for each type of instruction, extract more information. Stack > > consumption computing is an example. Checker can be further employed to > > determine whether one instruction is possible to execute directy in > > optimized kprobe. I'd like to expand current checker framework by > > chaining checkers together. After that, I believe most of ARM > > instructions can be executed directly like x86, kprobe performace can be > > improved. > > > > The first 3 patches introduces checker. After that, patch 4/7 checks > > stack requirement for probed instructions. Patches 5/7 - 7/7 are similar > > to patch v5, except: > > > > 1. As Tixy proposed, unoptimized probes are also suffer from stack > > problem (https://lkml.org/lkml/2014/9/1/548 ). Commit d30a0c8b saves > > 64 bytes for them, but for instruction use register addressing (like > > 'str r0, [sp, r1]'), 64 bytes are unsafe. Patch 5/7 prohibit such > > probing according to stack information collected by checker. > > By the way, this sounds like a bugfix rather than an improvement. > Is it possible to separate 1/7-5/7 as a bugfix series? I think those > should go to 3.18.
I believe that problem has existed since kprobes was first implemented on ARM 7 years ago, and the problematic instruction type doesn't appear to get generated by GCC so, in my opinion, I don't think there is any particular urgency to fix this as a bug in the current and, by implication, stable kernels. -- Tixy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/