In the Linux kernel, the following vulnerability has been resolved:<\/p>\n
memcg: bypass the reclaim and oom killer for dying tasks once oom_reaper is done<\/p>\n
At Meta, we are seeing instances where an OOM killed job is stuck in the
\nexit path for several hours. In one particular case, the job was stuck
\nfor more than 8 hours and I had to manually remove the memory.max limits
\nto allow the process to exit.<\/p>\n
The job was a single process job and had ~55 GiB memory.max and zswap
\nenabled. It had almost 0 anon in memory and ~111 GiB in zswap compressed
\nto ~51 GiB zswap pool (i.e. almost all of memory.current was zswap).
\nNothing was left on the LRUs to reclaim.<\/p>\n
On further inspection, I observed ~20k threads of that process stuck with
\nthe following stack:<\/p>\n
[] mem_cgroup_out_of_memory+0x4e\/0xa0
\n[] charge_memcg+0x8bf\/0x990
\n[] mem_cgroup_swapin_charge_folio+0x4e\/0x80
\n[] __read_swap_cache_async+0x10c\/0x260
\n[] swapin_readahead+0x116\/0x3f0
\n[] do_swap_page+0x13c\/0x1ce0
\n[] handle_mm_fault+0x61d\/0x11f0
\n[] do_user_addr_fault+0x3e7\/0x6d0
\n[] exc_page_fault+0x8f\/0x110
\n[] asm_exc_page_fault+0x22\/0x30
\n[] __get_user_8+0x14\/0x20
\n[] futex_cleanup+0x27\/0x1c0
\n[] futex_exit_release+0x47\/0x60
\n[] do_exit+0x107\/0x940
\n[] do_group_exit+0x81\/0xa0
\n[] get_signal+0x2b1\/0x6e0
\n[] arch_do_signal_or_restart+0x1a\/0x1c0
\n[] exit_to_user_mode_loop+0xa8\/0x1c0
\n[] do_syscall_64+0x152\/0x250
\n[] entry_SYSCALL_64_after_hwframe+0x4b\/0x53<\/p>\n
In addition the dmesg was filled with “Out of memory and no killable
\nprocesses…” messages.<\/p>\n
I have no idea why oom reaper was not able to reap\/unmap the process. My
\nguess is that since oom reaper tries to acquire mmap_lock in read mode
\nlimited number of times and then gives up, there might be a thread of that
\nprocess which had mmap_lock in write mode at that time.<\/p>\n
My initial suspicion was the futex_cleanup and kernel page fault causing
\ninfinite fault and charge retries but that was put to rest in previous
\ndiscussions happened on similar problem [1].<\/p>\n
My current theory is that it is just a simple slow serialization behind
\nthe oom_lock. Unlike page allocator, memcg charge code takes the oom_lock
\nwithout the “try”. Though memcg oom code uses mutex_lock_killable(), note
\nthat in the call stack get_signal() consumes SIGKILL (or
\nsigdelset(SIGKILL)) before calling do_group_exit(). So this
\nmutex_lock_killable() is just a mutex_lock() here. Therefore 10s of
\nthousands of threads are waiting on oom_lock and one by one they get
\n-EFAULT from get_user() in the futex cleanup code and bails out.<\/p>\n
Discussion from [1] led to commit a75ffa26122b (“memcg, oom: do not bypass
\noom killer for dying tasks”) which routes dying tasks into the OOM path
\nprecisely so the oom_reaper can reap their mm and free the memory
\nasynchronously. But the reaper is best-effort and one-shot: if it cannot
\ntake mmap_lock for read (e.g. a sibling thread holds it for write) it
\nsets MMF_OOM_SKIP and never retries, leaving only the glacial
\noom_lock-serialized synchronous drain.<\/p>\n
Once MMF_OOM_SKIP is set there is no more asynchronous reclaim coming for
\nthe mm, so a dying task charging against it has nothing left to wait for:
\nit frees its memory only once it finishes exiting. Running reclaim and
\nthe (no-victim) OOM killer for it is then pointless, and doing it for 10s
\nof thousands of exiting threads is what serializes them behind oom_lock.
\nSo before reclaim, if current is an OOM victim whose reaper is done, fail
\nthe charge.<\/p>\n
Reproduced with 20k threads, each parking a robust futex head on its own
\nzswapped page, OOM-group-killed while a sibling holds mmap_lock for write
\nso the reaper gives up and sets MMF_OOM_SKIP. Tested on next-20260728 and
\nbaseline show ~90 seconds exit time while with the patch the exit time
\nreduced to ~3 seconds.<\/p>\n","protected":false},"excerpt":{"rendered":"
In the Linux kernel, the following vulnerability has been resolved:<\/p>\n
memcg: bypass the reclaim and oom killer for dying tasks once oom_reaper is done<\/p>\n
At Meta, we are seeing instances where an OOM kil<\/p>\n","protected":false},"template":"","meta":[],"categories":[],"tags":[],"class_list":["post-28505","vuln","type-vuln","status-publish","hentry"],"_links":{"self":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=\/wp\/v2\/vuln\/28505","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=\/wp\/v2\/vuln"}],"about":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=\/wp\/v2\/types\/vuln"}],"wp:attachment":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=28505"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.54iter.cn\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=28505"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.54iter.cn\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=28505"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}