Re: [RFC PATCH 0/2] futex: how to solve the robust_list race condition?

[André Almeida]

Hi Liam,

Em 20/02/2026 17:51, Liam R. Howlett escreveu:
> +Cc Suren, Lorenzo, and Michal
>
> * André Almeida <andrealmeid@xxxxxxxxxx> [260220 15:27]:
> > During LPC 2025, I presented a session about creating a new syscall for
> > robust_list[0][1]. However, most of the session discussion wasn't much related
> > to the new syscall itself, but much more related to an old bug that exists in
> > the current robust_list mechanism.
>
> Ah, sorry for hijacking the session, that was not my intention, but this
> needs to be addressed before we propagate the issue into the next
> iteration.

No problem! I believe that this reflects the fact that the race 
condition is the main concern about this new interface, and that we 
should focus our discussion around this.

> > Since at least 2012, there's an open bug reporting a race condition, as
> > Carlos O'Donell pointed out:
> >
> >    "File corruption race condition in robust mutex unlocking"
> >    https://sourceware.org/bugzilla/show_bug.cgi?id=14485

[...]

> There was a delay added to the oom reaper for these tasks [1] by commit
> e4a38402c36e ("oom_kill.c: futex: delay the OOM reaper to allow time for
> proper futex cleanup")
>
> We did discuss marking the vmas as needing to be skipped by the oom
> manager, but no clear path forward was clear.  It's also not clear if
> that's the only area where such a problem exists.
>
> [1].  https://lore.kernel.org/all/20220414144042.677008-1-npache@xxxxxxxxxx/T/#u

So how would you detect which vmas should be skipped? And this won't fix 
the issue when the memory is unmapped right, just for the OOM case?