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

[Paul Walmsley <pjw@kernel.org>]

On Thu, 12 Feb 2026, Linus Torvalds wrote:

> On Thu, 12 Feb 2026 at 15:39, Paul Walmsley <pjw@kernel.org> wrote:
> >
> > Deepak Gupta (26):
> >       prctl: add arch-agnostic prctl()s for indirect branch tracking
> 
> Hmm. In the meantime, I had pulled the RSEQ time slice extensions
> stuff first, so what happened was that these prctl numbers got bumped
> up from 79-81 to 80-82.
> 
> I note that it looks like linux-next ended up merging things in a
> different order, and so instead left the indirect branch status prctls
> alone, and instead modified the RSEQ one.
> 
> Just letting everybody involved know - maybe this was obvious to
> people, and maybe this came as a surprise.

Thanks for the heads-up; shouldn't be a problem.

> And only very tangentially related: I think the indirect branch
> locking could have been just a separate bit from the enable bit. I
> don't see why it needed separate prctls for "set status" and "set
> lock".

Will think this through and respond back.

> On a similar theme: why is it called "indir_br_lp"? That's a horrible name.
> 
> This was supposed to be architecture-neutral, but I get the feeling
> that "lp" does not stand for "Long Play" and has nothing to do with
> 12-inch vinyl records.
> 
> 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.  Or 
perhaps "verified_branch_target" could be another option.  It would be 
nice to avoid using IBT or BTI, since those are definitely associated with 
specific architectures.  Any preference?

> In other words: I've pulled this, but I expect this to be fixed asap.

Will do, once we stop bikeshedding on the name :-)


thanks

- Paul