linux-kernel - Re: [PATCH] Revert "kmemleak: allow to coexist with fault injection"

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] [day] [month] [year] [list]

Message-Id: <00205B2E-36E0-4169-997B-B9A522482CD1@lca.pw>
Date:   Sat, 27 Jul 2019 07:48:09 -0400
From:   Qian Cai <cai@....pw>
To:     Catalin Marinas <catalin.marinas@....com>
Cc:     Yang Shi <yang.shi@...ux.alibaba.com>, mhocko@...e.com,
        Dmitry Vyukov <dvyukov@...gle.com>, rientjes@...gle.com,
        willy@...radead.org, Andrew Morton <akpm@...ux-foundation.org>,
        linux-mm@...ck.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] Revert "kmemleak: allow to coexist with fault injection"



> On Jul 27, 2019, at 6:13 AM, Catalin Marinas <catalin.marinas@....com> wrote:
> 
> On Tue, Jul 16, 2019 at 02:23:30PM -0400, Qian Cai wrote:
>> As mentioned in anther thread, the situation for kmemleak under memory pressure
>> has already been unhealthy. I don't feel comfortable to make it even worse by
>> reverting this commit alone. This could potentially make kmemleak kill itself
>> easier and miss some more real memory leak later.
>> 
>> To make it really a short-term solution before the reverting, I think someone
>> needs to follow up with the mempool solution with tunable pool size mentioned
>> in,
>> 
>> https://lore.kernel.org/linux-mm/20190328145917.GC10283@arrakis.emea.arm.com/
> 
> Before my little bit of spare time disappears, let's add the tunable to
> the mempool size so that I can repost the patch. Are you ok with a
> kernel cmdline parameter or you'd rather change it at runtime? The
> latter implies a minor extension to mempool to allow it to refill on
> demand. I'd personally go for the former.

Agreed. The cmdline is good enough.