Re: [patch V5 11/16] futex: Provide infrastructure to plug the non contended robust futex unlock race

[Thomas Gleixner <tglx@kernel.org>]

On Wed, Jun 03 2026 at 11:14, Peter Zijlstra wrote:
> On Tue, Jun 02, 2026 at 11:10:04AM +0200, Thomas Gleixner wrote:
>> This is only relevant when user space was interrupted and a signal is
>> pending. The fix-up has to be done before signal delivery is attempted
>> because:
>> 
>>    1) The signal might be fatal so get_signal() ends up in do_exit()
>> 
>>    2) The signal handler might crash or the task is killed before returning
>>       from the handler. At that point the instruction pointer in pt_regs is
>>       not longer the instruction pointer of the initially interrupted unlock
>>       sequence.
>
> However, due to the pending field being strictly per thread (thread
> local storage and all that), the whole construct of futex robust unlock
> is not signal safe in the sense that signal handlers must not use it.
>
> A signal handler trying to use this would result in nested use of the
> pending field, and that leads to corrupted state.

That's true already today and this unlock magic does not change it.

>> Other architectures might need to do more complex evaluations due to LLSC,
>> but the approach is valid in general. The size of the pointer is determined
>> from the matching range struct, which covers both 32-bit and 64-bit builds
>> including COMPAT.
>
> So my initial thoughts today were that we should probably also move the
> IP to .Lend, to avoid userspace from writing to that location again.
>
> However, due to the above mentioned restrictions vs signals, there
> cannot be a situation where this matters, and so the point is moot.
>
> A double store is harmless and it makes the kernel just this little bit
> simpler.
>
> The only reason I'm sending this email is to have this more explicitly
> documented for posterity I suppose ;-)

Indeed :)