Re: [PATCH] s390/vdso: Implement __vdso_futex_robust_try_unlock()

[Heiko Carstens <hca@linux.ibm.com>]

On Mon, Oct 19, 2026 at 01:12:33PM +0200, Heiko Carstens wrote:
> Provide the s390 backend for the FUTEX_ROBUST_UNLOCK fix that was
> introduced for x86 with commit a2274cc0091e ("x86/vdso: Implement
> __vdso_futex_robust_try_unlock()"). See that commit for details.
> 
> Note that the Fixes tag does not mean that the x86 commit is broken,
> it is only helpful for backporting purposes, so required prerequisite
> code is present if this commit is backported.
> 
> Cc: stable@vger.kernel.org # 7.2
> Fixes: a2274cc0091e ("x86/vdso: Implement __vdso_futex_robust_try_unlock()")
> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>

Thinking about this again: the entire paragraph about "fixing" and
stable is nonsense. This is only about enabling FUTEX_ROBUST_UNLOCK
for s390. But the comment below about the test case remains true:

> Notes:
>     This passes all robust_list selftests in
>     tools/testing/selftests/futex/functional, except those listed below.
>     
>     wake32, wake_bitset32, unlock_pi32 fail, which seems to be kind of
>     expected, since those selftests set FUTEX_ROBUST_LIST32, which doesn't seem
>     to make too much sense for a 64 bit kernel without COMPAT support, since
>     futex_robust_list_clear_pending() contains this:
>     
>             if (IS_ENABLED(CONFIG_64BIT) && size32bit)
>                     return compat_robust_list_clear_pending(pop);
>     
>     which means that compat_robust_list_clear_pending() is guaranteed to do
>     nothing except returning false for !COMPAT. Therefore this looks like a
>     test case bug to me, but I could be entirely wrong.