linux-kernel - Re: [PATCH 1/2 v2] mm: Allow small allocations to fail

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: <201503182035.FJD69716.FMOHLOOFQFtVSJ@I-love.SAKURA.ne.jp>
Date:	Wed, 18 Mar 2015 20:35:49 +0900
From:	Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp>
To:	mhocko@...e.cz, hannes@...xchg.org
Cc:	akpm@...ux-foundation.org, david@...morbit.com, mgorman@...e.de,
	riel@...hat.com, fengguang.wu@...el.com, linux-mm@...ck.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/2 v2] mm: Allow small allocations to fail

I'm not opposing to have fundamental solutions. As you know the fundamental
solution will need many years to complete, I'm asking for interim workaround
which we can use now.

Michal Hocko wrote:
> The problem, as I see it, is that such a change cannot be pushed to
> Linus tree without extensive testing because there are thousands of code
> paths which never got exercised. We have basically two options here.

Your options are based on your proposal.
We can have different options based on Johannes's and my proposal.

> Either have a non-upstream patch (e.g. sitting in mmotm and linux-next)
> and have developers to do their testing. This will surely help to
> catch a lot of fallouts and fix them right away. But we will miss those
> who are using Linus based trees and would be willing to help to test
> in their loads which we never dreamed of.
> The other option would be pushing an experimental code to the Linus
> tree (and distribution kernels) and allow people to turn it on to help
> testing.

The third option is to purge majority of code paths which never got
exercised, by replacing kmalloc() with kmalloc_nofail() where amount of
requested size is known to be <= PAGE_SIZE bytes.

The third option becomes possible if we "allow triggering the OOM killer for
both __GFP_FS allocations and !__GFP_FS allocations" and "introduce the
OOM-killer timeout" so that OOM-deadlock which we are already observing can
be handled.
--
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/