From: james.morse@arm.com (James Morse)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v3 0/5] ARM64: disable irq between breakpoint and step exception
Date: Mon, 31 Jul 2017 18:15:41 +0100 [thread overview]
Message-ID: <597F65BD.3070200@arm.com> (raw)
In-Reply-To: <cover.1501496603.git.panand@redhat.com>
Hi Pratyush,
On 31/07/17 11:40, Pratyush Anand wrote:
> samples/hw_breakpoint/data_breakpoint.c passes with x86_64 but fails with
> ARM64. Even though it has been NAKed previously on upstream [1, 2], I have
> tried to come up with patches which can resolve it for ARM64 as well.
>
> I noticed that even perf step exception can go into an infinite loop if CPU
> receives an interrupt while executing breakpoint/watchpoint handler. So,
> event though we are not concerned about above test, we will have to find a
> solution for the perf issue.
This caught my eye as I've been reworking the order the DAIF flags get
set/cleared[0].
What causes your infinite loop? Is it single-stepping kernel_exit? If so patch 4
"arm64: entry.S mask all exceptions during kernel_exit" [1] may help.
If its more like "single stepping something we didn't expect" you will get the
same problem if we take an SError. (which with that series is unmasked ~all the
time).
Either way this looks like a new and exciting way of hitting the 'known issue'
described in patch 12 [3].
Would disabling MDSCR_EL1.SS if we took an exception solve your problem?
If so, I think we should add a new flag, 'TIF_KSINGLESTEP', causing us to
save/restore MDSCR_EL1.SS into pt_regs on el1 exceptions. This would let us
single-step without modifying the DAIF flags for the location we are stepping,
and allow taking any kind of exception from that location.
We should disable nested users of single-step, we can do that by testing the
flag, print a warning then pretend we missed the breakpoint. (hence it needs to
be separate from the user single-step flag).
Thanks,
James
[0] https://www.spinics.net/lists/arm-kernel/msg596684.html
[1] https://www.spinics.net/lists/arm-kernel/msg596686.html
[2] https://www.spinics.net/lists/arm-kernel/msg596689.html
WARNING: multiple messages have this Message-ID (diff)
From: James Morse <james.morse@arm.com>
To: Pratyush Anand <panand@redhat.com>
Cc: linux-arm-kernel@lists.infradead.org, mark.rutland@arm.com,
will.deacon@arm.com, huawei.libin@huawei.com,
takahiro.akashi@linaro.org,
Alexander Shishkin <alexander.shishkin@linux.intel.com>,
Arnaldo Carvalho de Melo <acme@kernel.org>,
Ingo Molnar <mingo@redhat.com>,
linux-kernel@vger.kernel.org,
Peter Zijlstra <peterz@infradead.org>
Subject: Re: [PATCH v3 0/5] ARM64: disable irq between breakpoint and step exception
Date: Mon, 31 Jul 2017 18:15:41 +0100 [thread overview]
Message-ID: <597F65BD.3070200@arm.com> (raw)
In-Reply-To: <cover.1501496603.git.panand@redhat.com>
Hi Pratyush,
On 31/07/17 11:40, Pratyush Anand wrote:
> samples/hw_breakpoint/data_breakpoint.c passes with x86_64 but fails with
> ARM64. Even though it has been NAKed previously on upstream [1, 2], I have
> tried to come up with patches which can resolve it for ARM64 as well.
>
> I noticed that even perf step exception can go into an infinite loop if CPU
> receives an interrupt while executing breakpoint/watchpoint handler. So,
> event though we are not concerned about above test, we will have to find a
> solution for the perf issue.
This caught my eye as I've been reworking the order the DAIF flags get
set/cleared[0].
What causes your infinite loop? Is it single-stepping kernel_exit? If so patch 4
"arm64: entry.S mask all exceptions during kernel_exit" [1] may help.
If its more like "single stepping something we didn't expect" you will get the
same problem if we take an SError. (which with that series is unmasked ~all the
time).
Either way this looks like a new and exciting way of hitting the 'known issue'
described in patch 12 [3].
Would disabling MDSCR_EL1.SS if we took an exception solve your problem?
If so, I think we should add a new flag, 'TIF_KSINGLESTEP', causing us to
save/restore MDSCR_EL1.SS into pt_regs on el1 exceptions. This would let us
single-step without modifying the DAIF flags for the location we are stepping,
and allow taking any kind of exception from that location.
We should disable nested users of single-step, we can do that by testing the
flag, print a warning then pretend we missed the breakpoint. (hence it needs to
be separate from the user single-step flag).
Thanks,
James
[0] https://www.spinics.net/lists/arm-kernel/msg596684.html
[1] https://www.spinics.net/lists/arm-kernel/msg596686.html
[2] https://www.spinics.net/lists/arm-kernel/msg596689.html
next prev parent reply other threads:[~2017-07-31 17:15 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-07-31 10:40 [PATCH v3 0/5] ARM64: disable irq between breakpoint and step exception Pratyush Anand
2017-07-31 10:40 ` Pratyush Anand
2017-07-31 10:40 ` [PATCH v3 1/5] hw_breakpoint: Add step_needed event attribute Pratyush Anand
2017-07-31 10:40 ` Pratyush Anand
2017-08-01 8:18 ` Peter Zijlstra
2017-08-01 8:18 ` Peter Zijlstra
2017-07-31 10:40 ` [PATCH v3 2/5] arm64: use hw_breakpoint_needs_single_step() to decide if step is needed Pratyush Anand
2017-07-31 10:40 ` Pratyush Anand
2017-07-31 10:40 ` [PATCH v3 3/5] register_wide_hw_breakpoint(): modify to accept step_needed arg Pratyush Anand
2017-07-31 10:40 ` Pratyush Anand
2017-07-31 10:40 ` [PATCH v3 4/5] arm64: disable irq between breakpoint and step exception Pratyush Anand
2017-07-31 10:40 ` Pratyush Anand
2017-07-31 10:40 ` [PATCH v3 5/5] arm64: fault: re-enable irq if it was disabled for single stepping Pratyush Anand
2017-07-31 10:40 ` Pratyush Anand
2017-07-31 17:15 ` James Morse [this message]
2017-07-31 17:15 ` [PATCH v3 0/5] ARM64: disable irq between breakpoint and step exception James Morse
2017-08-01 4:18 ` Pratyush Anand
2017-08-01 4:18 ` Pratyush Anand
2017-08-02 17:13 ` James Morse
2017-08-02 17:13 ` James Morse
2017-08-02 18:46 ` Pratyush Anand
2017-08-02 18:46 ` Pratyush Anand
2017-08-03 15:25 ` James Morse
2017-08-03 15:25 ` James Morse
2017-08-01 8:14 ` AKASHI Takahiro
2017-08-01 8:14 ` AKASHI Takahiro
2017-08-01 8:32 ` Pratyush Anand
2017-08-01 8:32 ` Pratyush Anand
2017-08-25 6:05 ` Pratyush Anand
2017-08-25 6:05 ` Pratyush Anand
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=597F65BD.3070200@arm.com \
--to=james.morse@arm.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.