[PATCH v8 1/4] arm64: vdso: Prepare for robust futex unlock support

[André Almeida]

Em 17/09/2026 07:01, Mark Rutland escreveu:
> On Wed, Sep 16, 2026 at 10:05:38PM -0300, André Almeida wrote:
>> Em 16/09/2026 11:24, Mark Rutland escreveu:
>>> I reckon this might also be clearer as:
>>>
>>> | 	if (regs->regs[3])
>>> | 		return NULL;
>>> | 	
>>> | 	return (void __user *)regs->regs[2];
>>>
>>> Do we need a __force cast here, or is sparse happy without that?
>>
>> I've just re-compiled those patches with C=1, and didn't find any warning
>> for this.
> 
> Perfect, thanks for confirming!
> 
> [...]
> 
>>>> +	futex_set_vdso_cs_range(fd, is_32bit ? 1 : 0, start, end, is_32bit);
>>>
>>> On arm64 (and every architecture other than x86, AFAICT), the
>>> native/compat VDSOs are mutually exclusive, and a single mm can only
>>> have one of them.
>>>
>>> Given that, I think we can make this:
>>>
>>> 	futex_set_vdso_cs_range(fd, 0, start, end, is_32bit);
>>>
>>> That way we'll avoid confusing/bikesheeding over 'is_32bit ? 1 : 0',
>>> without having to add mnemnonics for the native/compat CS indices.
>>
>> Perfect, I will simplify that then.
>>
>>> That said, what's the plan for 32-bit robust lists on a 64-bit host?
>>> IIUC you wanted that for emulation, and AFAICT you have no way to call
>>> __vdso_futex_robust_list32_try_unlock() from a native task.
>>
>> Yes, the plan is to be able to use the 32-bit robust lists on a 64-bit
>> hosts, with a new interface (set/get_robust_list2[1]). That means that a
>> 64-bit kernel will be able to process an user robust list made of 32-bit
>> pointers. So the emulator will call set_robust_list2() one time for it's own
>> list, and another time for the emulated app list.
>>
>> However, what we have agreed for the moment is that, while there's no
>> support for that, we will not expose the 32-bit functions yet [2]:
> 
> Ah, thanks for the pointer! I had mistakenly assumed that some of
> that had already happened.
> 
> I guess the common logic for futex_set_vdso_cs_range() will need to
> change at that point I guess if/when that happens, you'd expect to add
> __vdso_futex_robust_list32_try_unlock() into the 64-bit VDSO, regardless
> of compat?
> 

Yes, given __vdso_futex_robust_list64_try_unlock() would write a 64-bit 
zero word in a 32-bit pointer, I probably need someway to expose 
__vdso_futex_robust_list32_try_unlock().

However, this will be need when a x86-32 bit app is running on top of 
the emulator, where the 32-bit glibc would eventually call the x86-32 
version of the VDSO. I will check what the emulator does with the other 
VDSOs, if they redirect to the native arm versions or what.

> Mark.
> 
>> "...that requires also the ability to register a 32-bit robust list for a
>> 64-bit process, which is not supported right now. So no, we are not exposing
>> something half functional..."
>>
>> So yes, in the near future I will need to expose
>> __vdso_futex_robust_list32_try_unlock() to 64-bit apps as well, to be able
>> to do this handling with 32-bit pointers, but we are not doing it right now.
>>
>> [1] https://lore.kernel.org/lkml/20251122-tonyk-robust_futex-v6-0-05fea005a0fd@igalia.com/
>>
>> [2] https://lore.kernel.org/lkml/878q9vwote.ffs@tglx/
>>