On Wed, Dec 8, 2021 at 11:05 AM Michal Hocko <mhocko@xxxxxxxx> wrote: > > On Wed 08-12-21 10:01:44, Michal Hocko wrote: > > On Tue 07-12-21 15:47:59, Andrew Morton wrote: > > > (cc's added) > > > > Extend CC to have all futex maintainers on board. > > > > > On Tue, 7 Dec 2021 16:49:02 -0500 Joel Savitz <jsavitz@xxxxxxxxxx> wrote: > > > > > > > In the case that two or more processes share a futex located within > > > > a shared mmaped region, such as a process that shares a lock between > > > > itself and a number of child processes, we have observed that when > > > > a process holding the lock is oom killed, at least one waiter is never > > > > alerted to this new development and simply continues to wait. > > > > > > Well dang. Is there any way of killing off that waiting process, or do > > > we have a resource leak here? > > > > > > > This is visible via pthreads by checking the __owner field of the > > > > pthread_mutex_t structure within a waiting process, perhaps with gdb. > > > > > > > > We identify reproduction of this issue by checking a waiting process of > > > > a test program and viewing the contents of the pthread_mutex_t, taking note > > > > of the value in the owner field, and then checking dmesg to see if the > > > > owner has already been killed. > > > > > > > > This issue can be tricky to reproduce, but with the modifications of > > > > this small patch, I have found it to be impossible to reproduce. There > > > > may be additional considerations that I have not taken into account in > > > > this patch and I welcome any comments and criticism. > > > > Why does OOM killer need a special handling. All the oom killer does is > > to send a fatal signal to the victim. Why is this any different from > > sending SIGKILL from the userspace? > > I have had a closer look and I guess I can see what you are trying to > achieve. futex_exit_release is normally called from exit_mm context. You > are likely seeing a situation when the oom victim is blocked and cannot > exit. That is certainly possible but it shouldn't be a permanent state. > So I would be more interested about your particular issue and how long > the task has been stuck unable to exit. Before applying this patch I never saw a task eventually exit during the reproduction of this system state. Every task in this waiting-on-a-dead-owner situation state appeared to be permanently blocked until user intervention killed it manually. > > Whether this is safe to be called from the oom killer context I cannot > really judge. That would be a question to Futex folks. I am also very interested in feedback from the Futex folks. This is the first fix for the bug that I have found but I am not sure whether this introduces other issues due to the context. > -- > Michal Hocko > SUSE Labs > Best, Joel Savitz
