From: will.deacon@arm.com (Will Deacon)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH V2 4/4] arm64: disable irq between breakpoint and step exception
Date: Tue, 25 Jul 2017 14:25:51 +0100 [thread overview]
Message-ID: <20170725132551.GB28815@arm.com> (raw)
In-Reply-To: <8f9c3073792c107e3d928e413499572ec75c5175.1499416107.git.panand@redhat.com>
On Fri, Jul 07, 2017 at 05:34:00PM +0530, Pratyush Anand wrote:
> If an interrupt is generated between breakpoint and step handler then
> step handler can not get correct step address. This situation can easily
> be invoked by samples/hw_breakpoint/data_breakpoint.c. It can also be
> reproduced if we insert any printk() statement or dump_stack() in perf
> overflow_handler. So, it seems that perf is working fine just luckily.
> If the CPU which is handling perf breakpoint handler receives any
> interrupt then, perf step handler will not execute sanely.
>
> This patch improves do_debug_exception() handling, which enforces now,
> that exception handler function:
> - should return 0 for any software breakpoint and hw
> breakpoint/watchpoint handler if it does not expect a single step stage
> - should return 1 if it expects single step.
> - A single step handler should always return 0.
> - All handler should return a -ve error in any other case.
>
> Now, we can know in do_debug_exception() that whether a step exception
> will be followed or not. If there will a step exception then disable
> irq. Re-enable it after single step handling.
AFAICT, this is only a problem for kernel-mode breakpoints where we end up
stepping into the interrupt handler when trying to step over a breakpoint.
We'd probably be better off getting all users of kernel step (kprobes, kgdb
and perf) to run the step with irqs disabled, but I still have reservations
about that:
http://lists.infradead.org/pipermail/linux-arm-kernel/2017-May/508066.html
http://lists.infradead.org/pipermail/linux-arm-kernel/2017-June/510814.html
Wouldn't it be better to follow kprobes/kgdb and have perf run the step with
irqs disabled?
Will
WARNING: multiple messages have this Message-ID (diff)
From: Will Deacon <will.deacon@arm.com>
To: Pratyush Anand <panand@redhat.com>
Cc: linux-arm-kernel@lists.infradead.org, mark.rutland@arm.com,
huawei.libin@huawei.com, linux-kernel@vger.kernel.org
Subject: Re: [PATCH V2 4/4] arm64: disable irq between breakpoint and step exception
Date: Tue, 25 Jul 2017 14:25:51 +0100 [thread overview]
Message-ID: <20170725132551.GB28815@arm.com> (raw)
In-Reply-To: <8f9c3073792c107e3d928e413499572ec75c5175.1499416107.git.panand@redhat.com>
On Fri, Jul 07, 2017 at 05:34:00PM +0530, Pratyush Anand wrote:
> If an interrupt is generated between breakpoint and step handler then
> step handler can not get correct step address. This situation can easily
> be invoked by samples/hw_breakpoint/data_breakpoint.c. It can also be
> reproduced if we insert any printk() statement or dump_stack() in perf
> overflow_handler. So, it seems that perf is working fine just luckily.
> If the CPU which is handling perf breakpoint handler receives any
> interrupt then, perf step handler will not execute sanely.
>
> This patch improves do_debug_exception() handling, which enforces now,
> that exception handler function:
> - should return 0 for any software breakpoint and hw
> breakpoint/watchpoint handler if it does not expect a single step stage
> - should return 1 if it expects single step.
> - A single step handler should always return 0.
> - All handler should return a -ve error in any other case.
>
> Now, we can know in do_debug_exception() that whether a step exception
> will be followed or not. If there will a step exception then disable
> irq. Re-enable it after single step handling.
AFAICT, this is only a problem for kernel-mode breakpoints where we end up
stepping into the interrupt handler when trying to step over a breakpoint.
We'd probably be better off getting all users of kernel step (kprobes, kgdb
and perf) to run the step with irqs disabled, but I still have reservations
about that:
http://lists.infradead.org/pipermail/linux-arm-kernel/2017-May/508066.html
http://lists.infradead.org/pipermail/linux-arm-kernel/2017-June/510814.html
Wouldn't it be better to follow kprobes/kgdb and have perf run the step with
irqs disabled?
Will
next prev parent reply other threads:[~2017-07-25 13:25 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-07-07 12:03 [PATCH V2 0/4] ARM64: Fix irq generation between breakpoint and step exception Pratyush Anand
2017-07-07 12:03 ` Pratyush Anand
2017-07-07 12:03 ` [PATCH V2 1/4] hw_breakpoint: Add step_needed event attribute Pratyush Anand
2017-07-07 12:03 ` Pratyush Anand
2017-07-25 13:27 ` Will Deacon
2017-07-25 13:27 ` Will Deacon
2017-07-25 14:14 ` Peter Zijlstra
2017-07-25 14:14 ` Peter Zijlstra
2017-07-25 16:04 ` Mark Rutland
2017-07-25 16:04 ` Mark Rutland
2017-07-26 5:42 ` Pratyush Anand
2017-07-26 5:42 ` Pratyush Anand
2017-07-26 7:49 ` Peter Zijlstra
2017-07-26 7:49 ` Peter Zijlstra
2017-07-07 12:03 ` [PATCH V2 2/4] arm64: use hw_breakpoint_needs_single_step() to decide if step is needed Pratyush Anand
2017-07-07 12:03 ` Pratyush Anand
2017-07-07 12:03 ` [PATCH V2 3/4] hw-breakpoint: sample test: set step_needed bit field Pratyush Anand
2017-07-07 12:03 ` Pratyush Anand
2017-07-07 12:04 ` [PATCH V2 4/4] arm64: disable irq between breakpoint and step exception Pratyush Anand
2017-07-07 12:04 ` Pratyush Anand
2017-07-25 13:25 ` Will Deacon [this message]
2017-07-25 13:25 ` Will Deacon
2017-07-26 5:36 ` Pratyush Anand
2017-07-26 5:36 ` Pratyush Anand
2017-07-17 3:21 ` [PATCH V2 0/4] ARM64: Fix irq generation " Pratyush Anand
2017-07-17 3:21 ` 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=20170725132551.GB28815@arm.com \
--to=will.deacon@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.