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 E233CC77B75 for ; Fri, 21 Apr 2023 12:34:16 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 4AE166B0071; Fri, 21 Apr 2023 08:34:16 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 45DA76B0072; Fri, 21 Apr 2023 08:34:16 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 34C6C6B0074; Fri, 21 Apr 2023 08:34:16 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 237566B0071 for ; Fri, 21 Apr 2023 08:34:16 -0400 (EDT) Received: from smtpin01.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id CBFA11603E5 for ; Fri, 21 Apr 2023 12:34:15 +0000 (UTC) X-FDA: 80705340870.01.DDC6F76 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf12.hostedemail.com (Postfix) with ESMTP id 01CB240006 for ; Fri, 21 Apr 2023 12:34:13 +0000 (UTC) Authentication-Results: imf12.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=jQqZg2GT; spf=pass (imf12.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=1682080454; a=rsa-sha256; cv=none; b=lIRYGi4xVPJjPR/HaoWFgxXNLO92a+TrypGhugEwckae5hBvzFeMJ29yWbEracVYw99ece 4/ajzutAoeLtJ82jPi8zBfbi9lUAFdeVhZuq9Snf5D3pTVVJ+v9qJG8YQbZoZQLYPe8aHq gem7TSKvKmRX8jO4q5PzyJSx5adYxlA= ARC-Authentication-Results: i=1; imf12.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=jQqZg2GT; spf=pass (imf12.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=1682080454; 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=1haxlzCv/f8FqKT7FyZKFd0EDU9AOrrVwwh7RS7GLUg=; b=H425RE55T43sZUKzQRdN7+4OSpPbzD3D1y+QwZPwbIy8Eqi+bB+P1CIJw9rghP8OV2Jfq1 UjoGTrXfac54wOSQwzJk08r2PCiHfIHbwe6s4+D/40qb3ka9stVgNJy/CbWoB2jknfSc2n SK1BsZphaMbcOvkSEyTrfrUFD0e/OaI= 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 18A8B6164E; Fri, 21 Apr 2023 12:34:13 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0BC6CC433EF; Fri, 21 Apr 2023 12:34:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1682080452; bh=dga946Vepdsucpib1+Glr81GFaUTdbLG8Bi6ScDe4AY=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=jQqZg2GTAinua+owig+UtrJA/FKBo1ElJAOoFumWoQzBrbWlVtgHvvAn6ZGJdQuo7 txafkmE068ErUUClnxY5s7FZaszkCvXhxxo/KkO6BxMMGdyDhh3pV0Is8K1RWFX5K8 Qx38FQm9LdQIIfA3MB0dUo1B3cfBNkC838OHH5KNdBzGxecp53DekM7FBXXXPS391z CL/ekfrjIDu80aaEJz478cwbp27a9hb7ZKIGsbEK0OlBcP4nRf/JjgqqP3kl9FOBdA ZGwK6HuJqjcVmcj4IdAJtMzWA0r1fBtOBqx6jrvhduRmHb645kUwl+VVoTVYuhxCVe o211objNRUG8g== Date: Fri, 21 Apr 2023 14:34:07 +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: <20230421123407.yqkety2r7ijkchvf@andromeda> References: <20230420080359.2551150-1-cem@kernel.org> <20230420080359.2551150-7-cem@kernel.org> <20230420143954.asmpkta4tknyzcda@quack3> <20230421102042.re3mij2avpvyilek@andromeda> <20230421104743.ieehvkcjw3vxy3qe@quack3> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230421104743.ieehvkcjw3vxy3qe@quack3> X-Rspam-User: X-Rspamd-Queue-Id: 01CB240006 X-Rspamd-Server: rspam01 X-Stat-Signature: u63djjy34dippsxeuz1n5zd7ff8fd8kd X-HE-Tag: 1682080453-982393 X-HE-Meta: U2FsdGVkX18fx1dUPUvWn3vtDoiDYPg1h+gdQx2VSi7D1tPGCWBINQC32oEhfMDi+vsFMjWKySJYiXT+e4/6wSrziutrctPBhj0hVX7P7bCyh+E7SdTRpvfT6j27DohZkYsH9UdvlXfl7HMiC1ZkFI140RB6XUi7yecONO6QIOQXvrFFv8knA9t8rygQ4Ddlia0xZeMVsi61aXb3QeW3X8yEWBwJpfDJ/ejMA+ccc3ELNf8BG/2DHk3Dg73IGkK9kiNuVbitPUZH8lwxua3vNfQB+CTA6yyS3kDAVIcoD8Q3dI1CDqMTWNgP+XyqySmfIk5r1z+iaK9/voQChl+bNaPRneChbf/lsjBzcpqj8YaZAQjzluJqX7FlRC62CpWQa4ZqepzxikECnM7HK8zj70G/bC7uztTeR/HP/v32QpBmLPLrJ33p0FU8aC+TEHi/nq7DlDeGa4N78sqCxa66063PXZ5ig0AKjmbuWvTGgNYXhOlNFyIBC2HT4mWW5HnwaALoJjY0NPouF0Q3MzMC5ex/CWa2Pnlb1UsQDpbSAhb/Y1WHaU1UapoMxSOeJQgZbjuOncRJdctnma9MXLds1nz+w+9YpJnusILBxuSMbLVh1yP1yIMZ7ysM4BHAYeeGwiCHPaVDHRm4C+TzULrY9GzsKdnK59XYDBBkKKLdm4bfU8H6DYtyHBlGNS3DQ0ObkvESXzceFjy3yMdCU6Jc0KD0LvrwyWWpL7iI/O/QZxZjqks+/f3epw4ufpv2+4DQsUEZPwUFbbpu3giaiUd0XzGZfs6CuSEtqdLrLR3jWP5PoKuM6LvqsgTgpEPNxwoAzGnnyhs5mUz5qzBDtzpQplac9IKgeX7s2L/hWkntJv2f9X44P4WDG8HpDo1GKpgDs+P5jafUasI3tLCkribwUve5X2QW3jELKK7bgkjEA1FhxVpOSU6ZU7bdp4gvMZ7nq4XkHuAC3D9FaPTnJL1 8eTpShWW 24LAKRkqMKnCy4h9QOBfnTxo+I2c0OZXT7EjK6lXdahyO82CclVT4UcAFfj4fJi00/ZDLa2PgIQtkwniYBKJRHKdb+Ds0B+/lnUJH+OvJs+8d9WuvYIFgcidg/0apzi/ZjKC0O9KIEi5VPfM+eX4GbzDZ8UpohHGJcnoN2NJbLfMkT9ydzv9ebr1r++Pd4Q+CJcyAVfDv3RysEW1Ic3ms1t/bXrkcLPVvimq3N9kmZKbY/knW59/rrsAYaYdHh18ExwzlOwXLlwrfV1ZV2mshMhm0kw4YnhnTvugOa4CoaCyvVwnfstrVexPqBEsimgUSDrbdfrpncQOU2D/0rvbSvw3ftRn9g1RMZwMZB4LvBeuPU23OijDeDismCMkFS7EEkqN6O66+6AzEEjcwepvTxQ2aRg== 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 Fri, Apr 21, 2023 at 12:47:43PM +0200, Jan Kara wrote: > On Fri 21-04-23 12:20:42, Carlos Maiolino wrote: > > 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: > > > > @@ -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? > > Yes, works for me! Great! > > > > 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. > > Exactly. I don't say you have to do it now as I don't think that is super > useful. But if there's a demand we can easily do it. Sounds good :) If you don't mind, I'd postpone it, as I am planning to add prjquotas to it later, I can add it to the same series, just to avoid adding more review overhead to this one. > > > > > 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? > > Yes. > > Honza > -- > Jan Kara > SUSE Labs, CR -- Carlos Maiolino