Re: [PATCH] oom: always panic on OOM when panic_on_oom is configured

[Michal Hocko <mhocko@suse.cz>]

On Sat 06-06-15 15:51:35, Tetsuo Handa wrote:
> 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@I-love.SAKURA.ne.jp>
> > > > Signed-off-by: Michal Hocko <mhocko@suse.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.

Yes, the current behavior of GFP_NOFS is highly suboptimal, but this has
_nothing_ what so ever to do with this patch and panic_on_oom handling.
The former one is the page allocator proper while we are in the OOM
killer layer here.

This is not the first time you have done that. Please stop it. It makes
a complete mess of the original discussions.

[...]
-- 
Michal Hocko
SUSE Labs