lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Wed, 17 Feb 2010 09:41:37 +0900 From: KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com> To: David Rientjes <rientjes@...gle.com> Cc: Andrew Morton <akpm@...ux-foundation.org>, Rik van Riel <riel@...hat.com>, Nick Piggin <npiggin@...e.de>, Andrea Arcangeli <aarcange@...hat.com>, Balbir Singh <balbir@...ux.vnet.ibm.com>, Lubos Lunak <l.lunak@...e.cz>, KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>, linux-kernel@...r.kernel.org, linux-mm@...ck.org Subject: Re: [patch -mm 4/9 v2] oom: remove compulsory panic_on_oom mode On Tue, 16 Feb 2010 16:31:39 -0800 (PST) David Rientjes <rientjes@...gle.com> wrote: > On Wed, 17 Feb 2010, KAMEZAWA Hiroyuki wrote: > > > Hmm, I have a few reason to add special behavior to memcg rather than panic. > > > > - freeze_at_oom is enough. > > If OOM can be notified, the management daemon can do useful jobs. Shutdown > > all other cgroups or migrate them to other host and do kdump. > > > > The same could be said for cpusets if users use that for memory isolation. > cpuset's difficulty is that there are some methods which share the limitation. It's not simple that we have - cpuset - mempolicy per task - mempolicy per vma Sigh..but they are for their own purpose. > > But, Hmm...I'd like to go this way. > > > > 1. At first, support panic_on_oom=2 in memcg. > > > > This should panic in mem_cgroup_out_of_memory() and the documentation > should be added to Documentation/sysctl/vm.txt. > > The memory controller also has some protection in the pagefault oom > handler that seems like it could be made more general: instead of checking > for mem_cgroup_oom_called(), I'd rather do a tasklist scan to check for > already oom killed task (checking for the TIF_MEMDIE bit) and check all > zones for ZONE_OOM_LOCKED. If no oom killed tasks are found and no zones > are locked, we can check sysctl_panic_on_oom and invoke the system-wide > oom. > plz remove memcg's hook after doing that. Current implemantation is desgined not to affect too much to other cgroups by doing unnecessary jobs. > > 2. Second, I'll add OOM-notifier and freeze_at_oom to memcg. > > and don't call memcg_out_of_memory in oom_kill.c in this case. Because > > we don't kill anything. Taking coredumps of all procs in memcg is not > > very difficult. > > > > The oom notifier would be at a higher level than the oom killer, the oom > killer's job is simply to kill a task when it is called. > So for these particular cases, you would never even call into out_of_memory() to panic > the machine in the first place. That's my point. Thanks, -Kame -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists