linux-kernel - Re: [PATCH] oom: always panic on OOM when panic_on

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]

Date:	Sat, 6 Jun 2015 15:51:35 +0900
From:	Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp>
To:	mhocko@...e.cz, rientjes@...gle.com
Cc:	akpm@...ux-foundation.org, linux-mm@...ck.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] oom: always panic on OOM when panic_on_oom is configured

Michal Hocko wrote:
> > > Let's move check_panic_on_oom up before the current task is
> > > checked so that the knob value is . Do the same for the memcg in
> > > mem_cgroup_out_of_memory.
> > > 
> > > Reported-by: Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp>
> > > Signed-off-by: Michal Hocko <mhocko@...e.cz>
> > 
> > Nack, this is not the appropriate response to exit path livelocks.  By 
> > doing this, you are going to start unnecessarily panicking machines that 
> > have panic_on_oom set when it would not have triggered before.  If there 
> > is no reclaimable memory and a process that has already been signaled to 
> > die to is in the process of exiting has to allocate memory, it is 
> > perfectly acceptable to give them access to memory reserves so they can 
> > allocate and exit.  Under normal circumstances, that allows the process to 
> > naturally exit.  With your patch, it will cause the machine to panic.
> 
> Isn't that what the administrator of the system wants? The system
> is _clearly_ out of memory at this point. A coincidental exiting task
> doesn't change a lot in that regard. Moreover it increases a risk of
> unnecessarily unresponsive system which is what panic_on_oom tries to
> prevent from. So from my POV this is a clear violation of the user
> policy.

For me, !__GFP_FS allocations not calling out_of_memory() _forever_ is a
violation of the user policy.

If kswapd found nothing more to reclaim and/or kswapd cannot continue
reclaiming due to lock dependency, can't we consider as out of memory
because we already tried to reclaim memory which would have been done by
__GFP_FS allocations?

Why do we do "!__GFP_FS allocations do not call out_of_memory() because
they have very limited reclaim ability"? Both GFP_NOFS and GFP_NOIO
allocations will wake up kswapd due to !__GFP_NO_KSWAPD, doesn't it?

Are objects reclaimed by kswapd and objects reclaimed by __GFP_FS allocations
differ? If yes, we could introduce a proxy kernel thread which does __GFP_FS
allocations on behalf of !__GFP_FS allocators, and notify !__GFP_FS allocators
of completion. If no, why not to call out_of_memory() when kswapd found nothing
more to reclaim and/or kswapd cannot continue reclaiming due to lock dependency?

At least, I expect some warning like check_hung_task() in kernel/hung_task.c
is emitted when memory allocation livelock/deadlock is suspected. That will
help detecting unresponsive systems.
--
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/