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 D68B0C76188 for ; Wed, 5 Apr 2023 10:44:37 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 5B76D6B0071; Wed, 5 Apr 2023 06:44:37 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 567CC6B0072; Wed, 5 Apr 2023 06:44:37 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 42F446B007E; Wed, 5 Apr 2023 06:44:37 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 31D406B0071 for ; Wed, 5 Apr 2023 06:44:37 -0400 (EDT) Received: from smtpin26.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 015301A10DD for ; Wed, 5 Apr 2023 10:44:36 +0000 (UTC) X-FDA: 80647003794.26.14D1C49 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf03.hostedemail.com (Postfix) with ESMTP id 37C8A20022 for ; Wed, 5 Apr 2023 10:44:34 +0000 (UTC) Authentication-Results: imf03.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=mArROwVX; spf=pass (imf03.hostedemail.com: domain of cem@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=cem@kernel.org; dmarc=pass (policy=none) header.from=kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1680691475; 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=Qb2WUjkFKxiY2ZQnc8pvDWTKZhEbRix6vLMfyPk41QU=; b=1KIjOLY6M8BhctrEXkgivZ1y8yA7XYwvZlrEpzpEnJdhB5jt1oIxC7e4r2MMRqjXkw0RHE ixss1zZB6dE0AAsuANoYI5pQlVIZCwqjpvgS3p9zd5C4Jkhn+VbGjE8YA9SN1RIsenGeIC ql0ksD9wGV63IchbNRQrD80+l2TCtXA= ARC-Authentication-Results: i=1; imf03.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=mArROwVX; spf=pass (imf03.hostedemail.com: domain of cem@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=cem@kernel.org; dmarc=pass (policy=none) header.from=kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1680691475; a=rsa-sha256; cv=none; b=ShH6LR5t3WCPNBsqcI6Fk2QR9HszepZXaltauY5RW4QBASfnbe96zUQLcbJAOsM5v6JOLX FkFCTadD1jgDhrVDN2MFVxsw7+37dBuTZ6qL2fJcVEjFKouKxcoPdgV9Ju6XVP101YNXKe CudeoThnLkCKKzBsSmDYa4jmJILevlo= 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 4538763C54; Wed, 5 Apr 2023 10:44:34 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 8B140C433D2; Wed, 5 Apr 2023 10:44:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1680691473; bh=+cdhz2CMx94Qpiww/9dH8jB4BLwMUhhDy7fTZNjLdp4=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=mArROwVXu//vCpGUXIitInQ5I5HqBYxVVS748op1IiLt+II5NVOMS+E2HPHJsRR8y KYs1PhUKVicStYgO5WX6ywbOPnjWLgqJcQa0FlaUkf+lA0VNGe4rB9xVOZEtDivOao s4vmltB0aG8ReGGpaa2Qu+vpC5z5z9ZLXCQZ7JlVMNWfex7FDuuTRqTdsQlZedR63e WC+tDFK3xvHxPEgHPfNEEPK0aHbI+s9up7xnS5rXdhMgj/+6Kq9kbSi5/LXaX4uLvq HRhvnmmmw0ATD9MbqVloNXbqXFV6PlR88/0bdWvyWIoNcnP9sF5olPDNRw9fC4stxh TAAiOJy467HkA== Date: Wed, 5 Apr 2023 12:44:27 +0200 From: Carlos Maiolino To: Christian Brauner 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: <20230405104427.rndb5skuubfhucpv@andromeda> References: <20230403084759.884681-1-cem@kernel.org> <20230405-klarkommen-zellkern-03af0950b80f@brauner> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230405-klarkommen-zellkern-03af0950b80f@brauner> X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 37C8A20022 X-Stat-Signature: f14dp6g3rie8urjg8fpjc7obabjsa1dj X-Rspam-User: X-HE-Tag: 1680691474-796637 X-HE-Meta: U2FsdGVkX1+w0JgUQxApHgZc93Xn+g4UrgIL2kbRvYfDgMfO9OAYrQ3ZpQLmcAA6noGQ25a7O4+Zk0rzHM95t7ZV/JaFtagH8E459c1uIgAbF1FXPxFo20J/MzJ8IYCrgQEy+6iVcrjXjbnPEqMYheKS1Op+zOJIlDQnrF/ACExR939e0ZGF7hy8JxpLhr+CJ10rvj98I0MyWPLyDJRmFSo55fVQfT++jHHBhSIyQFUIcLzqpL7YTMDxexF/YYzOPH7imO/RcViCMH7n1lcjoMmsfFh+ciwWUe4bizHNuR67bM9X696A5/YfxNS12DS04kYMwy3Jn9dPAmZLNwv3T9Ir6zrQqJ1godLxctfgdv9uaDb4z60fmmvtC6zGODtzTNjtc+zzm1VKyeSYmwuOoNDw1pCx0DQpysNcd9qLgHakjNF/q3ihM0b03NlZb0osgftQeeb2LpcaeUgPxz3D3CYQtsyoaP/zZ+OD63LnVE5NSw7qfcoqzL5kEieHpBfy0UuoCQY15RpQEJVzWAkDIobuse7qbXteyHAJU9u3IsH0keY5qDldKHZdzQYHDVyJYiTW0BFMw9t+LbCd8Fikd0wrKtjSdb2YIh7Ts8Q9A3MQL/izFEfxKKx1czfEy1nOS/K3c5kZxpOdK88PBCgnTcCPlV/if5iOyOkNxrwFC1Qn7IStCMo4Y0DV49UWhBsE49EamUG8k1ZTtNbEVnj9EyVCxkutVuawK9hChVzreRJA+7ShmkdyCaREgEnLcz0CESPOgRCSiRc9sOtrnA7R08QYv7ZV/dFaNOMz2tKQ2BtALFMP8U5/vXEC1RMovNwOE0JDKQpz/cTPc0L096I+hCUcwk8uQOX9Ep9qzFj2ImU21pDxH+VIva8YBwT8+IBFxl3xZx64R6l5PmmBmhmzGn2H+KJycXsk27yjZIsabzI1SnJOII641xMWI/vvEsU22JsFpbe7z7dmAHp2lO0 VXEf2rn5 KKMbm8T24RyBy5RDGpDakv7t7Aeqw7sQN4f1yo62L22lOGpj7SVlJgOVglzk23fvYYEFRXoOGtVRp/s6DC8zj32szKyP9s16z17Dh5a78CVnnfgIK3/Dwz1UdAk0VfzWpqby2abSBhXYwZufwvFAIlDihJ0pW1snOTilPNjAFdnSPBNFk9Si9GBUPxqHvCwhpE9ldfsUdQdRa+DhZW9G2XavbsKsEg76BUB4rC/HFz/cRrGGzjV58uatN5tewGbLCMnsv0BsgtjL2jTS6ETQ24OgHMYakj0o/ON0B5An6ytQoi2Zbeal1f1L0Yuqcts5RHxyuRH7HXt8r5Mpi5fMtw8OZEnvFxggJgcvj/KTn7ABTeM210+NnW4sPB00vkvSJMxfF 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: Hi Christian. On Wed, Apr 05, 2023 at 10:52:44AM +0200, Christian Brauner wrote: > 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. > Thanks for the link, I've read it before, and this is by now a limitation I'd like to keep in this series. I can extend it to be namespace aware later on, but the current goal of this series is to be able tmpfs mounts on the host to limit the amount of memory consumed by users. Being namespace aware is something I plan to work later. Because as you said, it needs more testing coverage, which will only delay the main goal of this series, which again, is to avoid users to consume all memory in the host itself. > > 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 > > -- Carlos Maiolino