From: Mark Brown <broonie@kernel.org>
To: Will Deacon <will@kernel.org>, Catalin Marinas <catalin.marinas@arm.com>
Cc: Mark Rutland <mark.rutland@arm.com>,
Mark Brown <broonie@kernel.org>,
linux-arm-kernel@lists.infradead.org
Subject: [PATCH v4 0/4] arm64: Make NOP handling a whitelist
Date: Mon, 4 May 2020 14:13:22 +0100 [thread overview]
Message-ID: <20200504131326.18290-1-broonie@kernel.org> (raw)
Currently we default to assuming any unrecognized instruction in the
hint space can be safely handled as a NOP. This is not robust and any
code that really wants a NOP should be using the explicitly defined NOP
so let's instead invert this and whitelist those instructions which it
is safe to handle as NOPs.
Patch 1 adds defines for the HINTs for BTI landing pads which will be
used by the in-kernel BTI series to generate landing pads in JITed BPF
code so it'd be good if this could be applied on or merged into the BTI
branch.
v4:
- Add a patch renaming _is_nop() to make the usage clearer.
- Reorder series and tweak commit logs.
v3:
- Correct values for more of the HINTs.
- Add constants for additional HINTs
- Handle XPACLRI as a NOP along with all the other PAC HINTs.
- Update commit messages for greater clarity.
- Tweak the comment about what a NOP.
v2:
- Fix values for BTI HINTs.
- Rebase on v5.7-rc3+for-next/bti-user
Mark Brown (4):
arm64: insn: Add constants for new HINT instruction decode
arm64: insn: Provide a better name for aarch64_insn_is_nop()
arm64: insn: Don't assume unrecognized HINTs are skippable
arm64: insn: Report PAC and BTI instructions as skippable
arch/arm64/include/asm/insn.h | 30 +++++++++++++++++++++---
arch/arm64/kernel/insn.c | 32 ++++++++++++++++++--------
arch/arm64/kernel/probes/decode-insn.c | 2 +-
3 files changed, 50 insertions(+), 14 deletions(-)
--
2.20.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next reply other threads:[~2020-05-04 13:13 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-04 13:13 Mark Brown [this message]
2020-05-04 13:13 ` [PATCH v4 1/4] arm64: insn: Add constants for new HINT instruction decode Mark Brown
2020-05-04 14:05 ` Mark Rutland
2020-05-04 13:13 ` [PATCH v4 2/4] arm64: insn: Provide a better name for aarch64_insn_is_nop() Mark Brown
2020-05-04 13:40 ` Mark Rutland
2020-05-04 13:13 ` [PATCH v4 3/4] arm64: insn: Don't assume unrecognized HINTs are skippable Mark Brown
2020-05-04 13:44 ` Mark Rutland
2020-05-04 13:13 ` [PATCH v4 4/4] arm64: insn: Report PAC and BTI instructions as skippable Mark Brown
2020-05-04 13:43 ` Mark Rutland
2020-05-04 15:33 ` [PATCH v4 0/4] arm64: Make NOP handling a whitelist Will Deacon
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=20200504131326.18290-1-broonie@kernel.org \
--to=broonie@kernel.org \
--cc=catalin.marinas@arm.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=mark.rutland@arm.com \
--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 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.