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 34796C433FE for ; Mon, 21 Nov 2022 14:29:22 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 978CB6B0071; Mon, 21 Nov 2022 09:29:21 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 928A96B0073; Mon, 21 Nov 2022 09:29:21 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7F0FE8E0001; Mon, 21 Nov 2022 09:29:21 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 6E3B66B0071 for ; Mon, 21 Nov 2022 09:29:21 -0500 (EST) Received: from smtpin01.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 49A47160170 for ; Mon, 21 Nov 2022 14:29:21 +0000 (UTC) X-FDA: 80157682122.01.A71D65F Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by imf03.hostedemail.com (Postfix) with ESMTP id DFA1F2000D for ; Mon, 21 Nov 2022 14:29:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1669040960; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding; bh=+GqZOZ3Ge0gmFEUW/+k13x8e6CReeYjz07m3XvBDfBs=; b=gcO03OUs+pas7HK6cbPXJKxbZ5BouhdRflKE/eV5TV1i4F61+muUWvrlnryGh0p5EE/jRI kxdLDt/B/msd7pn5DjKvKJ0Ka+jsajFZykN3q1Sp6faaUbJEnsR1ezVvYuGTHGu/22sRSD FUN+KzCocmqLCrTn112sk9WqOryNH9w= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-75-lVT5P5mzNSKrEWyssnzScA-1; Mon, 21 Nov 2022 09:29:16 -0500 X-MC-Unique: lVT5P5mzNSKrEWyssnzScA-1 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.rdu2.redhat.com [10.11.54.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 6B0A6811E84; Mon, 21 Nov 2022 14:29:16 +0000 (UTC) Received: from ovpn-193-186.brq.redhat.com (ovpn-193-186.brq.redhat.com [10.40.193.186]) by smtp.corp.redhat.com (Postfix) with ESMTP id 563162166B2E; Mon, 21 Nov 2022 14:29:15 +0000 (UTC) From: Lukas Czerner To: Hugh Dickins Cc: Jan Kara , Eric Sandeen , linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, djwong@kernel.org Subject: [PATCH v2 0/3] [RFC] shmem: user and group quota support for tmpfs Date: Mon, 21 Nov 2022 15:28:51 +0100 Message-Id: <20221121142854.91109-1-lczerner@redhat.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 3.1 on 10.11.54.6 ARC-Authentication-Results: i=1; imf03.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=gcO03OUs; spf=pass (imf03.hostedemail.com: domain of lczerner@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=lczerner@redhat.com; dmarc=pass (policy=none) header.from=redhat.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1669040961; a=rsa-sha256; cv=none; b=rsHAtbaZAqYmRDkSjTpIhJikFvVQOjpMV9pLhn7MzHauGXNffXAY0PGKLQme6KVsPiTSNO 6mR8Y31psCWcnTieLhir/go2tkZye44nU97GgT0CbYwP9fofRuK2q6EoAJz7o4+NECXljh PGwa6Ib89+wmUiURIAGXl6Gzm+FwRrg= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1669040961; 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-transfer-encoding:content-transfer-encoding: in-reply-to:references:dkim-signature; bh=+GqZOZ3Ge0gmFEUW/+k13x8e6CReeYjz07m3XvBDfBs=; b=SPETX+FUfPKcfpu6LZQKOjUM1uwLLSB0DXjVS+oBuCpVQHr8be5fDo4xDBo6fp/A7jsHAC YLInvFVjHs6tQRU+60iPinKALOnAW3LZ7KcOVzNu5/pDp1Yiz87WU2t9NafzOhCHWSVPHP sWloxp+N3jH0CuLDLZyPqyoDU2HIfHw= X-Rspam-User: Authentication-Results: imf03.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=gcO03OUs; spf=pass (imf03.hostedemail.com: domain of lczerner@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=lczerner@redhat.com; dmarc=pass (policy=none) header.from=redhat.com X-Stat-Signature: dx6r5xzbxxiwm6mow33giafhrwg8x8yd X-Rspamd-Queue-Id: DFA1F2000D X-Rspamd-Server: rspam09 X-HE-Tag: 1669040960-51523 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: 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]. Changes in v2: - Instead of using quota format QFMT_VFS_V1 with all the complexities around writing/reading quota files, instroduce new in-memory only quota format (PATCH 1/3) and use that instead as suggested by Jan Kara. - Rename global quota limits mount options to something much more sensible as suggested by Darrick J. Wong. - Improve documentation. - Check if qlobal quota limits aren't too large. -Lukas [1] https://github.com/lczerner/quota/tree/quotactl_fd_support [2] https://github.com/lczerner/xfsprogs/tree/quotactl_fd_support [3] https://github.com/lczerner/xfstests/tree/tmpfs_quota_support