Re: [PATCH v12 2/7] arm64: cpufeature: add FEAT_LSUI

[Catalin Marinas <catalin.marinas@arm.com>]

On Tue, Feb 10, 2026 at 05:01:33PM +0000, Yeoreum Yun wrote:
> > Why not keep uaccess_enable_privileged() in
> > arch_futex_atomic_op_inuser() and cmpxchg for all cases and make it a
> > no-op if FEAT_LSUI is implemented together with FEAT_PAN?
> 
> This is because I had a assumption FEAT_PAN must be present
> when FEAT_LSUI is presented and this was not considering the virtualisation case.
> and  FEAT_PAN is present uaccess_ttbr0_enable() becomes nop and
> following feedback you gave - https://lore.kernel.org/all/aJ9oIes7LLF3Nsp1@arm.com/
> and the reason you mention last, It doesn't need to call mte_enable_tco().
> 
> That's why I thought it doesn't need to call uaccess_enable_privileged().
> 
> But for a compatibility with SW_PAN, I think we can put only
> uaccess_ttbr0_enable() in arch_futex_atomic_op_inuser() and cmpxchg simply
> instead of adding a new APIs uaccess_enable_futex() and
> by doing this I think has_lsui() can be removed with its WRAN.

Yes, I think you can use uaccess_ttbr0_enable() when we take the
FEAT_LSUI path. What I meant above was for uaccess_enable_privileged()
to avoid PAN disabling if we have FEAT_LSUI as we know all cases would
be executed with user privileges.

Either way, we don't need a new uaccess_enable_futex().

> > BTW, with the removal of uaccess_enable_privileged(), we now get MTE tag
> > checks for the futex operations. I think that's good as it matches the
> > other uaccess ops, though it's a slight ABI change. If we want to
> > preserve the old behaviour, we definitely need
> > uaccess_enable_privileged() that only does mte_enable_tco().
> 
> I think we don't need to preserve the old behaviour. so we can skip
> mte_enable_tco() in case of FEAT_LSUI is presented.

Just spell it out in the commit log that we have a slight ABI change. I
don't think we'll have a problem but it needs at least checking with
some user-space (libc, Android) people.

-- 
Catalin