> From: Johannes Weiner <hannes@xxxxxxxxxxx> > Subject: [PATCH] memcg: do not sleep on OOM waitqueue with full charge context > > The memcg OOM handling is incredibly fragile because once a memcg goes > OOM, one task (kernel or userspace) is responsible for resolving the > situation. Every other task that gets caught trying to charge memory > gets stuck in a waitqueue while potentially holding various filesystem > and mm locks on which the OOM handling task may now deadlock. > > Do two things: > > 1. When OOMing in a system call (buffered IO and friends), invoke the > OOM killer but do not trap other tasks and just return -ENOMEM for > everyone. Userspace should be able to handle this... right? > > 2. When OOMing in a page fault, invoke the OOM killer but do not trap > other chargers directly in the charging code. Instead, remember > the OOMing memcg in the task struct and then fully unwind the page > fault stack first. Then synchronize the memcg OOM from > pagefault_out_of_memory(). > > While reworking the OOM routine, also remove a needless OOM waitqueue > wakeup when invoking the killer. Only uncharges and limit increases, > things that actually change the memory situation, should do wakeups. > > Signed-off-by: Johannes Weiner <hannes@xxxxxxxxxxx> >From point of the memcg oom notification view, it is NOT supported on the case that an oom handler process is subjected its own memcg limit. All memcg developers clearly agreed it since it began. Even though, anyway, people have a right to shoot their own foot. :) However, this patch fixes more than that. OK, I prefer it. Good fix! Acked-by: KOSAKI Motohiro <kosaki.motohiro@xxxxxxxxxxxxxx> -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>