From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id CD8EEC433EF for ; Mon, 22 Nov 2021 19:54:00 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 3A8326B0071; Mon, 22 Nov 2021 14:53:45 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 330D56B0072; Mon, 22 Nov 2021 14:53:45 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1A99F6B0073; Mon, 22 Nov 2021 14:53:45 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0006.hostedemail.com [216.40.44.6]) by kanga.kvack.org (Postfix) with ESMTP id 089BF6B0071 for ; Mon, 22 Nov 2021 14:53:45 -0500 (EST) Received: from smtpin02.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id B723289B28 for ; Mon, 22 Nov 2021 19:53:34 +0000 (UTC) X-FDA: 78837615948.02.ECE9A90 Received: from mail-il1-f180.google.com (mail-il1-f180.google.com [209.85.166.180]) by imf17.hostedemail.com (Postfix) with ESMTP id 30B8CF0001CD for ; Mon, 22 Nov 2021 19:53:34 +0000 (UTC) Received: by mail-il1-f180.google.com with SMTP id j7so12012190ilk.13 for ; Mon, 22 Nov 2021 11:53:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel-dk.20210112.gappssmtp.com; s=20210112; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=aYWRo4OnMSjtGg0tX+Mk+QuvsqmMl0X/zqqUxoDxPuQ=; b=qoIiOgAz8Ked6kslZpQ1ZXKr3ZWose+cMbN8e9bUt2W9tM31pFZfHHWfthnKAumbo/ 1iP0vPgfFO1apG/C8gEGIo6yTpnJ6JPgdrRwSgIAqStCoogmfCmweTHT/YQQ469eLX23 T8Y3uvEi8+aNAfk3DCwP1TzSgZHmy0qJS7/uXfgkgcGEtpsWhdMTngaYY9BXV/61i+a9 SW3V5XEHG8wSYxT+88+G0ie4lIJuZ7yx4a4nP+IW2R8k4nXEHpHA/nr+9jVYIUaUwrL5 QBGPVGnUUFY7x+w4KS7oAAv5gRkF+1rM3ZekVRyRutgpFYSnbxMpoeLU9UOr6l6yh2zs LMgg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=aYWRo4OnMSjtGg0tX+Mk+QuvsqmMl0X/zqqUxoDxPuQ=; b=I9AELINpaOTjsYYbwiVV/1kYRXdYBsi4/CWZrUSBMjAPuYCWQnJyu6fTjEQjZwZIEP 5keIva1FVlnRkWBvvJyQj6d5sKPg0jaznyoTthU+egbLpeX5xU/AtQH7Ja0gR945Mybf R01UQl8fAJSyjvMRB8jSH1jOkEWCP5ZSX420yxgRyAyPwVmH/olo6b/a1NvAr7qvYa9a VK09Y0QEJiVU6ay1Qkebew+erxs7WW70OpUaCRRSI315IPdVbaJxMYZ1zr15qTvK6dzM Nhp9Jqe13NKdCqtv0x6IkeHLibWwOBpK5JMMn/+6iFA3+CAlsqAcgj/hWM0fLwegw6xa X0AQ== X-Gm-Message-State: AOAM532hZ3U4tk1YWdcX/sdYccxzlKA84C/nvWPUVxLeVs7kppZkyJJZ QbRpH9wCsa+bSMKIzjjPSfK2u6M8sHGixCPU X-Google-Smtp-Source: ABdhPJwP3wYrRTZQJ8HHrsPBlUltYe5Z5Bf7eDFAFZOy32OsoOlu2fOqGFaq9YOGEZF+8WYUctP5NQ== X-Received: by 2002:a05:6e02:1563:: with SMTP id k3mr21659500ilu.256.1637610813112; Mon, 22 Nov 2021 11:53:33 -0800 (PST) Received: from [192.168.1.30] ([207.135.234.126]) by smtp.gmail.com with ESMTPSA id a25sm5389768ioa.24.2021.11.22.11.53.32 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 22 Nov 2021 11:53:32 -0800 (PST) Subject: Re: [PATCH] Increase default MLOCK_LIMIT to 8 MiB To: David Hildenbrand , Andrew Dona-Couch , Andrew Morton , Drew DeVault Cc: Ammar Faizi , linux-kernel@vger.kernel.org, linux-api@vger.kernel.org, io_uring Mailing List , Pavel Begunkov , linux-mm@kvack.org References: <20211028080813.15966-1-sir@cmpwn.com> <593aea3b-e4a4-65ce-0eda-cb3885ff81cd@gnuweeb.org> <20211115203530.62ff33fdae14927b48ef6e5f@linux-foundation.org> <20211116114727.601021d0763be1f1efe2a6f9@linux-foundation.org> <20211116133750.0f625f73a1e4843daf13b8f7@linux-foundation.org> <8f219a64-a39f-45f0-a7ad-708a33888a3b@www.fastmail.com> <333cb52b-5b02-648e-af7a-090e23261801@redhat.com> From: Jens Axboe Message-ID: 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 X-Rspamd-Queue-Id: 30B8CF0001CD X-Stat-Signature: 6p7bn59rp3jctazpjz69j6myjemw73ry Authentication-Results: imf17.hostedemail.com; dkim=pass header.d=kernel-dk.20210112.gappssmtp.com header.s=20210112 header.b=qoIiOgAz; dmarc=none; spf=pass (imf17.hostedemail.com: domain of axboe@kernel.dk designates 209.85.166.180 as permitted sender) smtp.mailfrom=axboe@kernel.dk X-Rspamd-Server: rspam02 X-HE-Tag: 1637610814-623379 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: 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