From: Jean-Philippe Brucker <jean-philippe@linaro.org>
To: Will Deacon <will@kernel.org>
Cc: catalin.marinas@arm.com, Masami Hiramatsu <mhiramat@kernel.org>,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH] arm64: kprobes: Use BRK instead of single-step when executing instructions out-of-line
Date: Tue, 17 Nov 2020 18:28:12 +0100 [thread overview]
Message-ID: <20201117172812.GA551957@myrica> (raw)
In-Reply-To: <20201103092315.GC4403@willie-the-truck>
On Tue, Nov 03, 2020 at 09:23:16AM +0000, Will Deacon wrote:
> Yes, let's just set all of DAIF during the trampoline. Also, while I've got
> you, If you get a chance, I'd appreciate any feedback on my proposal for
> reworking our debug exception handling altogether:
>
> https://lore.kernel.org/r/20200626095551.GA9312@willie-the-truck
Well, I stared at this for a while... It looks fine to me, but I don't
have a full picture of the trap infrastructure (not sure whether you were
asking me). I could help with testing if you get around to reworking it.
> On taking an interrupt from EL1, stash MDSCR_EL1.SS in a pcpu variable and
> clear the register bit if it was set. Then unmask only D and leave I set. On
> return from the exception, set D and restore MDSCR_EL1.SS. If we decide to
> reschedule, unmask D (i.e. we only step into interrupts if we need a
> reschedule. Alternatively, we could skip the reschedule if we were
> stepping.)
Any specific reason to treat reschedule differently, or just to keep
things simple? I'm asking because that could be a problem with the
current code: when taking an interrupt while stepping EL1, we keep
MDSCR_EL1.SS set and unmask D before calling the IRQ handler. The step
exception might only be taken after the next context synchronization event
(on QEMU it happens at an isb in the timer handler). If the IRQ handler
doesn't happen to do any context synchronization and we reschedule, I
guess the step exception could happen after the next eret?
Thanks,
Jean
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2020-11-17 17:29 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-29 17:34 [PATCH] arm64: kprobes: Use BRK instead of single-step when executing instructions out-of-line Jean-Philippe Brucker
2020-10-29 23:34 ` Masami Hiramatsu
2020-10-30 1:13 ` [PATCH] arm64: kprobes: Remove redundant kprobe_step_ctx Masami Hiramatsu
2020-10-30 8:27 ` Jean-Philippe Brucker
2020-10-30 16:06 ` [PATCH] arm64: kprobes: Use BRK instead of single-step when executing instructions out-of-line Will Deacon
2020-10-30 16:13 ` Jean-Philippe Brucker
2020-11-02 11:41 ` Will Deacon
2020-11-02 13:52 ` Masami Hiramatsu
2020-11-03 9:13 ` Jean-Philippe Brucker
2020-11-03 9:23 ` Will Deacon
2020-11-17 17:28 ` Jean-Philippe Brucker [this message]
2020-11-24 2:34 ` 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=20201117172812.GA551957@myrica \
--to=jean-philippe@linaro.org \
--cc=catalin.marinas@arm.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=mhiramat@kernel.org \
--cc=will@kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox