linux-kernel - Re: [PATCH] fs, mm: account filp and names caches to kmemcg

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20171009181754.37svpqljub2goojr@dhcp22.suse.cz>
Date:   Mon, 9 Oct 2017 20:17:54 +0200
From:   Michal Hocko <mhocko@...nel.org>
To:     Greg Thelen <gthelen@...gle.com>
Cc:     Shakeel Butt <shakeelb@...gle.com>,
        Alexander Viro <viro@...iv.linux.org.uk>,
        Vladimir Davydov <vdavydov.dev@...il.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Linux MM <linux-mm@...ck.org>, linux-fsdevel@...r.kernel.org,
        LKML <linux-kernel@...r.kernel.org>,
        Johannes Weiner <hannes@...xchg.org>
Subject: Re: [PATCH] fs, mm: account filp and names caches to kmemcg

On Mon 09-10-17 20:04:09, Michal Hocko wrote:
> [CC Johannes - the thread starts
> http://lkml.kernel.org/r/20171005222144.123797-1-shakeelb@google.com]
> 
> On Mon 09-10-17 10:52:44, Greg Thelen wrote:
[...]
> > A few ideas on how to make it more flexible:
> > 
> > a) Go back to memcg oom killing within memcg charging.  This runs risk
> >    of oom killing while caller holds locks which oom victim selection or
> >    oom victim termination may need.  Google's been running this way for
> >    a while.

We can actually reopen this discussion now that the oom handling is
async due to the oom_reaper. At least for the v2 interface. I would have
to think about it much more but the primary concern for this patch was
whether we really need/want to charge short therm objects which do not
outlive a single syscall.
 
> > b) Have every syscall return do something similar to page fault handler:
> >    kmem allocations in oom memcg mark the current task as needing an oom
> >    check return NULL.  If marked oom, syscall exit would use
> >    mem_cgroup_oom_synchronize() before retrying the syscall.  Seems
> >    risky.  I doubt every syscall is compatible with such a restart.

yes, this is simply a no go

> > c) Overcharge kmem to oom memcg and queue an async memcg limit checker,
> >    which will oom kill if needed.

This is what we have max limit for.
-- 
Michal Hocko
SUSE Labs