Subject: Re: [PATCH] Increase default MLOCK_LIMIT to 8 MiB
To:     David Hildenbrand <david@redhat.com>,
        Andrew Dona-Couch <andrew@donacou.ch>,
        Andrew Morton <akpm@linux-foundation.org>,
        Drew DeVault <sir@cmpwn.com>
Cc:     Ammar Faizi <ammarfaizi2@gnuweeb.org>,
        linux-kernel@vger.kernel.org, linux-api@vger.kernel.org,
        io_uring Mailing List <io-uring@vger.kernel.org>,
        Pavel Begunkov <asml.silence@gmail.com>, linux-mm@kvack.org
References: <20211028080813.15966-1-sir@cmpwn.com>
 <CAFBCWQ+=2T4U7iNQz_vsBsGVQ72s+QiECndy_3AMFV98bMOLow@mail.gmail.com>
 <CFII8LNSW5XH.3OTIVFYX8P65Y@taiga>
 <593aea3b-e4a4-65ce-0eda-cb3885ff81cd@gnuweeb.org>
 <20211115203530.62ff33fdae14927b48ef6e5f@linux-foundation.org>
 <CFQZSHV700KV.18Y62SACP8KOO@taiga>
 <20211116114727.601021d0763be1f1efe2a6f9@linux-foundation.org>
 <CFRGQ58D9IFX.PEH1JI9FGHV4@taiga>
 <20211116133750.0f625f73a1e4843daf13b8f7@linux-foundation.org>
 <b84bc345-d4ea-96de-0076-12ff245c5e29@redhat.com>
 <8f219a64-a39f-45f0-a7ad-708a33888a3b@www.fastmail.com>
 <333cb52b-5b02-648e-af7a-090e23261801@redhat.com>
From:   Jens Axboe <axboe@kernel.dk>
Message-ID: <ca96bb88-295c-ccad-ed2f-abc585cb4904@kernel.dk>
Date:   Mon, 22 Nov 2021 12:53:31 -0700
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.10.0
MIME-Version: 1.0
In-Reply-To: <333cb52b-5b02-648e-af7a-090e23261801@redhat.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Precedence: bulk

On 11/22/21 11:26 AM, David Hildenbrand wrote:
> On 22.11.21 18:55, Andrew Dona-Couch wrote:
>> Forgive me for jumping in to an already overburdened thread.  But can
>> someone pushing back on this clearly explain the issue with applying
>> this patch?
> 
> It will allow unprivileged users to easily and even "accidentally"
> allocate more unmovable memory than it should in some environments. Such
> limits exist for a reason. And there are ways for admins/distros to
> tweak these limits if they know what they are doing.

But that's entirely the point, the cases where this change is needed are
already screwed by a distro and the user is the administrator. This is
_exactly_ the case where things should just work out of the box. If
you're managing farms of servers, yeah you have competent administration
and you can be expected to tweak settings to get the best experience and
performance, but the kernel should provide a sane default. 64K isn't a
sane default.

> This is not a step into the right direction. This is all just trying to
> hide the fact that we're exposing FOLL_LONGTERM usage to random
> unprivileged users.
> 
> Maybe we could instead try getting rid of FOLL_LONGTERM usage and the
> memlock limit in io_uring altogether, for example, by using mmu
> notifiers. But I'm no expert on the io_uring code.

You can't use mmu notifiers without impacting the fast path. This isn't
just about io_uring, there are other users of memlock right now (like
bpf) which just makes it even worse.

We should just make this 0.1% of RAM (min(0.1% ram, 64KB)) or something
like what was suggested, if that will help move things forward. IMHO the
32MB machine is mostly a theoretical case, but whatever .

-- 
Jens Axboe