From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.remote-ip=100.103.45.18 ARC-Seal: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; cv=none; t=1793181347; b=hm5Yrl9ogLmMcTKpCUVei+UzApgROz5cAKyKSXzaYOgEwLBQK1dufaQdrGE1QMCsnUpK sy6E27CtVxmch3eFUb7yvn2gI7i9C4WLtGcc7v+Ue67zQ8BvYnkSWJNk2MGB1y0F8X/Vy IbzWhOboxrMIJ0od+YAOTscG3fDE9YrXyyu4W4185vEnQkBpzB4J1lVdoNTlLeQy4vjPX 1URo8D/GbpVWdhKqCwll6Y6wxpRhHyA8BaTTCVMg2Bpu4tKpR3KkH4vzp052plZ3ltuG2 SndxxVZqQaOCUB980NqYSu/r60oYdTYirfFbB7sn8ylmNKy+N3MlQuNTyu26U1WD02g== ARC-Message-Signature: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; c=relaxed/relaxed; t=1793181347; h=Received:DKIM-Signature:From:Date:Subject:MIME-Version:Content-Type: Content-Transfer-Encoding:Message-Id:References:In-Reply-To:To:Cc: X-Mailer:X-Developer-Signature:X-Developer-Key; bh=Z9eiRA9OkFCUVhYH0CVOKfXufpFXWjFThguNF2Kcag8=; b=a2QUJqQKV2xxL58BRNTlQ/rGKZeeOWDsvBacwk4IQpnTZCuL5gP8hWObAQO3DrcV81tb yKmptU9WZyEa5ejv5RIdz6d5yMyMkM9zsMnOOvmHn1L0BjxP2AzRobuze5wNvb2O8S+Y2 51SDkidI7WforTlYW9x72KnVS4aivyyQ0qlJWun/9yxBghK/GV4JtqmUW/eXJIsijOKxH j9+jzMecRz5UXXfGK0Ocbr/mAuq6EjQrJWWv7t0bjqZjvKlyqaHX4nX157yLSmGV0OgHh OAJE/7NKFPGuXmRi55PJu8HXyUmVW6Ll2Tl7OPCwFuAC06g/DUf8V4yWBGVKKHSKXfg== ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256 header.s=k20260515 header.b=B+eJfwLw; arc=none smtp.remote-ip=100.103.45.18 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (prime256v1)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id DE42F606A31E; Wed, 28 Oct 2026 09:55:46 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key, unprotected) header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256 header.s=k20260515 header.b=B+eJfwLw Received: by smtp.kernel.org (Postfix) with ESMTPSA id E5A7E1F01825; Wed, 28 Oct 2026 09:55:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1793181346; bh=Z9eiRA9OkFCUVhYH0CVOKfXufpFXWjFThguNF2Kcag8=; h=From:Date:Subject:References:In-Reply-To:To:Cc; b=B+eJfwLwaQEpxEQ8wPvorA6PpFP35jEEtTjJnBLn3AtCU8/JxR685LCoWhKO1KJnq eQl+L8nCKaLEzhvX2YOmY2n3Dxa8FyH7xr/pzfmdHTLn2qpd4B+ZUJILsEggKmRG2O 94tw04XthaJBZKwuh9pM7Dh58s6XxO0wIquUPemUGZNYw6CUcXLG4WYpwZLm685k91 dmkfR1KujkIuhZeJ9m8j4zNAd5xJgZZwbmZvm7CyeX5oTerHInRcNBWYBUjmAYzIHW BMt6B+t3H1eWnsqUPVVK4gQnKqfO+SWd2/aza/wZrS2Y//w5KxUetKDkUJzjU+5fUl WxWqB6M8ECVlw== From: "David Hildenbrand (Arm)" Date: Wed, 28 Oct 2026 10:55:01 +0100 Subject: [PATCH v3 03/15] tmpfs: preserve explicitly disabled quota limits X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Message-Id: <20261028-fixes_shmem-v3-3-4ce3baf2db4b@kernel.org> References: <20261028-fixes_shmem-v3-0-4ce3baf2db4b@kernel.org> In-Reply-To: <20261028-fixes_shmem-v3-0-4ce3baf2db4b@kernel.org> To: Andrew Morton , Gregory Price , Zi Yan , Joshua Hahn , Rakie Kim , Ying Huang , Johannes Weiner , Vladimir Davydov , Michal Hocko , Hugh Dickins , Baolin Wang , Lukas Czerner , Carlos Maiolino , Christian Brauner , Jan Kara , Daniel Verkamp , Jeff Xu , Muchun Song , Oscar Salvador , David Stevens , "Matthew Wilcox (Oracle)" , William Kucharski , Chris Li , Kairui Song , Nhat Pham , Miaohe Lin , Naoya Horiguchi Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, "David Hildenbrand (Arm)" , Josef Bacik , stable@vger.kernel.org X-Mailer: b4 0.16.0 X-Developer-Signature: v=1; a=openpgp-sha256; l=3973; i=david@kernel.org; h=from:subject:message-id; bh=mHULKBAMs4xjW0VzLP2nnjZNPWIPFmkQhWvVe2XbF4s=; b=owGbwMvMwCF2/OVpCdfQ3ZWMp9WSGLIeHmtkiX5k8Hb9o6kqH9IyoxkE2EO3y8R7fJvwL2jpl C1nw2be6ShlYRDjYJAVU2QJCr5v8PLlutpqNz5mmDmsTCBDGLg4BWAi7BkMv5i52Kr2v3XuCJk3 rz308olH3LLvFrrbX3salcmtdffBnZMMf4Ws+/iuFf18G/VOqmd6T+mlv1FVB/7XKEp8WlSmd/L TWg4A X-Developer-Key: i=david@kernel.org; a=openpgp; fpr=1BD9CAAD735C4C3A460DFCCA4DDE10F700FF835A From: Josef Bacik An administrator’s decision to disable a user’s or group’s quota limits can be silently lost when tmpfs restores the mount defaults after releasing and reacquiring the quota record. This can cause later file creation or writes to fail with EDQUOT, even though the administrator has explicitly disabled quota limits for the user or group. do_set_dqblk() sets DQ_FAKE_B when all block and inode limits are zero. This means quota enforcement is disabled for that user or group. shmem_is_empty_dquot() treats the flag as a reason to discard the entry from the mount's quota tree. The next shmem_acquire_dquot() finds no saved entry and recreates it with the mount's default hard limits. If the cached dquot is reused, DQ_FAKE_B remains set: Q_GETQUOTA reports the restored defaults, but enforcement is still disabled. Once that dquot has been reclaimed, a new dquot enforces the restored defaults. Remove the DQ_FAKE_B test. Only discard entries with zero usage, zero soft limits and hard limits equal to the mount defaults. Explicitly disabled limits are then preserved whenever the mount defaults are nonzero. Explicitly disabled limits now retain a quota-tree entry, just like other limits that differ from the mount defaults. Rename shmem_is_empty_dquot() to shmem_is_default_dquot() to describe the check for default values. Fix generated by an LLM and sent by Josef Bacik in private. Fixes: de4c0e7ca8b5 ("shmem: Add default quota limit mount options") Cc: stable@vger.kernel.org Signed-off-by: Josef Bacik Reviewed-by: Jan Kara Tested-by: Gregory Price (Meta) [ david: code cleanups; rewrite description ] Signed-off-by: David Hildenbrand (Arm) --- mm/shmem_quota.c | 30 +++++++++++++++--------------- 1 file changed, 15 insertions(+), 15 deletions(-) diff --git a/mm/shmem_quota.c b/mm/shmem_quota.c index 43d3b4fd6cb1..d191ebda3f00 100644 --- a/mm/shmem_quota.c +++ b/mm/shmem_quota.c @@ -239,7 +239,7 @@ static int shmem_acquire_dquot(struct dquot *dquot) return ret; } -static bool shmem_is_empty_dquot(struct dquot *dquot) +static bool shmem_is_default_dquot(struct dquot *dquot) { struct shmem_sb_info *sbinfo = dquot->dq_sb->s_fs_info; qsize_t bhardlimit; @@ -253,21 +253,21 @@ static bool shmem_is_empty_dquot(struct dquot *dquot) ihardlimit = sbinfo->qlimits.grpquota_ihardlimit; } - if (test_bit(DQ_FAKE_B, &dquot->dq_flags) || - (dquot->dq_dqb.dqb_curspace == 0 && - dquot->dq_dqb.dqb_curinodes == 0 && - dquot->dq_dqb.dqb_bsoftlimit == 0 && - dquot->dq_dqb.dqb_isoftlimit == 0 && - dquot->dq_dqb.dqb_bhardlimit == bhardlimit && - dquot->dq_dqb.dqb_ihardlimit == ihardlimit)) - return true; - - return false; + /* + * Defaults are zero usage and soft limits, and the mount's hard limits. + * DQ_FAKE_B only means that *all* limits are zero, which need not match + * the mount defaults. + */ + return dquot->dq_dqb.dqb_curspace == 0 && + dquot->dq_dqb.dqb_curinodes == 0 && + dquot->dq_dqb.dqb_bsoftlimit == 0 && + dquot->dq_dqb.dqb_isoftlimit == 0 && + dquot->dq_dqb.dqb_bhardlimit == bhardlimit && + dquot->dq_dqb.dqb_ihardlimit == ihardlimit; } /* - * Store limits from dquot in the tree unless it's fake. If it is fake - * remove the id from the tree since there is no useful information in - * there. + * Remove the ID from the tree if it has no usage and its limits match + * the mount defaults. Otherwise, save its limits for the next acquire. */ static int shmem_release_dquot(struct dquot *dquot) { @@ -302,7 +302,7 @@ static int shmem_release_dquot(struct dquot *dquot) return -ENOENT; found: - if (shmem_is_empty_dquot(dquot)) { + if (shmem_is_default_dquot(dquot)) { /* Remove entry from the tree */ rb_erase(&entry->node, info->dqi_priv); kfree(entry); -- 2.43.0