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]

Message-ID: <20150608082137.GD1380@dhcp22.suse.cz>
Date:	Mon, 8 Jun 2015 10:21:37 +0200
From:	Michal Hocko <mhocko@...e.cz>
To:	Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp>
Cc:	rientjes@...gle.com, 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

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@...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.

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
--
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/