linux-kernel - Re: tty crash due to auto-failing vmalloc

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: <20171004083343.tqy5xjzyd332bwdn@dhcp22.suse.cz>
Date:   Wed, 4 Oct 2017 10:33:43 +0200
From:   Michal Hocko <mhocko@...nel.org>
To:     Johannes Weiner <hannes@...xchg.org>
Cc:     Alan Cox <alan@...yncelyn.cymru>, Christoph Hellwig <hch@....de>,
        Andrew Morton <akpm@...ux-foundation.org>, linux-mm@...ck.org,
        linux-kernel@...r.kernel.org, kernel-team@...com
Subject: Re: tty crash due to auto-failing vmalloc

On Tue 03-10-17 18:55:04, Johannes Weiner wrote:
[...]
> commit 5d17a73a2ebeb8d1c6924b91e53ab2650fe86ffb
> Author: Michal Hocko <mhocko@...e.com>
> Date:   Fri Feb 24 14:58:53 2017 -0800
> 
>     vmalloc: back off when the current task is killed
>     
>     __vmalloc_area_node() allocates pages to cover the requested vmalloc
>     size.  This can be a lot of memory.  If the current task is killed by
>     the OOM killer, and thus has an unlimited access to memory reserves, it
>     can consume all the memory theoretically.  Fix this by checking for
>     fatal_signal_pending and back off early.
>     
>     Link: http://lkml.kernel.org/r/20170201092706.9966-4-mhocko@kernel.org
>     Signed-off-by: Michal Hocko <mhocko@...e.com>
>     Reviewed-by: Christoph Hellwig <hch@....de>
>     Cc: Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp>
>     Cc: Al Viro <viro@...iv.linux.org.uk>
>     Signed-off-by: Andrew Morton <akpm@...ux-foundation.org>
>     Signed-off-by: Linus Torvalds <torvalds@...ux-foundation.org>
> 
> This talks about the oom killer and memory exhaustion, but most fatal
> signals don't happen due to the OOM killer.

Now that we have cd04ae1e2dc8 ("mm, oom: do not rely on TIF_MEMDIE for
memory reserves access") the risk of the memory depletion is much
smaller so reverting the above commit should be acceptable. On the other
hand the failure is still possible and the caller should be prepared for
that.
-- 
Michal Hocko
SUSE Labs