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/[email protected]/ > 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
