lkml.org 
[lkml]   [2022]   [Mar]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH v5] mm/oom_kill.c: futex: Close a race between do_exit and the oom_reaper
On Mon 21-03-22 19:57:24, Davidlohr Bueso wrote:
> On Mon, 21 Mar 2022, Nico Pache wrote:
>
> > We could proceed with the V3 approach; however if we are able to find a complete
> > solution that keeps both functionalities (Concurrent OOM Reaping & Robust Futex)
> > working, I dont see why we wouldnt go for it.
>
> Because semantically killing the process is, imo, the wrong thing to do.

I am not sure I follow. The task has been killed by the oom killer. All
we are discussing here is how to preserve the robust list metadata
stored in the memory which is normally unmapped by the oom_reaper to
guarantee a further progress.

I can see we have 4 potential solutions:
1) do not oom_reap oom victims with robust futex metadata in anonymous
memory. Easy enough but it could lead to excessive oom killing in
case the victim gets stuck in the kernel and cannot terminate.
2) clean up robust list from the oom_reaper context. Seems tricky due to
#PF handling from the oom_reaper context which would need to be
non-blocking
3) filter vmas which contain robust list. Simple check for the vma range
4) internally mark vmas which have to preserve the state during
oom_reaping. Futex code would somehow have to mark those mappings.
While more generic solution. I am not sure this is a practical
approach.
--
Michal Hocko
SUSE Labs

\
 
 \ /
  Last update: 2022-03-22 09:27    [W:0.324 / U:0.192 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site