From: Will Deacon <will@kernel.org>
To: Masami Hiramatsu <mhiramat@kernel.org>
Cc: Jean-Philippe Brucker <jean-philippe@linaro.org>,
Steven Rostedt <srostedt@redhat.com>,
dianders@chromium.org, linux-arm-kernel@lists.infradead.org,
catalin.marinas@arm.com
Subject: Re: [PATCH] arm64: Fix early single-stepping
Date: Wed, 25 Nov 2020 16:11:34 +0000 [thread overview]
Message-ID: <20201125161133.GA16924@willie-the-truck> (raw)
In-Reply-To: <20201126010906.dd56ca668e30de6be9380028@kernel.org>
Hi Masami,
On Thu, Nov 26, 2020 at 01:09:06AM +0900, Masami Hiramatsu wrote:
> On Wed, 28 Oct 2020 08:36:44 +0000
> Will Deacon <will@kernel.org> wrote:
> > Cheers. An alternative (which I think would be better in the long run
> > anyway) would be to avoid using hardware step in kprobes and instead rely
> > on a BRK instruction to trap after running the trampoline.
>
> We started working on using the BRK instead of hardware step in kprobes
> in other threads. However, there still be a bug in the kernel.
> I would like to fix or at least mitigate this issue until this is released
> (since it's a bug)
>
> Would you think we can push the BRK only kprobes until it or in stable kernel?
> Or, we should add a mitigation patch for this bug?
> For the mitigation, I think we can introduce a kconfig flag which indicates
> the arch doesn't support early kprobes, in that case we defer the kprobe and
> boot-time trace later stage. This flag will be removed after we introduce the
> BRK-only kprobes.
The BRK stuff is merged upstream:
http://git.kernel.org/linus/7ee31a3aa8f49
Are you saying that this isn't sufficient to fix the problem?
Will
_______________________________________________
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-25 16:12 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-26 17:29 [PATCH] arm64: Fix early single-stepping Jean-Philippe Brucker
2020-10-26 17:38 ` Will Deacon
2020-10-27 0:48 ` Masami Hiramatsu
2020-10-27 10:13 ` Masami Hiramatsu
2020-10-27 10:42 ` Masami Hiramatsu
2020-10-27 11:59 ` Jean-Philippe Brucker
2020-10-27 12:33 ` Will Deacon
2020-10-27 13:49 ` Masami Hiramatsu
2020-10-28 8:28 ` Jean-Philippe Brucker
2020-10-28 8:36 ` Will Deacon
2020-10-28 9:07 ` Masami Hiramatsu
2020-10-28 9:48 ` Jean-Philippe Brucker
2020-10-28 12:21 ` Masami Hiramatsu
2020-11-25 16:09 ` Masami Hiramatsu
2020-11-25 16:11 ` Will Deacon [this message]
2020-11-25 16:18 ` 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=20201125161133.GA16924@willie-the-truck \
--to=will@kernel.org \
--cc=catalin.marinas@arm.com \
--cc=dianders@chromium.org \
--cc=jean-philippe@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=mhiramat@kernel.org \
--cc=srostedt@redhat.com \
/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.