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 X-Spam-Level: X-Spam-Status: No, score=-13.3 required=3.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_IN_DEF_DKIM_WL autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id DAE32C4338F for ; Wed, 4 Aug 2021 09:15:32 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 7D6C360F14 for ; Wed, 4 Aug 2021 09:15:32 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 7D6C360F14 Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id 205918D0055; Wed, 4 Aug 2021 05:15:32 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 1B5C58D002D; Wed, 4 Aug 2021 05:15:32 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0A4F18D0055; Wed, 4 Aug 2021 05:15:32 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0104.hostedemail.com [216.40.44.104]) by kanga.kvack.org (Postfix) with ESMTP id E1E2D8D002D for ; Wed, 4 Aug 2021 05:15:31 -0400 (EDT) Received: from smtpin15.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 9FEA88249980 for ; Wed, 4 Aug 2021 09:15:31 +0000 (UTC) X-FDA: 78436840062.15.1BE4192 Received: from mail-oi1-f170.google.com (mail-oi1-f170.google.com [209.85.167.170]) by imf28.hostedemail.com (Postfix) with ESMTP id 5439E9006087 for ; Wed, 4 Aug 2021 09:15:31 +0000 (UTC) Received: by mail-oi1-f170.google.com with SMTP id a19so2135069oiw.6 for ; Wed, 04 Aug 2021 02:15:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=date:from:to:cc:subject:in-reply-to:message-id:references :mime-version; bh=h7Zb2A6Dh35OWvvMLuElewoKlDVEdIPG861c8z8d7jg=; b=Y+FPojpZ7vt4c9aS5JxHtYi18I/UZ1MIAtfN7XmXFNAKWkhc8z6zThket2NIo8OWzv o6BoeEfJUNOU/E2EOlgL44Q4WYwKCgL8OwzFH99F9XMQm5SSel14hNwv+AqmKFh46L1C 1kYt5Y5qZQQCbd/dwLuOkWY6OJGph/xf8u3TjomeEOCGyff7QYW73X1eNuTNkYLQvGv5 ZR/cHEpvqFQSWRV4hjpDNnphgts54ZHQ3cccgNqDNaVhI4CSKEqCcv+xmT4QLqpNVaTx QEFAj5r7cAVU0Tga+T52yaijY0x26+uG/kZiDest7zF2s/PQqIlz4mKUa2LMtIjVXg41 0Xaw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:in-reply-to:message-id :references:mime-version; bh=h7Zb2A6Dh35OWvvMLuElewoKlDVEdIPG861c8z8d7jg=; b=WD51XglHaiyqTN9rItjw1recgUxuWNcCOemRll9+35P33ArY23520/oJKNdyrLET/U eH3Merv/ALzgKvp2TjrutXkCEDqdvpZgxjHqgQxpPprkicJf5Ea4Y6qWy5IavugyGPV7 YklVXu03vrauyNru3Vaagw/2KjBQAemL/IYdwktVmR0womQmTMO1EaO16c4AUi/I7Pvr 7VDog6FXJc/vlE8DR2mc/TVWICh6Pi/Ba/viCVnbOAxyD5dsyj9S/DS6tE+G2fkfjpeF EnvJ5+S3Ze7gbhhWTdqho8nXotXPHkbdGMtDbMs/OYezm7gp7W3RBEktAKR9SdzoyUIw 5JkA== X-Gm-Message-State: AOAM533T1nAgQvBZf46onikF9k1IMLpmgv1oSDjJWJdVCCH36golsYAQ 2sNWg8Dl+96uF4SoPOpmkWj1Mw== X-Google-Smtp-Source: ABdhPJyiGrsvu72TeAV4c1kVT/RJj6hoqjS/aWTa8gUe1f/N1n3nzIaS/JrvT7jZLpDJKjpFi8eRxg== X-Received: by 2002:aca:6704:: with SMTP id z4mr17441159oix.89.1628068530413; Wed, 04 Aug 2021 02:15:30 -0700 (PDT) Received: from ripple.attlocal.net (172-10-233-147.lightspeed.sntcca.sbcglobal.net. [172.10.233.147]) by smtp.gmail.com with ESMTPSA id x8sm260465oof.27.2021.08.04.02.15.28 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 04 Aug 2021 02:15:29 -0700 (PDT) Date: Wed, 4 Aug 2021 02:15:26 -0700 (PDT) From: Hugh Dickins X-X-Sender: hugh@ripple.anvils To: Matthew Wilcox cc: Hugh Dickins , Andrew Morton , Shakeel Butt , "Kirill A. Shutemov" , Yang Shi , Miaohe Lin , Mike Kravetz , Michal Hocko , Rik van Riel , Christoph Hellwig , "Eric W. Biederman" , Alexey Gladkov , Chris Wilson , Matthew Auld , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, linux-api@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCH 10/16] tmpfs: fcntl(fd, F_MEM_LOCK) to memlock a tmpfs file In-Reply-To: Message-ID: <7077b94a-d894-4d97-4b3e-23f516d58591@google.com> References: <2862852d-badd-7486-3a8e-c5ea9666d6fb@google.com> <54e03798-d836-ae64-f41-4a1d46bc115b@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: 5439E9006087 Authentication-Results: imf28.hostedemail.com; dkim=pass header.d=google.com header.s=20161025 header.b=Y+FPojpZ; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf28.hostedemail.com: domain of hughd@google.com designates 209.85.167.170 as permitted sender) smtp.mailfrom=hughd@google.com X-Stat-Signature: f3ng1fwhdd3hs31ew5o7mfdyhzgftiiu X-HE-Tag: 1628068531-744563 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 Tue, 3 Aug 2021, Matthew Wilcox wrote: > On Fri, Jul 30, 2021 at 12:55:22AM -0700, Hugh Dickins wrote: > > A new uapi to lock the files on tmpfs in memory, to protect against swap > > without mapping the files. This commit introduces two new commands to > > fcntl and shmem: F_MEM_LOCK and F_MEM_UNLOCK. The locking will be > > charged against RLIMIT_MEMLOCK of uid in namespace of the caller. > > It's not clear to me why this is limited to shmfs. Would it not also > make sense for traditional filesystems, eg to force chrome's text pages > to stay in the page cache, no matter how much memory the tabs allocate? Right: if VFS people would like this to be available for all filesystems, that's fine by me - it's just that we have not given thought to other filesystems, and the demand was for tmpfs, so that was where to start. I'm more confident adding fields to shmem inode than to generic inode. (Plus tmpfs does have a stronger claim on CAP_IPC_LOCK etc, but there's no real reason why that cannot be extended to similar use by other FSs). hugetlbfs and ramfs, where the files are already memlocked? Not worth a special case, I think: if someone uses up memlock quota on them, so be it. It looks as if tmpfs would still want its own special case, just to handle the FALLOC_FL_KEEP_SIZE issue (see 12/16): tmpfs has beyond-i_size pages in memory, but accounts them evictable; whereas I doubt any storage filesystems would be using memory for them. To be clear: I'm not intending to extend this to other filesystems at the moment; but happy to do so if that's the consensus. Hugh