From: Mark Brown <broonie@kernel.org>
To: Ard Biesheuvel <ardb@kernel.org>
Cc: Will Deacon <will@kernel.org>,
Catalin Marinas <catalin.marinas@arm.com>,
Mark Rutland <mark.rutland@arm.com>,
Linux ARM <linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH v3 2/2] arm64: Unconditionally override SYM_FUNC macros
Date: Tue, 14 Dec 2021 14:58:12 +0000 [thread overview]
Message-ID: <YbixBCcLVaYWAyQU@sirena.org.uk> (raw)
In-Reply-To: <CAMj1kXH8gFcWTOLwxYu+FZ_zSuQt3kHU2M3YOhZNNBjxFKLKZQ@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 1283 bytes --]
On Tue, Dec 14, 2021 at 03:31:07PM +0100, Ard Biesheuvel wrote:
> On Tue, 14 Dec 2021 at 15:28, Mark Brown <broonie@kernel.org> wrote:
> > > I already pointed out computed gotos, which are admittedly rare, but
> > > there are other reasons why adhering to WYSIWYG is strongly preferred
> > > for asm code IMO.
> > The use case for this macro is for SYM_FUNC_START() which is going to be
> > emitting the BTI without it really appearing directly in the code so I'm
> > not sure how much I buy that TBH. I think you're pushing back on uses
> > of the macro outside of linkage.h more than on what linkage.h is doing,
> > that does make more sense to me.
> Fair point, but we don't really have any control over where else BTI_C
> may end up being used, no?
It's also a macro, which should put people off, and there's precious
little arm64 asm outside of arch/arm64 so I'm not sure how worried I am
about that.
> In any case, I don't think it's worth it blowing up the validation
> matrix over this, so if we can emit the same code for all
> configurations, we should IMO
We could have been doing that since the BTI kernel support was
originally merged... TBH I'm just really surprised everyone's pushing
to generate worse code here, feels not the direction people usually go
in.
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
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:[~2021-12-14 14:59 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-12-08 16:08 [PATCH v3 0/2] arm64: BTI cleanups Mark Brown
2021-12-08 16:08 ` [PATCH v3 1/2] arm64: Add macro version of the BTI instruction Mark Brown
2021-12-13 18:44 ` Will Deacon
2021-12-08 16:08 ` [PATCH v3 2/2] arm64: Unconditionally override SYM_FUNC macros Mark Brown
2021-12-13 18:46 ` Will Deacon
2021-12-13 19:21 ` Mark Brown
2021-12-14 14:10 ` Will Deacon
2021-12-14 14:12 ` Ard Biesheuvel
2021-12-14 14:28 ` Mark Brown
2021-12-14 14:31 ` Ard Biesheuvel
2021-12-14 14:58 ` Mark Brown [this message]
2021-12-09 9:29 ` [PATCH v3 0/2] arm64: BTI cleanups Ard Biesheuvel
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=YbixBCcLVaYWAyQU@sirena.org.uk \
--to=broonie@kernel.org \
--cc=ardb@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).