From: mhiramat@kernel.org (Masami Hiramatsu)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v4] arm64: Improve kprobes test for atomic sequence
Date: Thu, 15 Sep 2016 13:31:33 +0900 [thread overview]
Message-ID: <20160915133133.950de3aeafdec36c25be4e00@kernel.org> (raw)
In-Reply-To: <57D7515C.30704@linaro.org>
On Mon, 12 Sep 2016 21:07:40 -0400
David Long <dave.long@linaro.org> wrote:
>
> After the patch the function reads as follows:
>
> > enum kprobe_insn __kprobes
> > arm_kprobe_decode_insn(kprobe_opcode_t *addr, struct arch_specific_insn *asi)
> > {
> > enum kprobe_insn decoded;
> > kprobe_opcode_t insn = le32_to_cpu(*addr);
> > kprobe_opcode_t *scan_end = NULL;
> > unsigned long size = 0, offset = 0;
> >
> > /*
> > * If there's a symbol defined in front of and near enough to
> > * the probe address assume it is the entry point to this
> > * code and use it to further limit how far back we search
> > * when determining if we're in an atomic sequence. If we could
> > * not find any symbol skip the atomic test altogether as we
> > * could otherwise end up searching irrelevant text/literals.
> > * KPROBES depends on KALLSYMS so this last case should never
> > * happen.
> > */
> > if (kallsyms_lookup_size_offset((unsigned long) addr, &size, &offset)) {
> > if (offset < (MAX_ATOMIC_CONTEXT_SIZE*sizeof(kprobe_opcode_t)))
> > scan_end = addr - (offset / sizeof(kprobe_opcode_t));
> > else
> > scan_end = addr - MAX_ATOMIC_CONTEXT_SIZE;
> > }
> > decoded = arm_probe_decode_insn(insn, asi);
> >
> > if (decoded != INSN_REJECTED && scan_end)
> > if (is_probed_address_atomic(addr - 1, scan_end))
> > return INSN_REJECTED;
> >
> > return decoded;
> > }
>
> A failed kallsyms_lookup_size_offset() call means scan_end will be left
> as NULL, which in turn means arm_kprobe_decode_insn() will simply return
> the result of the arm_probe_decode_insn() call. In other words it does
> the normal analysis of the instruction to be probed, but does not do the
> atomic sequence search that normally follows that (since it doesn't
> really know how far back to search).
OK, my idea was just rejecting it when kallsyms_lookup_size_offset() is
failed, because we can not ensure that the address is in the kernel
text. But anyway, that should be tested in general code like kernel/kprobes.c.
OK, now I think it is clear to apply.
Acked-by: Masami Hiramatsu <mhiramat@kernel.org>
Thanks,
>
> Thanks,
> -dl
>
--
Masami Hiramatsu <mhiramat@kernel.org>
WARNING: multiple messages have this Message-ID (diff)
From: Masami Hiramatsu <mhiramat@kernel.org>
To: David Long <dave.long@linaro.org>
Cc: Ananth N Mavinakayanahalli <ananth@linux.vnet.ibm.com>,
Anil S Keshavamurthy <anil.s.keshavamurthy@intel.com>,
"David S. Miller" <davem@davemloft.net>,
Will Deacon <will.deacon@arm.com>,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, catalin.marinas@arm.com,
Sandeepa Prabhu <sandeepa.s.prabhu@gmail.com>,
William Cohen <wcohen@redhat.com>,
Pratyush Anand <panand@redhat.com>,
Mark Brown <broonie@kernel.org>
Subject: Re: [PATCH v4] arm64: Improve kprobes test for atomic sequence
Date: Thu, 15 Sep 2016 13:31:33 +0900 [thread overview]
Message-ID: <20160915133133.950de3aeafdec36c25be4e00@kernel.org> (raw)
In-Reply-To: <57D7515C.30704@linaro.org>
On Mon, 12 Sep 2016 21:07:40 -0400
David Long <dave.long@linaro.org> wrote:
>
> After the patch the function reads as follows:
>
> > enum kprobe_insn __kprobes
> > arm_kprobe_decode_insn(kprobe_opcode_t *addr, struct arch_specific_insn *asi)
> > {
> > enum kprobe_insn decoded;
> > kprobe_opcode_t insn = le32_to_cpu(*addr);
> > kprobe_opcode_t *scan_end = NULL;
> > unsigned long size = 0, offset = 0;
> >
> > /*
> > * If there's a symbol defined in front of and near enough to
> > * the probe address assume it is the entry point to this
> > * code and use it to further limit how far back we search
> > * when determining if we're in an atomic sequence. If we could
> > * not find any symbol skip the atomic test altogether as we
> > * could otherwise end up searching irrelevant text/literals.
> > * KPROBES depends on KALLSYMS so this last case should never
> > * happen.
> > */
> > if (kallsyms_lookup_size_offset((unsigned long) addr, &size, &offset)) {
> > if (offset < (MAX_ATOMIC_CONTEXT_SIZE*sizeof(kprobe_opcode_t)))
> > scan_end = addr - (offset / sizeof(kprobe_opcode_t));
> > else
> > scan_end = addr - MAX_ATOMIC_CONTEXT_SIZE;
> > }
> > decoded = arm_probe_decode_insn(insn, asi);
> >
> > if (decoded != INSN_REJECTED && scan_end)
> > if (is_probed_address_atomic(addr - 1, scan_end))
> > return INSN_REJECTED;
> >
> > return decoded;
> > }
>
> A failed kallsyms_lookup_size_offset() call means scan_end will be left
> as NULL, which in turn means arm_kprobe_decode_insn() will simply return
> the result of the arm_probe_decode_insn() call. In other words it does
> the normal analysis of the instruction to be probed, but does not do the
> atomic sequence search that normally follows that (since it doesn't
> really know how far back to search).
OK, my idea was just rejecting it when kallsyms_lookup_size_offset() is
failed, because we can not ensure that the address is in the kernel
text. But anyway, that should be tested in general code like kernel/kprobes.c.
OK, now I think it is clear to apply.
Acked-by: Masami Hiramatsu <mhiramat@kernel.org>
Thanks,
>
> Thanks,
> -dl
>
--
Masami Hiramatsu <mhiramat@kernel.org>
next prev parent reply other threads:[~2016-09-15 4:31 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-09-12 18:21 [PATCH v4] arm64: Improve kprobes test for atomic sequence David Long
2016-09-12 18:21 ` David Long
2016-09-13 0:46 ` Masami Hiramatsu
2016-09-13 0:46 ` Masami Hiramatsu
2016-09-13 1:07 ` David Long
2016-09-13 1:07 ` David Long
2016-09-15 4:31 ` Masami Hiramatsu [this message]
2016-09-15 4:31 ` Masami Hiramatsu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160915133133.950de3aeafdec36c25be4e00@kernel.org \
--to=mhiramat@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.