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: Mon, 16 Sep 2013 16:03:18 +0200 From: Michal Hocko <mhocko@...e.cz> To: Johannes Weiner <hannes@...xchg.org> Cc: Glauber Costa <glommer@...il.com>, azurIt <azurit@...ox.sk>, Andrew Morton <akpm@...ux-foundation.org>, David Rientjes <rientjes@...gle.com>, KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>, KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>, linux-mm@...ck.org, cgroups@...r.kernel.org, x86@...nel.org, linux-arch@...r.kernel.org, linux-kernel@...r.kernel.org Subject: Re: [patch 0/7] improve memcg oom killer robustness v2 [Sorry for the late reply. I am in pre-long-vacation mode trying to clean up my desk] On Thu 12-09-13 08:59:38, Johannes Weiner wrote: > On Mon, Sep 09, 2013 at 02:56:59PM +0200, Michal Hocko wrote: [...] > > Hmm, wait a second. I have completely forgot about the kmem charging > > path during the review. > > > > So while previously memcg_charge_kmem could have oom killed a > > task if the it couldn't charge to the u-limit after it managed > > to charge k-limit, now it would simply fail because there is no > > mem_cgroup_{enable,disable}_oom around __mem_cgroup_try_charge it relies > > on. The allocation will fail in the end but I am not sure whether the > > missing oom is an issue or not for existing use cases. > > Kernel sites should be able to handle -ENOMEM, right? And if this > nests inside a userspace fault, it'll still enter OOM. Yes, I am not concerned about page faults or the kernel not being able to handle ENOMEM. I was more worried about somebody relying on kmalloc allocation trigger OOM (e.g. fork bomb hitting kmem limit). This wouldn't be a good idea in the first place but I wanted to hear back from those who use kmem accounting for something real. I would rather see no-oom from kmalloc until oom is kmem aware. > > My original objection about oom triggered from kmem paths was that oom > > is not kmem aware so the oom decisions might be totally bogus. But we > > still have that: > > Well, k should be a fraction of u+k on any reasonable setup, so there > are always appropriate candidates to take down. > > > /* > > * Conditions under which we can wait for the oom_killer. Those are > > * the same conditions tested by the core page allocator > > */ > > may_oom = (gfp & __GFP_FS) && !(gfp & __GFP_NORETRY); > > > > _memcg = memcg; > > ret = __mem_cgroup_try_charge(NULL, gfp, size >> PAGE_SHIFT, > > &_memcg, may_oom); > > > > I do not mind having may_oom = false unconditionally in that path but I > > would like to hear fromm Glauber first. > > The patch I just sent to azur puts this conditional into try_charge(), > so I'd just change the kmem site to pass `true'. It seems that your previous patch got merged already (3812c8c8). Could you post your new version on top of the merged one, please? I am getting lost in the current patch flow. I will try to review it before I leave (on Friday). Thanks! -- Michal Hocko SUSE Labs -- 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