On Tue, 2013-10-15 at 17:04 -0400, David Long wrote:
> From: "David A. Long" <[email protected]>
>
> Instead of depending on include/asm/kprobes.h to provide a dummy definition
> for struct arch_specific_insn, do so in include/linux/kprobes.h.
That change description doesn't quite seem to quite make sense to me.
Anyway, what we're trying to do with this patch is to allow us to use
arch_specific_insn for purposes additional to implementing kprobes. This
patch enables that but I'm wary that the kprobes code assumes that ainsn
is a struct arch_specific_insn, e.g. in linux/kernel/kprobes.c we have:
memcpy(&p->ainsn, &ap->ainsn, sizeof(struct arch_specific_insn));
Now, that code isn't compiled when kprobes isn't configured, but it
seams to me to be safer if that was also changed to
memcpy(&p->ainsn, &ap->ainsn, sizeof(p->ainsn));
However, I also wonder if we should instead leave arch_specific_insn as
a kprobes specific structure and on ARM define it in terms of a new more
generic 'struct probe_insn'? The drawback with that is that we'd
probably end up with a struct just containing a single member which
seems a bit redundant:
struct arch_specific_insn {
struct probe_insn pinsn;
};
Thought's anyone?
>
> Signed-off-by: David A. Long <[email protected]>
> ---
> include/linux/kprobes.h | 7 ++++---
> 1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/include/linux/kprobes.h b/include/linux/kprobes.h
> index 925eaf2..4b5a74d 100644
> --- a/include/linux/kprobes.h
> +++ b/include/linux/kprobes.h
> @@ -52,9 +52,6 @@
>
> #else /* CONFIG_KPROBES */
> typedef int kprobe_opcode_t;
> -struct arch_specific_insn {
> - int dummy;
> -};
> #endif /* CONFIG_KPROBES */
>
> struct kprobe;
> @@ -110,7 +107,11 @@ struct kprobe {
> kprobe_opcode_t opcode;
>
> /* copy of the original instruction */
> +#ifdef CONFIG_KPROBES
> struct arch_specific_insn ainsn;
> +#else
> + int ainsn;
> +#endif
>
> /*
> * Indicates various status flags.
--
Tixy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
