From: masami.hiramatsu.pt@hitachi.com (Masami Hiramatsu)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH RFC 2/6] arm64: Kprobes with single stepping support
Date: Sat, 09 Nov 2013 18:10:52 +0900 [thread overview]
Message-ID: <527DFC1C.1020107@hitachi.com> (raw)
In-Reply-To: <20131108165639.GD15074@mudshark.cambridge.arm.com>
(2013/11/09 1:56), Will Deacon wrote:
> Hi Sandeepa,
>
> On Thu, Oct 17, 2013 at 12:17:47PM +0100, Sandeepa Prabhu wrote:
>> Add support for basic kernel probes(kprobes), jump probes (jprobes)
>> for ARM64.
>
> I think this series will conflict quite heavily with the jump_label series,
> since they both introduce some common instruction manipulation code. On the
> debug side, there will also be conflicts with the kgdb series, so it might
> make sense for us to merge those two first, then you can rebase on a stable
> branch from us.
[...]
> In fact, how do you avoid a race with hardware breakpoints? E.g., somebody
> places a hardware breakpoint on an instruction in the kernel for which
> kprobes has patched in a brk. We take the hardware breakpoint, disable the
> breakpoint and set up a single step before returning to the brk. The brk
> then traps, but we must take care not to disable single-step and/or unmask
> debug exceptions, because that will cause the hardware breakpoint code to
> re-arm its breakpoint before we've stepped off the brk instruction.
Hmm, frankly to say, this kind of race issue is not seriously discussed
on x86 too, since kgdb is still a special tool (not used on the production
system).
I think under such situation kgdb operator must have full control of the
system, and he can (and has to) avoid such kind of race.
Thank you,
--
Masami HIRAMATSU
IT Management Research Dept. Linux Technology Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: masami.hiramatsu.pt at hitachi.com
WARNING: multiple messages have this Message-ID (diff)
From: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
To: Will Deacon <will.deacon@arm.com>
Cc: Sandeepa Prabhu <sandeepa.prabhu@linaro.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"patches@linaro.org" <patches@linaro.org>,
"linaro-kernel@lists.linaro.org" <linaro-kernel@lists.linaro.org>,
Catalin Marinas <Catalin.Marinas@arm.com>,
"steve.capper@linaro.org" <steve.capper@linaro.org>,
"nico@linaro.org" <nico@linaro.org>,
"srikar@linux.vnet.ibm.com" <srikar@linux.vnet.ibm.com>,
"rostedt@goodmis.org" <rostedt@goodmis.org>,
"dsaxena@linaro.org" <dsaxena@linaro.org>,
"jiang.liu@huawei.com" <jiang.liu@huawei.com>,
"Vijaya.Kumar@caviumnetworks.com"
<Vijaya.Kumar@caviumnetworks.com>
Subject: Re: Re: [PATCH RFC 2/6] arm64: Kprobes with single stepping support
Date: Sat, 09 Nov 2013 18:10:52 +0900 [thread overview]
Message-ID: <527DFC1C.1020107@hitachi.com> (raw)
In-Reply-To: <20131108165639.GD15074@mudshark.cambridge.arm.com>
(2013/11/09 1:56), Will Deacon wrote:
> Hi Sandeepa,
>
> On Thu, Oct 17, 2013 at 12:17:47PM +0100, Sandeepa Prabhu wrote:
>> Add support for basic kernel probes(kprobes), jump probes (jprobes)
>> for ARM64.
>
> I think this series will conflict quite heavily with the jump_label series,
> since they both introduce some common instruction manipulation code. On the
> debug side, there will also be conflicts with the kgdb series, so it might
> make sense for us to merge those two first, then you can rebase on a stable
> branch from us.
[...]
> In fact, how do you avoid a race with hardware breakpoints? E.g., somebody
> places a hardware breakpoint on an instruction in the kernel for which
> kprobes has patched in a brk. We take the hardware breakpoint, disable the
> breakpoint and set up a single step before returning to the brk. The brk
> then traps, but we must take care not to disable single-step and/or unmask
> debug exceptions, because that will cause the hardware breakpoint code to
> re-arm its breakpoint before we've stepped off the brk instruction.
Hmm, frankly to say, this kind of race issue is not seriously discussed
on x86 too, since kgdb is still a special tool (not used on the production
system).
I think under such situation kgdb operator must have full control of the
system, and he can (and has to) avoid such kind of race.
Thank you,
--
Masami HIRAMATSU
IT Management Research Dept. Linux Technology Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: masami.hiramatsu.pt@hitachi.com
next prev parent reply other threads:[~2013-11-09 9:10 UTC|newest]
Thread overview: 99+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-10-17 11:17 [PATCH RFC v2 0/6] ARM64: Add kernel probes(Kprobes) support Sandeepa Prabhu
2013-10-17 11:17 ` Sandeepa Prabhu
2013-10-17 11:17 ` [PATCH RFC v4 1/6] arm64: support single-step and breakpoint handler hooks Sandeepa Prabhu
2013-10-17 11:17 ` Sandeepa Prabhu
2013-10-25 15:22 ` Will Deacon
2013-10-25 15:22 ` Will Deacon
2013-12-03 14:33 ` Sandeepa Prabhu
2013-12-03 14:33 ` Sandeepa Prabhu
2013-12-03 19:44 ` Will Deacon
2013-12-03 19:44 ` Will Deacon
2013-10-17 11:17 ` [PATCH RFC 2/6] arm64: Kprobes with single stepping support Sandeepa Prabhu
2013-10-17 11:17 ` Sandeepa Prabhu
2013-11-08 16:56 ` Will Deacon
2013-11-08 16:56 ` Will Deacon
2013-11-09 9:10 ` Masami Hiramatsu [this message]
2013-11-09 9:10 ` Masami Hiramatsu
2013-11-11 5:39 ` Sandeepa Prabhu
2013-11-11 5:39 ` Sandeepa Prabhu
2013-11-11 7:54 ` Masami Hiramatsu
2013-11-11 7:54 ` Masami Hiramatsu
2013-11-11 10:51 ` Masami Hiramatsu
2013-11-11 10:51 ` Masami Hiramatsu
2013-11-11 10:58 ` Will Deacon
2013-11-11 10:58 ` Will Deacon
2013-11-11 17:32 ` Masami Hiramatsu
2013-11-11 17:32 ` Masami Hiramatsu
2013-11-12 6:23 ` Sandeepa Prabhu
2013-11-12 6:23 ` Sandeepa Prabhu
2013-11-12 7:27 ` Masami Hiramatsu
2013-11-12 7:27 ` Re: " Masami Hiramatsu
2013-11-12 8:44 ` Sandeepa Prabhu
2013-11-12 8:44 ` Re: " Sandeepa Prabhu
2013-11-12 10:17 ` Masami Hiramatsu
2013-11-12 10:17 ` Re: Re: " Masami Hiramatsu
2013-11-12 10:55 ` Sandeepa Prabhu
2013-11-12 10:55 ` Re: Re: " Sandeepa Prabhu
2013-11-12 14:11 ` Masami Hiramatsu
2013-11-12 14:11 ` Re: Re: Re: " Masami Hiramatsu
2013-11-12 16:59 ` Steven Rostedt
2013-11-12 16:59 ` Steven Rostedt
2013-11-13 16:05 ` Masami Hiramatsu
2013-11-13 16:05 ` Masami Hiramatsu
2013-11-13 6:55 ` Sandeepa Prabhu
2013-11-13 7:08 ` Sandeepa Prabhu
2013-11-13 7:08 ` Re: " Sandeepa Prabhu
2013-11-13 14:07 ` Masami Hiramatsu
2013-11-13 14:07 ` Re: Re: " Masami Hiramatsu
2013-11-13 14:31 ` Will Deacon
2013-11-13 14:31 ` Re: " Will Deacon
2013-11-13 15:55 ` Sandeepa Prabhu
2013-11-13 15:55 ` Re: " Sandeepa Prabhu
2013-11-15 16:39 ` Will Deacon
2013-11-15 16:39 ` Re: " Will Deacon
2013-11-18 6:55 ` Sandeepa Prabhu
2013-11-18 6:55 ` Re: " Sandeepa Prabhu
2013-11-18 8:51 ` Sandeepa Prabhu
2013-11-18 8:51 ` Re: " Sandeepa Prabhu
2013-11-13 13:58 ` Peter Zijlstra
2013-11-13 13:58 ` Peter Zijlstra
2013-11-13 14:20 ` Will Deacon
2013-11-13 14:20 ` Will Deacon
2013-11-11 5:35 ` Sandeepa Prabhu
2013-11-11 5:35 ` Sandeepa Prabhu
2013-11-11 11:21 ` Will Deacon
2013-11-11 11:21 ` Will Deacon
2013-11-12 6:52 ` Sandeepa Prabhu
2013-11-12 6:52 ` Sandeepa Prabhu
2013-11-15 16:37 ` Will Deacon
2013-11-15 16:37 ` Will Deacon
2013-11-18 6:43 ` Sandeepa Prabhu
2013-11-18 6:43 ` Sandeepa Prabhu
2013-10-17 11:17 ` [PATCH RFC 3/6] arm64: Kprobes instruction simulation support Sandeepa Prabhu
2013-10-17 11:17 ` Sandeepa Prabhu
2013-11-08 17:03 ` Will Deacon
2013-11-08 17:03 ` Will Deacon
2013-11-11 5:58 ` Sandeepa Prabhu
2013-11-11 5:58 ` Sandeepa Prabhu
2013-10-17 11:17 ` [PATCH RFC 4/6] arm64: Add kernel return probes support(kretprobes) Sandeepa Prabhu
2013-10-17 11:17 ` Sandeepa Prabhu
2013-11-08 17:04 ` Will Deacon
2013-11-08 17:04 ` Will Deacon
2013-11-11 4:29 ` Sandeepa Prabhu
2013-11-11 4:29 ` Sandeepa Prabhu
2013-11-11 7:53 ` AKASHI Takahiro
2013-11-11 7:53 ` AKASHI Takahiro
2013-11-11 8:55 ` Sandeepa Prabhu
2013-11-11 8:55 ` Sandeepa Prabhu
2013-10-17 11:17 ` [PATCH RFC 5/6] arm64: Enable kprobes support for arm64 platform Sandeepa Prabhu
2013-10-17 11:17 ` Sandeepa Prabhu
2013-10-17 11:17 ` [PATCH RFC 6/6] kprobes: Add cases for arm and arm64 in sample module Sandeepa Prabhu
2013-10-17 11:17 ` Sandeepa Prabhu
2013-10-25 15:24 ` Will Deacon
2013-10-25 15:24 ` Will Deacon
2013-11-06 11:05 ` Sandeepa Prabhu
2013-11-06 11:05 ` Sandeepa Prabhu
2013-10-18 8:32 ` [PATCH RFC v2 0/6] ARM64: Add kernel probes(Kprobes) support Masami Hiramatsu
2013-10-18 8:32 ` Masami Hiramatsu
2013-10-21 4:17 ` Sandeepa Prabhu
2013-10-21 4:17 ` Sandeepa Prabhu
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=527DFC1C.1020107@hitachi.com \
--to=masami.hiramatsu.pt@hitachi.com \
--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.