[GIT PULL] RISC-V updates for v7.0

[Linus Torvalds]

On Fri, 13 Feb 2026 at 16:23, Paul Walmsley <pjw at kernel.org> wrote:
>
> > I think it probably is shorthand for "lpad", which is RISC-V thing.
> > Which is complete nonsense for something that is documented to be
> > architecture-neutral.
>
> RISC-V didn't invent that term; here are some earlier CFI-related uses:
>
> * ARM (2019): https://developer.arm.com/-/media/Arm%20Developer%20Community/PDF/Learn%20the%20Architecture/Providing%20protection%20for%20complex%20software.pdf
> * LWN (2022): https://lwn.net/Articles/900099/
> * FineIBT (2023): https://cs.brown.edu/~vpk/papers/fineibt.raid23.pdf
>
> If you're okay with keeping the term "landing pad," we could get rid of
> the "LP" and use something like "branch_landing_pad" instead.

Oh, ok. "landing pad" makes sense. "lp" didn't.

I absolutely detest the industry practice of making crazy acronyms
that make no sense - and then every company makes their *own* crazy
acronym to make things worse.

Please just write it out. It's a few extra characters, but maybe it
then makes people understand what it is all about.

When it's called "indir_br_lp", it's just line noise. The most
understandable part of that line noise is "indir", but that's also the
least relevant - noody does this all for direct branches anyway, so
the "indir" part is arguably the least useful part of it.

So yeah, something like "branch_landing_pad" at least sounds like it's
meant for human consumption.

I would have expected there to be some industry standard naming for
this, but if there is, I sure can't find it. Everybody carves out
their own small space of "control flow integrity" and gives it a TLA.

So I can only find letter jumbles that are all different for different
architectures. Oh well.

I do wonder if we should do something like the existing speculation
control prctl does: we have a notion of "prctl_spec_ctrl", and it then
has "subcontrols" for the individual parts (ie PR_SPEC_STORE_BYPASS /
PR_SPEC_INDIRECT_BRANCH / PR_SPEC_L1D_FLUSH).

Although it looks like only PR_SPEC_STORE_BYPASS ends up being
somewhat cross-architecture.

IOW, I get the feeling that we should have a "control flow integrity" prctl.

Because arguably the shadow-stack feature would have fit under that
umbrella - instead of us now having multiple different prctrls.

One subcontrol of that that control flow integrity prctrl to be set
(and queried, and locked) would then be that "branch_landing_pad" bit
(aka arm64 BTI, x86 IBT, and apparently Zicfilp if you're a RISC-V
person).

I guess with names like "Zicfilp" - it really rolls off the tongue,
doesn't it - the notion of "human readable" might be a foreign concept
to some RISC-V designers. They really took that "TLA's are bad" as a
challenge, went "hold my beer", and came up with an even *worse*
industry practice.

Can we please be a force for good in the industry, and try to use
names and identifiers that make sense to humans?

And maybe be a bit forward-thinking so that the *next* time somebody
wants to do a prctrl for some flow control setting, we already have
the infrastructure in place?

                  Linus