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: <201506082053.IIF18706.JFFFHOQtMLOSVO@I-love.SAKURA.ne.jp>
Date:	Mon, 8 Jun 2015 20:53:18 +0900
From:	Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp>
To:	mhocko@...e.cz
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

Michal Hocko wrote:
> On Sat 06-06-15 15:51:35, Tetsuo Handa wrote:
> > 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.

My specific area of expertise in Linux kernel is security/tomoyo/ directory.
What I could contribute with other areas is to pay attention to potential
possibilities. But I'm such outsider about other areas that I can't
differentiate the page allocator proper from the OOM killer layer.

Excuse me for focusing on the wrong issue, but I will likely unconsciously
make the same mistake again. Please ignore or point out when I made mistakes.
--
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/