Re: [PATCH 1/2] Revert "vmalloc: back off when the current task is killed"

From: Tetsuo Handa
Date: Sat Oct 07 2017 - 00:14:08 EST


Johannes Weiner wrote:
> On Sat, Oct 07, 2017 at 11:21:26AM +0900, Tetsuo Handa wrote:
> > On 2017/10/05 19:36, Tetsuo Handa wrote:
> > > I don't want this patch backported. If you want to backport,
> > > "s/fatal_signal_pending/tsk_is_oom_victim/" is the safer way.
> >
> > If you backport this patch, you will see "complete depletion of memory reserves"
> > and "extra OOM kills due to depletion of memory reserves" using below reproducer.
> >
> > ----------
> > #include <linux/module.h>
> > #include <linux/slab.h>
> > #include <linux/oom.h>
> >
> > static char *buffer;
> >
> > static int __init test_init(void)
> > {
> > set_current_oom_origin();
> > buffer = vmalloc((1UL << 32) - 480 * 1048576);
>
> That's not a reproducer, that's a kernel module. It's not hard to
> crash the kernel from within the kernel.
>

When did we agree that "reproducer" is "userspace program" ?
A "reproducer" is a program that triggers something intended.

Year by year, people are spending efforts for kernel hardening.
It is silly to say that "It's not hard to crash the kernel from
within the kernel." when we can easily mitigate.

Even with cd04ae1e2dc8, there is no point with triggering extra
OOM kills by needlessly consuming memory reserves.