linux-kernel - Re: [PATCH] Increase default MLOCK

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: <CFRWRP3RTFT4.3VWRBA26OUSND@taiga>
Date:   Wed, 17 Nov 2021 09:23:07 +0100
From:   "Drew DeVault" <sir@...wn.com>
To:     "Andrew Morton" <akpm@...ux-foundation.org>
Cc:     "Ammar Faizi" <ammarfaizi2@...weeb.org>,
        <linux-kernel@...r.kernel.org>, <linux-api@...r.kernel.org>,
        "io_uring Mailing List" <io-uring@...r.kernel.org>,
        "Jens Axboe" <axboe@...nel.dk>,
        "Pavel Begunkov" <asml.silence@...il.com>, <linux-mm@...ck.org>
Subject: Re: [PATCH] Increase default MLOCK_LIMIT to 8 MiB

On Tue Nov 16, 2021 at 10:37 PM CET, Andrew Morton wrote:
> We're never going to get this right, are we? The only person who can
> decide on a system's appropriate setting is the operator of that
> system. Haphazardly increasing the limit every few years mainly
> reduces incentive for people to get this right.
>
> And people who test their software on 5.17 kernels will later find that
> it doesn't work on 5.16 and earlier, so they still need to tell their
> users to configure their systems appropriately. Until 5.16 is
> obsolete, by which time we're looking at increasing the default again.
>
> I don't see how this change gets us closer to the desired state:
> getting distros and their users to configure their systems
> appropriately.

Perfect is the enemy of good. This is a very simple change we can make
to improve the status quo, and I think that's worth doing. I do not have
time to develop a more sophisticated solution which steers the defaults
based on memory present, and I definitely don't have the time to
petition every distro to configure a better default for their particular
needs. This is the easiest way to get broad adoption for a better
default.