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: <20180130075226.GL21609@dhcp22.suse.cz>
Date:   Tue, 30 Jan 2018 08:52:26 +0100
From:   Michal Hocko <mhocko@...nel.org>
To:     Florian Westphal <fw@...len.de>
Cc:     "Kirill A. Shutemov" <kirill@...temov.name>,
        Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>,
        davem@...emloft.net, netfilter-devel@...r.kernel.org,
        coreteam@...filter.org, netdev@...r.kernel.org,
        aarcange@...hat.com, yang.s@...baba-inc.com,
        syzkaller-bugs@...glegroups.com, linux-kernel@...r.kernel.org,
        mingo@...nel.org, linux-mm@...ck.org, rientjes@...gle.com,
        akpm@...ux-foundation.org, guro@...com,
        kirill.shutemov@...ux.intel.com
Subject: Re: [netfilter-core] kernel panic: Out of memory and no killable
 processes... (2)

On Mon 29-01-18 23:35:22, Florian Westphal wrote:
> Kirill A. Shutemov <kirill@...temov.name> wrote:
[...]
> > I hate what I'm saying, but I guess we need some tunable here.
> > Not sure what exactly.
> 
> Would memcg help?

That really depends. I would have to check whether vmalloc path obeys
__GFP_ACCOUNT (I suspect it does except for page tables allocations but
that shouldn't be a big deal). But then the other potential problem is
the life time of the xt_table_info (or other potentially large) data
structures. Are they bound to any process life time. Because if they are
not then the OOM killer will not help. The OOM panic earlier in this
thread suggests it doesn't because the test case managed to eat all the
available memory and killed all the eligible tasks which didn't help.

So in some sense the memcg would help to stop the excessive allocation,
but it wouldn't resolve it other than kill all tasks in the affected
memcg/container. Whether this is sufficient or not, I dunno. It sounds
quite suboptimal to me. But it is true this would be less tricky then
adding a global knob...
-- 
Michal Hocko
SUSE Labs

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ