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 1986FC77B75 for ; Fri, 21 Apr 2023 10:20:52 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 9E94B6B0071; Fri, 21 Apr 2023 06:20:51 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 9997F6B0072; Fri, 21 Apr 2023 06:20:51 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 861EF6B0074; Fri, 21 Apr 2023 06:20:51 -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 739E56B0071 for ; Fri, 21 Apr 2023 06:20:51 -0400 (EDT) Received: from smtpin10.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 381B012062D for ; Fri, 21 Apr 2023 10:20:51 +0000 (UTC) X-FDA: 80705004702.10.3F0BCD4 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf04.hostedemail.com (Postfix) with ESMTP id 8ED994000A for ; Fri, 21 Apr 2023 10:20:48 +0000 (UTC) Authentication-Results: imf04.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=KmCICkkL; spf=pass (imf04.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=1682072448; a=rsa-sha256; cv=none; b=EuIeK/Nd6ooFh4fxFQ1e7eFzA/q866gkPRIGgs327b3aVHGBSMJOdDBE+MK5VMcbRVw89Z y++hbz9uEW5zc+8aMoHpkojs7oN4i0IZ2BMewghGsM87y6mNGBNYsTPxsDi6u1/zkfRADQ wa7U2kL6VAb0ZrMZskGjn0Obmha8/c8= ARC-Authentication-Results: i=1; imf04.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=KmCICkkL; spf=pass (imf04.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=1682072448; 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=cayz8GZrT5ec8DnFmnmigIAHZNoGfQLkEB7Vl7jAN9Y=; b=yekI/3HbaiC9j09jhHc0TMYBhq+wDBXMw3c9Tg80/1FW5mPwiQBUkjnp2v7a2ifStU4tSV zq8M5QX0RzOHnEkaaiNGUPIH4GImTkzza91JR8TjF1C2j6yJ88PAP/pC2kFaLN/9beaOj7 K59iHZvU5n4TY2MRvqA8QFDbipd2MiM= 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 A7A4364FD4; Fri, 21 Apr 2023 10:20:47 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id E11C1C433D2; Fri, 21 Apr 2023 10:20:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1682072447; bh=U+b/+dv0OYfR922a/EMYngteFkuh3GpuR3Zv9Q3ESek=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=KmCICkkLosJy72kWhOppDzth2MJIEstExrYLrBBHcCaEgIF/n4ahjneFu1HSi3vUY 7R5utZNCdp3igQoscobbD2Ed1mqJwW0DKco+HIat+khI9Ua7S8iB5+fvNPfI831JYG fpzrtfjXnh9MqHW0rYmOCWoSG1+RyS6RbIbGKgrwGtmfY1KtvPSW9gMgrqYCUXiOQ8 eYMBYVlfI65bQdgC1faM830cmGuUWKBqBL1XMb1UooKhW1AhppMnZExzPHaCPnKoq4 zkGyewghBpmny80Puyf2rDTWqEw++BRWqHpQFxuGv07sOXwMyevvpFs+q8HcFSk8g5 BbEQduAkBs5qQ== Date: Fri, 21 Apr 2023 12:20:42 +0200 From: Carlos Maiolino To: Jan Kara Cc: hughd@google.com, linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, djwong@kernel.org Subject: Re: [PATCH 6/6] Add default quota limit mount options Message-ID: <20230421102042.re3mij2avpvyilek@andromeda> References: <20230420080359.2551150-1-cem@kernel.org> <20230420080359.2551150-7-cem@kernel.org> <20230420143954.asmpkta4tknyzcda@quack3> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230420143954.asmpkta4tknyzcda@quack3> X-Rspam-User: X-Rspamd-Queue-Id: 8ED994000A X-Rspamd-Server: rspam01 X-Stat-Signature: ku3j1ntx5i5gbogort7paondsm4tjtpz X-HE-Tag: 1682072448-922226 X-HE-Meta: U2FsdGVkX1+yquVxHoHFqIXLoYkrYn/b/Jebn9MqMqsblpCQOYZHpavTS+560w1Cse/v1OcZs8AxBgqeZUi8bXWoUTKtTAaSppd4ROEhIQt6VgQKoZkT6qf3pq8D42j5mlUfdB8Dij3aE7R4SrHNj5QafMz4FV3FF1O5hK5t5T32IvrnMhW+Bklf/fAYfflV3sZkIqz/ff09XdTejfcf5XymgYP7q+res/U/LetdrDuvtG7rd+Ax/I6k0uVsZRZA2PeVpQ6O3DwBydcZKiQ6lCnksaJq2KexiC5s5raYRp6+e5yjbOkSJ+Xzjh0Hc+HeWOgctkPBmMqjjNk37IfeNRb4uUgqPKHWXKOct3EQADPp2Gg7fGz63PxaNr9OQ5+5sydrOBnwmAnjAUUdXocOy4w/ejMA3YQuVyLRceZpVWCe2gzkZgG9WKBykD4AJppChsRj25N7KgNJRhmuycNITjr7+Xn6UqnaBFpJj689J+1vDXdQvUl+v0eLr7pCYisU+bWQr1ddzqd3BD+MD+yfQQDdX2VL6zCF8IQMqorNHAh7xKxl11972CDrNSb/rPujsDQ95h+RPR2s2bhYF+O4Y99ydGhTS4Z91SlKcfAAR+cLrZK6sq/ikz1BG3Jg806GRD/sBBPxWelTHYT8w2jhXz773OT/vb0RPg2eGbAQQLncvldDfPDsmxGWVE+wH0BQeooiu+sOBpfd8A/WFFigDOBQw9kd2at6CnHPmCE8ziX+wT/luTUx7v/NEoV2XfUqUprnW9Wujmh/OjQ5ailirccYREJI4Ne39F1bCQSUjC3fIvQ60al3vUjj/dtNLWk3UwKnKQM39PJK8AUqg6wS7papfUgLTzgp/Q/jTj3pYPZs5aOIqg0OwHMju5RxQkLlbSH2KWUlY7ITRC5OfqalWdX3etAKZKCTHNA/RexX8AP3aCzyxoUMYyGwWAgm1V3eB3xeaiVDQfN1ot8r5gG P1MqtVz8 IoSI9Gl6X7Hp3FiLNebbfCcb/qnLS69+PlmD0FOmPipITbapYzuUHyVNtNoKdaibQPdjxz895G4ZT7HZPQZb/lhGUPDGNRsUEtgBVHVfQrDR9rH+NVrN3rvrQ8RrcQynlXo8zNkc9JfogoDv79Jftj/YPWEnlW9X5Zq8T6aORv+qDOTYuCzPdNMyWVFCGTr89vPwzzYf0tHpHUWTNE/CFxtWP+4nA6UtOy4/qxJVnEl5lBXoBFoECrFNlQ7tX0CIzbHDdJNSAhtJEDjfH/hDwR5bt5oK1KU2tzdI+3VLOvyCwekmO2FAdfb+UL1pbOHNclm3m7foPcMwfdRFQoGTx721LmGVOpF0uHTOkWrah7+eUQLnMXENtpAxHD3WushMjHveXoSQUYCH91rgb0BRrrHzmQKaR74Qu41rCTbq2yyEz4ag= 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 Thu, Apr 20, 2023 at 04:39:54PM +0200, Jan Kara wrote: > On Thu 20-04-23 10:03:59, cem@kernel.org wrote: > > From: Lukas Czerner > > > > Allow system administrator to set default global quota limits at tmpfs > > mount time. > > > > Signed-off-by: Lukas Czerner > > Signed-off-by: Carlos Maiolino > > --- > > Documentation/filesystems/tmpfs.rst | 34 ++++++++++---- > > include/linux/shmem_fs.h | 8 ++++ > > mm/shmem.c | 69 +++++++++++++++++++++++++++++ > > mm/shmem_quota.c | 9 ++++ > > 4 files changed, 111 insertions(+), 9 deletions(-) > > > > diff --git a/Documentation/filesystems/tmpfs.rst b/Documentation/filesystems/tmpfs.rst > > index 1d4ef4f7cca7e..241c11f86cd73 100644 > > --- a/Documentation/filesystems/tmpfs.rst > > +++ b/Documentation/filesystems/tmpfs.rst > > @@ -88,15 +88,31 @@ that instance in a system with many CPUs making intensive use of it. > > > > tmpfs also supports quota with the following mount options > > > > -======== ============================================================= > > -quota User and group quota accounting and enforcement is enabled on > > - the mount. Tmpfs is using hidden system quota files that are > > - initialized on mount. > > -usrquota User quota accounting and enforcement is enabled on the > > - mount. > > -grpquota Group quota accounting and enforcement is enabled on the > > - mount. > > -======== ============================================================= > > +======================== ================================================= > > +quota User and group quota accounting and enforcement > > + is enabled on the mount. Tmpfs is using hidden > > + system quota files that are initialized on mount. > > +usrquota User quota accounting and enforcement is enabled > > + on the mount. > > +grpquota Group quota accounting and enforcement is enabled > > + on the mount. > > +usrquota_block_hardlimit Set global user quota block hard limit. > > +usrquota_inode_hardlimit Set global user quota inode hard limit. > > +grpquota_block_hardlimit Set global group quota block hard limit. > > +grpquota_inode_hardlimit Set global group quota inode hard limit. > > +======================== ================================================= > > + > > +None of the quota related mount options can be set or changed on remount. > > + > > +Quota limit parameters accept a suffix k, m or g for kilo, mega and giga > > +and can't be changed on remount. Default global quota limits are taking > > +effect for any and all user/group/project except root the first time the > > +quota entry for user/group/project id is being accessed - typically the > > +first time an inode with a particular id ownership is being created after > > +the mount. In other words, instead of the limits being initialized to zero, > > +they are initialized with the particular value provided with these mount > > +options. The limits can be changed for any user/group id at any time as it > ^^ they > > +normally can. > ^^^ can be > Thanks! > > @@ -3714,6 +3723,50 @@ static int shmem_parse_one(struct fs_context *fc, struct fs_parameter *param) > > ctx->seen |= SHMEM_SEEN_QUOTA; > > ctx->quota_types |= QTYPE_MASK_GRP; > > break; > > + case Opt_usrquota_block_hardlimit: > > + size = memparse(param->string, &rest); > > + if (*rest || !size) > > + goto bad_value; > > + if (size > SHMEM_QUOTA_MAX_SPC_LIMIT) > > + return invalfc(fc, > > + "User quota block hardlimit too large."); > > + ctx->qlimits.usrquota_bhardlimit = size; > > + ctx->seen |= SHMEM_SEEN_QUOTA; > > + ctx->quota_types |= QTYPE_MASK_USR; > > So if I get it right, the intention here is that if > usrquota_block_hardlimit=value option is used, it automatically enables > user quota accounting and enforcement. I guess it is logical but it is not > documented and I'd prefer to require explicit usrquota mount option to > enable accounting & enforcement - it is then e.g. easier to parse mount > options (in userspace) for finding out whether enforcement is enabled or > not. Hmmm, I think I see what you mean. I can make usrquota_block_hardlimit options to not actually set the quota flag on quota_types, so this should be explicitly set by usrquota/grpquota options. Does that work for you? > Also I can imagine we would allow changing the default limits on > remount but it isn't easy to enable quota accounting on remount etc. > hmm, yes, maybe enabling default limits to be changed on remount isn't a big deal, once the quota is already enabled, so everything is already in place. > > diff --git a/mm/shmem_quota.c b/mm/shmem_quota.c > > index c0b531e2ef688..3cc53f2c35e2c 100644 > > --- a/mm/shmem_quota.c > > +++ b/mm/shmem_quota.c > > @@ -166,6 +166,7 @@ static int shmem_acquire_dquot(struct dquot *dquot) > > { > > struct mem_dqinfo *info = sb_dqinfo(dquot->dq_sb, dquot->dq_id.type); > > struct rb_node **n = &((struct rb_root *)info->dqi_priv)->rb_node; > > + struct shmem_sb_info *sbinfo = dquot->dq_sb->s_fs_info; > > struct rb_node *parent = NULL, *new_node = NULL; > > struct quota_id *new_entry, *entry; > > qid_t id = from_kqid(&init_user_ns, dquot->dq_id); > > @@ -195,6 +196,14 @@ static int shmem_acquire_dquot(struct dquot *dquot) > > } > > > > new_entry->id = id; > > + if (dquot->dq_id.type == USRQUOTA) { > > + new_entry->bhardlimit = sbinfo->qlimits.usrquota_bhardlimit; > > + new_entry->ihardlimit = sbinfo->qlimits.usrquota_ihardlimit; > > + } else if (dquot->dq_id.type == GRPQUOTA) { > > + new_entry->bhardlimit = sbinfo->qlimits.grpquota_bhardlimit; > > + new_entry->ihardlimit = sbinfo->qlimits.grpquota_ihardlimit; > > + } > > + > > new_node = &new_entry->node; > > rb_link_node(new_node, parent, n); > > rb_insert_color(new_node, (struct rb_root *)info->dqi_priv); > > Maybe in shmem_dquot_release() when usage is 0 and limits are at default > limits, we can free the structure? hmmm, which struct are you talking about? quota_id? As we do for DQ_FAKE? > > Honza > -- > Jan Kara > SUSE Labs, CR -- Carlos Maiolino