Hi folks,

This is my take on implementing the new vDSO for unlocking a robust futex in
arm64. If you don't know what's that, Thomas wrote a good summary,
including the motivation for this work and the x86 implementation:

   https://lore.kernel.org/lkml/878qb89g7b.ffs@tglx/

There are some loose ends in my patchset so I'm sending as a RFC to ask
some questions:

 - If the process is interrupted between the labels, we need to check the
 conditional flags and clear the op_pending address from the register. Using
 objdump I see that op_pending addr is being stored at x2, but I suspect that
 this isn't stable, so I need to figure out how to make sure that the address
 will always be stored in the same register.
 - So far I have implemented only the LL/SC version to make review easier, but I
 can do the LSE version as well.

This patchset works fine with the tests proposed at
https://lore.kernel.org/lkml/20260330120118.012924430@kernel.org/

Changes from v1:
 - s/CONFIG_COMPAT/CONFIG_COMPAT_VDSO (Thomas Weißschuh)
 - Fixed linker not finding the symbols (Thomas Weißschuh)
v1: https://patch.msgid.link/20260417-tonyk-robust_arm-v1-0-03aa64e2ff1a@igalia.com

---
André Almeida (2):
      arm64: vdso: Prepare for robust futex unlock support
      arm64: vdso: Implement __vdso_futex_robust_try_unlock()

 arch/arm64/Kconfig                                 |  1 +
 arch/arm64/include/asm/futex_robust.h              | 35 +++++++++++++
 arch/arm64/kernel/vdso.c                           | 30 +++++++++++
 arch/arm64/kernel/vdso/Makefile                    |  9 +++-
 arch/arm64/kernel/vdso/vdso.lds.S                  | 11 ++++
 .../kernel/vdso/vfutex_robust_list_try_unlock.c    | 59 ++++++++++++++++++++++
 6 files changed, 144 insertions(+), 1 deletion(-)
---
base-commit: 0e8896e9899b607bb168c1cce340596b8c2e3e2b
change-id: 20260416-tonyk-robust_arm-54ff77d2c4e4

Best regards,
--  
André Almeida <andrealmeid@igalia.com>

On 2026-04-24 15:55:59 [-0300], André Almeida wrote:
> Hi folks,
Hi,

> This is my take on implementing the new vDSO for unlocking a robust futex in
> arm64. If you don't know what's that, Thomas wrote a good summary,
> including the motivation for this work and the x86 implementation:
> 
>    https://lore.kernel.org/lkml/878qb89g7b.ffs@tglx/
> 
> There are some loose ends in my patchset so I'm sending as a RFC to ask
> some questions:
> 
>  - If the process is interrupted between the labels, we need to check the
>  conditional flags and clear the op_pending address from the register. Using
>  objdump I see that op_pending addr is being stored at x2, but I suspect that
>  this isn't stable, so I need to figure out how to make sure that the address
>  will always be stored in the same register.
>  - So far I have implemented only the LL/SC version to make review easier, but I
>  can do the LSE version as well.

I am a bit behind here. In the meantime, were you able to check it with
	https://lore.kernel.org/all/20260404093939.7XgeW_54@linutronix.de/
?

Sebastian

Hi Sebastian,

Em 28/04/2026 08:00, Sebastian Andrzej Siewior escreveu:
> On 2026-04-24 15:55:59 [-0300], André Almeida wrote:
>> Hi folks,
> Hi,
> 
>> This is my take on implementing the new vDSO for unlocking a robust futex in
>> arm64. If you don't know what's that, Thomas wrote a good summary,
>> including the motivation for this work and the x86 implementation:
>>
>>     https://lore.kernel.org/lkml/878qb89g7b.ffs@tglx/
>>
>> There are some loose ends in my patchset so I'm sending as a RFC to ask
>> some questions:
>>
>>   - If the process is interrupted between the labels, we need to check the
>>   conditional flags and clear the op_pending address from the register. Using
>>   objdump I see that op_pending addr is being stored at x2, but I suspect that
>>   this isn't stable, so I need to figure out how to make sure that the address
>>   will always be stored in the same register.
>>   - So far I have implemented only the LL/SC version to make review easier, but I
>>   can do the LSE version as well.
> 
> I am a bit behind here. In the meantime, were you able to check it with
> 	https://lore.kernel.org/all/20260404093939.7XgeW_54@linutronix.de/
> ?
Sorry for my delay. Yes, I had to do some modifications for the test 
(will reply to your patch) and spot one error in my patch, and now the 
test passes, thanks! Will send a v3 for this soon.