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 A7901C7619A for ; Wed, 5 Apr 2023 08:52:55 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 1AF1C6B0074; Wed, 5 Apr 2023 04:52:55 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 15F0A6B0078; Wed, 5 Apr 2023 04:52:55 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0007E6B007B; Wed, 5 Apr 2023 04:52:54 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id E4CB16B0074 for ; Wed, 5 Apr 2023 04:52:54 -0400 (EDT) Received: from smtpin09.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 9D8E74105A for ; Wed, 5 Apr 2023 08:52:54 +0000 (UTC) X-FDA: 80646722268.09.F49413A Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf12.hostedemail.com (Postfix) with ESMTP id E357E4000E for ; Wed, 5 Apr 2023 08:52:50 +0000 (UTC) Authentication-Results: imf12.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=KW5wp09o; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf12.hostedemail.com: domain of brauner@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=brauner@kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1680684771; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=FlX49Bnjrnf38rg7i7w2emnUxHoGnOsdQySbKSJvjR4=; b=1YY9M395qLnE9t+Yl2ssm0IYfo8T4GWSH242Ov/TmeRjU4yLC94llk5RroA3efbNyFnrn3 uZXn+P5uAKNyTOf3fJahAXd7BeZk3ePgxjahW0y4ZkLDFj9TzQ/EhiYNJeXASOTDB93QOF QZTfwpdVR9dvqqY9dzMszrJ0XXvZJCE= ARC-Authentication-Results: i=1; imf12.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=KW5wp09o; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf12.hostedemail.com: domain of brauner@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=brauner@kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1680684771; a=rsa-sha256; cv=none; b=2bWdN02k9hwuDxzwxdq2GEXofn0AxoYjbIwsxTxT0ihWvT06Ii85V2+EW9b9zOiH524u9J Yove2nV//CRIxdJBzDGSLHe8yAQBIUYsi2n1Y0G4Om6clNW9OffPgVXFwoMU1yINQ1gp3E DkaRbiwlFBP0YUfOCqqNcOEXsaQGPc8= Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id DA8F76250D; Wed, 5 Apr 2023 08:52:49 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 78696C433EF; Wed, 5 Apr 2023 08:52:47 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1680684769; bh=wYgRmC8GHygAyGX9rI+0LgBMbN+B6EtuGOcgW3nxjjM=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=KW5wp09ogccYlGl2btqkOVLVWsWyHLw3Ty3dy6n9wJyx+4B3AYDub8WdUX+YlJg1m E/vj3Rcvp63JEGim++24FcL1N8TyBYr2Aw5JWm9XLpRjAh53nLa3lCzOejwqH5MwKi nuLKnxrPuUwBaTDBjVFNsXpIeaXaKb8SKJWfDblVqIVN+BxCLGusFWt/UB8bnix9/1 gnsamDqAN01klfi4OQav+my7V/097GE2/1OXzWf7JvOKvjg9LKyJiyhxEErIcH8DkH JtBsqka1NFmVKaTGpkO0T7i4Xi95ow0CBHhRh8JZbLWb1iZT4a345a7DjrLpfAhsOb fYoWH93OCByoA== Date: Wed, 5 Apr 2023 10:52:44 +0200 From: Christian Brauner To: cem@kernel.org Cc: hughd@google.com, jack@suse.cz, linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, djwong@kernel.org Subject: Re: [PATCH 0/6] shmem: Add user and group quota support for tmpfs Message-ID: <20230405-klarkommen-zellkern-03af0950b80f@brauner> References: <20230403084759.884681-1-cem@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20230403084759.884681-1-cem@kernel.org> X-Rspamd-Queue-Id: E357E4000E X-Rspamd-Server: rspam09 X-Rspam-User: X-Stat-Signature: b6bqfxtuyipuyjusd7hswztgkntxe87d X-HE-Tag: 1680684770-261434 X-HE-Meta: U2FsdGVkX18EocDefFz1OXkIqXbLC7ZJRw/GSnEjcWHu5J9JDRZCgmFX+ZhznWexy7cR6uVv6rRnRPwuUhoLu2C2P0krjt6URCeAeQ952U5AGNgRHsgqqAnJ56VuavjJRhX5yLL3llVa44Rg6yZFlGuVrywjhH0uFYdYk3z2kyUBzVO1DgvMya+E7PulO1ZQ+vqBnw/kZpjJdZgUgeV9q/QpP//1DCZf7Pwc6ZVS59LSFHjFmQtCrl0P420za9DJ/+V405LicGJGRq+t+8qSSUCKdOnJorNolX6rXVRkGw/pGRCI/3OE8fVg9zFeOrABz+g/86DuXnlNzP4Z59JMPByHF/pPYbgppJDsvRCnhRLxvoRdVzSTW2eufEDEtcpGzL4Pr7LeXF80gen1MoKiziaIYEOZd/6r5M+kzofxeI1zWCAB02m7qAae9Hae9MxRuy5VRb2bFesqLEeilw2u2ZJEhxyKIdFvcl4npWLCFuC6yp1JCi3ajE2l0zMKE3Vc8i/J0IgqhqfJFCAfJNs0cKiCKvHh/k5BHa/f36sFZyqZ6thQOpALgFiKpfUBxzA16kfhoieP55QWhHp57aui5usxYfwCdkdlJo9nOe8tdIYVz7GwjtQuheAQGtkBGMhV4MWm5Pw7e4D088jWg2hu6GNehxAErHnjRPO4HA+uzy911zV6jx1JjXOgkCSCuLTpcaIScDewMauiHbV0jQ/j6Br5rFZNgyYMvCTP/7MuWbX9gXZKpwEX4AWFMUVlDJDX2x5a7wpjzykuk5BkIzxHR93S5cGF6XDL8SW6zV/k/7Y5FTqj8ETwXz5QWp7Rw45K+wHmLzvlGDybjIyNvv32MHwED7Itr1cdT6lkqb3DYS2x02wMAVBVFnOBnKJGoY7AIy0lqCaGE2hPWNEHochFP2XXuKJYud5ONteUX4iSfcqDDH3YPN+fdMpXmj9fNzKDEEK0uz0bU76VXRltuXg d4Jhpwnt cOFNWns+Vj1oAHljW3xmaLrHIVLTQ3xPbUt9GkgyjdAaBnQiZONq/8sRhodTVw2CpSYBtRJ1TV85/B7jMxSfC19lgIXDMf1/Dx31qBLQ9JmAceUJX+7sTIx1syKfQ7LUrs60Df3drOcarANlXI5QftH3XILFVORpJx0JzukeJaidQD1MG4yImj3J7+zCAJzjzg2VEZLnAFzPbQlLPe3/XwvhlPvHFZ/qvsZDw+/EwvX1mKiUIED3961ld4N2Qm99t2P0qjcETdkmkBsthNSaIte5/rNUMg1dwMkuhTZyNyBN12yNZK+r7B9IYZ8xuhc4htux3I3tZu+bQ5yOSpP/H3Rz8Fg/EbM7mBIme7zYjLaDrShqzxjIUKA7j67qmHKLTSiOt 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 Mon, Apr 03, 2023 at 10:47:53AM +0200, cem@kernel.org wrote: > From: Carlos Maiolino > > Hi folks. this work has been done originally by Lukas, but he left the company, > so I'm taking over his work from where he left it of. This series is virtually > done, and he had updated it with comments from the last version, but, I'm I've commented on the last version: https://lore.kernel.org/linux-fsdevel/20221129112133.rrpoywlwdw45k3qa@wittgenstein trying to point out that tmpfs can be mounted in user namespaces. Which means that the quota uids and gids need to take the idmapping of the user namespace in which the tmpfs instances is mounted in into account; not the one on the host. See the link above for some details. Before we can merge this it would be very good if we could get tests that verify tmpfs being mounted inside a userns with quotas enabled because I don't think this is covered yet by xfstests. Or you punt on it for now and restricted quotas to tmpfs instances mounted on the host. > initially posting it as a RFC because it's been a while since he posted the > last version. > Most of what I did here was rebase his last work on top of current Linus's tree. > > Honza, there is one patch from you in this series, which I believe you had it > suggested to Lukas on a previous version. > > The original cover-letter follows... > > people have been asking for quota support in tmpfs many times in the past > mostly to avoid one malicious user, or misbehaving user/program to consume > all of the system memory. This has been partially solved with the size > mount option, but some problems still prevail. > > One of the problems is the fact that /dev/shm is still generally unprotected > with this and another is administration overhead of managing multiple tmpfs > mounts and lack of more fine grained control. > > Quota support can solve all these problems in a somewhat standard way > people are already familiar with from regular file systems. It can give us > more fine grained control over how much memory user/groups can consume. > Additionally it can also control number of inodes and with special quota > mount options introduced with a second patch we can set global limits > allowing us to replace the size mount option with quota entirely. > > Currently the standard userspace quota tools (quota, xfs_quota) are only > using quotactl ioctl which is expecting a block device. I patched quota [1] > and xfs_quota [2] to use quotactl_fd in case we want to run the tools on > mount point directory to work nicely with tmpfs. > > The implementation was tested on patched version of xfstests [3]. > > > Jan Kara (1): > quota: Check presence of quota operation structures instead of > ->quota_read and ->quota_write callbacks > > Lukas Czerner (5): > shmem: make shmem_inode_acct_block() return error > shmem: make shmem_get_inode() return ERR_PTR instead of NULL > shmem: prepare shmem quota infrastructure > shmem: quota support > Add default quota limit mount options > > Documentation/filesystems/tmpfs.rst | 28 ++ > fs/Kconfig | 12 + > fs/quota/dquot.c | 2 +- > include/linux/shmem_fs.h | 25 ++ > include/uapi/linux/quota.h | 1 + > mm/Makefile | 2 +- > mm/shmem.c | 452 +++++++++++++++++++++------- > mm/shmem_quota.c | 327 ++++++++++++++++++++ > 8 files changed, 740 insertions(+), 109 deletions(-) > create mode 100644 mm/shmem_quota.c > > -- > 2.30.2 >