Re: [PATCH v6 0/7] ARM: kprobes: enable OPTPROBES for ARM 32.
On Mon, 2014-10-27 at 17:17 +, Jon Medhurst (Tixy) wrote: [...] > The decode table could possibly incorporate patterns to > cover instructions types that you split up in PATCH 1, e.g. so we > might not need separate PROBES_STORE and PROBES_STORE_EXTRA ( Sorry, I got that a bit wrong, the first patch only splits loads and stores and doesn't create create any new 'extra' instruction types. However, my comment could still apply to that split between between loads and stores; for many of them, the difference is just a single bit that is possibly cheap or free to test in the checkers. The reason I am thinking along these lines is that each additional enum value in the instruction types adds an entry into every action and checker table, as well as expanding the decoding tables to detect them. So I just want to make sure that we think these additions result in a net benefit in code size and complexity. -- 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/
Re: [PATCH v6 0/7] ARM: kprobes: enable OPTPROBES for ARM 32.
On Mon, 2014-10-27 at 17:17 +, Jon Medhurst (Tixy) wrote: [...] The decode table could possibly incorporate patterns to cover instructions types that you split up in PATCH 1, e.g. so we might not need separate PROBES_STORE and PROBES_STORE_EXTRA ( Sorry, I got that a bit wrong, the first patch only splits loads and stores and doesn't create create any new 'extra' instruction types. However, my comment could still apply to that split between between loads and stores; for many of them, the difference is just a single bit that is possibly cheap or free to test in the checkers. The reason I am thinking along these lines is that each additional enum value in the instruction types adds an entry into every action and checker table, as well as expanding the decoding tables to detect them. So I just want to make sure that we think these additions result in a net benefit in code size and complexity. -- 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/
Re: [PATCH v6 0/7] ARM: kprobes: enable OPTPROBES for ARM 32.
On Sat, 2014-10-25 at 17:49 +0800, Wang Nan wrote:
[...]
> Anyway, I have done the separation. Please refer to:
>
> http://lists.infradead.org/pipermail/linux-arm-kernel/2014-October/297031.html
> http://lists.infradead.org/pipermail/linux-arm-kernel/2014-October/297036.html
>
> There is a big change in checker code in the first thread. Please help me
> review
> whether checker is acceptable.
I had started reviewing the previous version, I'll switch to the new
one.
I do prefer the new checker code better, and the only obvious
alternative I can think off would be to break down the decoding tables
into a lot more special cases of instruction forms, which I isn't as
scalable, so I don't like that idea.
However, I wonder if there is scope for the checker functions to
recursively call probes_decode_insn rather than decoding instructions in
C code. I don't know if that would be clearer and/or smaller or not.
Below is something I've just thrown together to get a feel of how it
could look. The decode table could possibly incorporate patterns to
cover instructions types that you split up in PATCH 1, e.g. so we might
not need separate PROBES_STORE and PROBES_STORE_EXTRA (depends if that
ends up making things simpler or not)...
int stack_use_none(probes_opcode_t insn,
struct arch_probes_insn *asi,
const struct decode_header *h)
{
asi->stack_space = 0;
return INSN_GOOD_NO_SLOT;
}
int stack_use_unknown(probes_opcode_t insn,
struct arch_probes_insn *asi,
const struct decode_header *h)
{
asi->stack_space = -1;
return INSN_GOOD_NO_SLOT;
}
int stack_use_imm_x0x(probes_opcode_t insn,
struct arch_probes_insn *asi,
const struct decode_header *h)
{
asi->stack_space = ((insn & 0xf00) >> 4) + (insn & 0xf);
return INSN_GOOD_NO_SLOT;
}
int stack_use_imm_xxx(probes_opcode_t insn,
struct arch_probes_insn *asi,
const struct decode_header *h)
{
asi->stack_space = insn & 0xfff;
return INSN_GOOD_NO_SLOT;
}
enum {
STACK_USE_NONE,
STACK_USE_UNKNOWN,
STACK_USE_FIXED_X0X,
STACK_USE_FIXED_XXX,
NUM_STACK_USE_TYPES
};
static const union decode_action chk_stack_actions[] = {
[STACK_USE_NONE] = {.handler = stack_use_none},
[STACK_USE_UNKNOWN] = {.handler = stack_use_unknown},
[STACK_USE_FIXED_X0X] = {.handler = stack_use_imm_x0x}
[STACK_USE_FIXED_XXX] = {.handler = stack_use_imm_xxx}
}
enum probes_insn __kprobes chk_stack_use_arm(probes_opcode_t insn,
struct arch_probes_insn *asi,
const struct decode_header *h)
{
static const union decode_item table[] = {
/* Register indexed addressing modes with SP as index register
(!)*/
DECODE_OR (0x004d, 0x000d),
/* Register indexed addressing modes with SP as base register */
DECODE_CUSTOM (0x004f, 0x000d, STACK_USE_UNKOWN,
REGS(0, 0, 0, 0, 0)),
/* STR{,B} with immediate pre-indexed addressing mode with SP
base address */
DECODE_CUSTOM (0x05cf, 0x054d, STACK_USE_FIXED_XXX,
REGS(0, 0, 0, 0, 0)),
/* STR{H,D} with immediate pre-indexed addressing mode with SP
base address */
DECODE_CUSTOM (0x05cf, 0x014d, STACK_USE_FIXED_X0X,
REGS(0, 0, 0, 0, 0)),
... other rules here, possibly including ...
... REGS values like 'NOSP' to reject certain forms ...
/* Catch all remaining cases */
DECODE_CUSTOM (0, 0, STACK_USE_NONE, REGS(0, 0, 0, 0, 0))
}
return probes_decode_insn(insn, asi, table, false, false,
chk_stack_actions, NULL);
}
And in the dubious case that anyone wants to copy any of the above, it's
Signed-off-by: Jon Medhurst
--
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/
Re: [PATCH v6 0/7] ARM: kprobes: enable OPTPROBES for ARM 32.
On Sat, 2014-10-25 at 17:49 +0800, Wang Nan wrote:
[...]
Anyway, I have done the separation. Please refer to:
http://lists.infradead.org/pipermail/linux-arm-kernel/2014-October/297031.html
http://lists.infradead.org/pipermail/linux-arm-kernel/2014-October/297036.html
There is a big change in checker code in the first thread. Please help me
review
whether checker is acceptable.
I had started reviewing the previous version, I'll switch to the new
one.
I do prefer the new checker code better, and the only obvious
alternative I can think off would be to break down the decoding tables
into a lot more special cases of instruction forms, which I isn't as
scalable, so I don't like that idea.
However, I wonder if there is scope for the checker functions to
recursively call probes_decode_insn rather than decoding instructions in
C code. I don't know if that would be clearer and/or smaller or not.
Below is something I've just thrown together to get a feel of how it
could look. The decode table could possibly incorporate patterns to
cover instructions types that you split up in PATCH 1, e.g. so we might
not need separate PROBES_STORE and PROBES_STORE_EXTRA (depends if that
ends up making things simpler or not)...
int stack_use_none(probes_opcode_t insn,
struct arch_probes_insn *asi,
const struct decode_header *h)
{
asi-stack_space = 0;
return INSN_GOOD_NO_SLOT;
}
int stack_use_unknown(probes_opcode_t insn,
struct arch_probes_insn *asi,
const struct decode_header *h)
{
asi-stack_space = -1;
return INSN_GOOD_NO_SLOT;
}
int stack_use_imm_x0x(probes_opcode_t insn,
struct arch_probes_insn *asi,
const struct decode_header *h)
{
asi-stack_space = ((insn 0xf00) 4) + (insn 0xf);
return INSN_GOOD_NO_SLOT;
}
int stack_use_imm_xxx(probes_opcode_t insn,
struct arch_probes_insn *asi,
const struct decode_header *h)
{
asi-stack_space = insn 0xfff;
return INSN_GOOD_NO_SLOT;
}
enum {
STACK_USE_NONE,
STACK_USE_UNKNOWN,
STACK_USE_FIXED_X0X,
STACK_USE_FIXED_XXX,
NUM_STACK_USE_TYPES
};
static const union decode_action chk_stack_actions[] = {
[STACK_USE_NONE] = {.handler = stack_use_none},
[STACK_USE_UNKNOWN] = {.handler = stack_use_unknown},
[STACK_USE_FIXED_X0X] = {.handler = stack_use_imm_x0x}
[STACK_USE_FIXED_XXX] = {.handler = stack_use_imm_xxx}
}
enum probes_insn __kprobes chk_stack_use_arm(probes_opcode_t insn,
struct arch_probes_insn *asi,
const struct decode_header *h)
{
static const union decode_item table[] = {
/* Register indexed addressing modes with SP as index register
(!)*/
DECODE_OR (0x004d, 0x000d),
/* Register indexed addressing modes with SP as base register */
DECODE_CUSTOM (0x004f, 0x000d, STACK_USE_UNKOWN,
REGS(0, 0, 0, 0, 0)),
/* STR{,B} with immediate pre-indexed addressing mode with SP
base address */
DECODE_CUSTOM (0x05cf, 0x054d, STACK_USE_FIXED_XXX,
REGS(0, 0, 0, 0, 0)),
/* STR{H,D} with immediate pre-indexed addressing mode with SP
base address */
DECODE_CUSTOM (0x05cf, 0x014d, STACK_USE_FIXED_X0X,
REGS(0, 0, 0, 0, 0)),
... other rules here, possibly including ...
... REGS values like 'NOSP' to reject certain forms ...
/* Catch all remaining cases */
DECODE_CUSTOM (0, 0, STACK_USE_NONE, REGS(0, 0, 0, 0, 0))
}
return probes_decode_insn(insn, asi, table, false, false,
chk_stack_actions, NULL);
}
And in the dubious case that anyone wants to copy any of the above, it's
Signed-off-by: Jon Medhurst t...@linaro.org
--
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/
Re: [PATCH v6 0/7] ARM: kprobes: enable OPTPROBES for ARM 32.
On 2014/10/24 17:02, Jon Medhurst (Tixy) wrote: > 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. > Anyway, I have done the separation. Please refer to: http://lists.infradead.org/pipermail/linux-arm-kernel/2014-October/297031.html http://lists.infradead.org/pipermail/linux-arm-kernel/2014-October/297036.html There is a big change in checker code in the first thread. Please help me review whether checker is acceptable. The next thing I'll do is to create another checker table to check whether the probed insn can be directly executed as in x86_64. Thanks. -- 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/
Re: [PATCH v6 0/7] ARM: kprobes: enable OPTPROBES for ARM 32.
On 2014/10/24 17:02, Jon Medhurst (Tixy) wrote: 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. Anyway, I have done the separation. Please refer to: http://lists.infradead.org/pipermail/linux-arm-kernel/2014-October/297031.html http://lists.infradead.org/pipermail/linux-arm-kernel/2014-October/297036.html There is a big change in checker code in the first thread. Please help me review whether checker is acceptable. The next thing I'll do is to create another checker table to check whether the probed insn can be directly executed as in x86_64. Thanks. -- 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/
Re: [PATCH v6 0/7] ARM: kprobes: enable OPTPROBES for ARM 32.
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/
Re: [PATCH v6 0/7] ARM: kprobes: enable OPTPROBES for ARM 32.
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/
Re: [PATCH v6 0/7] ARM: kprobes: enable OPTPROBES for ARM 32.
(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. Thank you, -- Masami HIRAMATSU Software Platform Research Dept. Linux Technology Research Center Hitachi, Ltd., Yokohama Research Laboratory E-mail: masami.hiramatsu...@hitachi.com -- 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/
Re: [PATCH v6 0/7] ARM: kprobes: enable OPTPROBES for ARM 32.
(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. Thank you, -- Masami HIRAMATSU Software Platform Research Dept. Linux Technology Research Center Hitachi, Ltd., Yokohama Research Laboratory E-mail: masami.hiramatsu...@hitachi.com -- 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/
[PATCH v6 0/7] ARM: kprobes: enable OPTPROBES for ARM 32.
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. 2. In patch 7/7, stack protection code now is generated according to the instruction be optimized. 3. In patch 7/7, kprobes-opt.c is renamed to kprobes-opt-arm.c due to it only deal with ARM case. 4. Bug in v5 is fixed. Wang Nan (7): ARM: kprobes: replace 'union decode_action' to 'struct decode_action' ARM: kprobes: seprates load and store actions ARM: kprobes: introduces checker ARM: kprobes: collects stack consumption for store instructions ARM: kprobes: disallow probing stack consuming instructions kprobes: copy ainsn after alloc aggr kprobe ARM: kprobes: enable OPTPROBES for ARM 32 arch/arm/Kconfig | 1 + arch/arm/include/asm/kprobes.h | 26 arch/arm/include/asm/probes.h| 1 + arch/arm/kernel/Makefile | 3 +- arch/arm/kernel/kprobes-arm.c| 12 +- arch/arm/kernel/kprobes-opt-arm.c| 285 +++ arch/arm/kernel/kprobes-test-arm.c | 17 ++- arch/arm/kernel/kprobes-test-thumb.c | 13 ++ arch/arm/kernel/kprobes-thumb.c | 24 +-- arch/arm/kernel/kprobes.c| 10 +- arch/arm/kernel/kprobes.h| 8 +- arch/arm/kernel/probes-arm.c | 32 +++- arch/arm/kernel/probes-arm.h | 15 +- arch/arm/kernel/probes-thumb.c | 152 --- arch/arm/kernel/probes-thumb.h | 31 +++- arch/arm/kernel/probes.c | 76 +- arch/arm/kernel/probes.h | 27 +++- arch/arm/kernel/uprobes-arm.c| 12 +- arch/arm/kernel/uprobes.h| 2 +- kernel/kprobes.c | 6 + 20 files changed, 679 insertions(+), 74 deletions(-) create mode 100644 arch/arm/kernel/kprobes-opt-arm.c -- 1.8.4 -- 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/
[PATCH v6 0/7] ARM: kprobes: enable OPTPROBES for ARM 32.
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. 2. In patch 7/7, stack protection code now is generated according to the instruction be optimized. 3. In patch 7/7, kprobes-opt.c is renamed to kprobes-opt-arm.c due to it only deal with ARM case. 4. Bug in v5 is fixed. Wang Nan (7): ARM: kprobes: replace 'union decode_action' to 'struct decode_action' ARM: kprobes: seprates load and store actions ARM: kprobes: introduces checker ARM: kprobes: collects stack consumption for store instructions ARM: kprobes: disallow probing stack consuming instructions kprobes: copy ainsn after alloc aggr kprobe ARM: kprobes: enable OPTPROBES for ARM 32 arch/arm/Kconfig | 1 + arch/arm/include/asm/kprobes.h | 26 arch/arm/include/asm/probes.h| 1 + arch/arm/kernel/Makefile | 3 +- arch/arm/kernel/kprobes-arm.c| 12 +- arch/arm/kernel/kprobes-opt-arm.c| 285 +++ arch/arm/kernel/kprobes-test-arm.c | 17 ++- arch/arm/kernel/kprobes-test-thumb.c | 13 ++ arch/arm/kernel/kprobes-thumb.c | 24 +-- arch/arm/kernel/kprobes.c| 10 +- arch/arm/kernel/kprobes.h| 8 +- arch/arm/kernel/probes-arm.c | 32 +++- arch/arm/kernel/probes-arm.h | 15 +- arch/arm/kernel/probes-thumb.c | 152 --- arch/arm/kernel/probes-thumb.h | 31 +++- arch/arm/kernel/probes.c | 76 +- arch/arm/kernel/probes.h | 27 +++- arch/arm/kernel/uprobes-arm.c| 12 +- arch/arm/kernel/uprobes.h| 2 +- kernel/kprobes.c | 6 + 20 files changed, 679 insertions(+), 74 deletions(-) create mode 100644 arch/arm/kernel/kprobes-opt-arm.c -- 1.8.4 -- 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/
