On 2017/03/15 22:03, Michal Hocko wrote: > On Wed 15-03-17 01:07:43, Theodore Ts'o wrote: >> Unfortunately, this can indeed cause livelocks, since inside the >> writepages() call, the file system is holding various mutexes, and >> these mutexes may prevent the OOM killer from killing its targetted >> victim if it is also holding on to those mutexes. > > The victim might be looping inside do_writepages now instead (especially > when the memory reserves are depleted), though. On the other hand the > recent OOM killer changes do not rely on the oom victim exiting anymore. True only if CONFIG_MMU=y. > We try to reap as much memory from its address space as possible > which alone should help us to move on. Even if that is not sufficient we > will move on to another victim. So unless everything is in this path and > all the memory is sitting unreachable from the reapable address space we > should be safe. If the caller is doing sync() or umount() syscall, isn't it reasonable to bail out if fatal_signal_pending() is true because it is caller's responsibility to check whether sync() or umount() succeeded? Though, I don't know whether writepages() can preserve data for later retry by other callers. -- 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>
