On Tue 12-12-17 17:09:36, Tetsuo Handa wrote: > Michal Hocko wrote: > > That being said, I will keep refusing other such tweaks unless you have > > a sound usecase behind. If you really _want_ to help out here then you > > can focus on the reaping of the mlock memory. > > Not the reaping of the mlock'ed memory. Although Manish's report was mlock'ed > case, there are other cases (e.g. MAP_SHARED, mmu_notifier, mmap_sem held for > write) which can lead to this race condition. Could you actually start thinking in a bigger picture rather than obsessively check the code? If MAP_SHARED is file backed then it should be reclaimable. If it is memory backed then we are screwed with insufficient sized swap partition. I've seen that David is already looking at the mmu_notifier. Well and the mmap_sem, sure that can happen but as long we do not see excessive OOM events out there I would rather leave it alone. > If we think about artificial case, > it would be possible to run 1024 threads not sharing signal_struct but consume > almost 0KB memory (i.e. written without using C library) and many of them are > running between __gfp_pfmemalloc_flags() and mutex_trylock() waiting for > ALLOC_OOM. Sigh... Nobody is arguing that the race is impossible. Just read what I've wrote. I recognize the race but I am not willing to add kludges into an already complicated code if it doesn't matter _practically_. A malicious user can DOS the system by other means and you have to configure your system carefully to prevent from that. So all I care about is to see whether these races happen out there in natural workloads and then we can more heuristics. -- Michal Hocko SUSE Labs -- 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>
