On Tue 08-03-22 17:25:50, Nico Pache wrote: > The pthread struct is allocated on PRIVATE|ANONYMOUS memory [1] which can > be targeted by the oom reaper. This mapping is also used to store the futex > robust list; the kernel does not keep a copy of the robust list and instead > references a userspace address to maintain the robustness during a process > death. A race can occur between exit_mm and the oom reaper that allows > the oom reaper to clear the memory of the futex robust list before the > exit path has handled the futex death. The above is missing the important part of the problem description. So the oom_reaper frees the memory which is backing the robust list. It would be useful to link that to the lockup on the futex. > Prevent the OOM reaper from concurrently reaping the mappings if the dying > process contains a robust_list. If the dying task_struct does not contain > a pointer in tsk->robust_list, we can assume there was either never one > setup for this task struct, or futex_cleanup has properly handled the > futex death and we can safely reap this memory. I do agree with Waiman that this should go into a helper function. This would be a quick workaround but I believe that it would be much better to either do the futex cleanup in the oom_reaper context if that could be done without blocking. If that is really not feasible for some reason then we could skip over vmas which are backing the robust list. Have you considered any of those solutions? -- Michal Hocko SUSE Labs
