On Sep 24, 2025, at 8:44 AM, Amir Goldstein amir73il@gmail.com wrote:
On Sat, Sep 13, 2025 at 5:05 AM Amir Goldstein amir73il@gmail.com wrote:
From: Allison Henderson allison.henderson@oracle.com
[ Upstream commit f103df763563ad6849307ed5985d1513acc586dd ]
With parent pointers enabled, a rename operation can update up to 5 inodes: src_dp, target_dp, src_ip, target_ip and wip. This causes their dquots to a be attached to the transaction chain, so we need to increase XFS_QM_TRANS_MAXDQS. This patch also add a helper function xfs_dqlockn to lock an arbitrary number of dquots.
Signed-off-by: Allison Henderson allison.henderson@oracle.com Reviewed-by: Darrick J. Wong djwong@kernel.org Signed-off-by: Darrick J. Wong djwong@kernel.org Reviewed-by: Christoph Hellwig hch@lst.de
[amir: backport to kernels prior to parent pointers to fix an old bug]
A rename operation of a directory (i.e. mv A/C/ B/) may end up changing three different dquot accounts under the following conditions:
- user (or group) quotas are enabled
- A/ B/ and C/ have different owner uids (or gids)
- A/ blocks shrinks after remove of entry C/
- B/ blocks grows before adding of entry C/
- A/ ino <= XFS_DIR2_MAX_SHORT_INUM
- B/ ino > XFS_DIR2_MAX_SHORT_INUM
- C/ is converted from sf to block format, because its parent entry
needs to be stored as 8 bytes (see xfs_dir2_sf_replace_needblock)
When all conditions are met (observed in the wild) we get this assertion:
XFS: Assertion failed: qtrx, file: fs/xfs/xfs_trans_dquot.c, line: 207
The upstream commit fixed this bug as a side effect, so decided to apply it as is rather than changing XFS_QM_TRANS_MAXDQS to 3 in stable kernels.
The Fixes commit below is NOT the commit that introduced the bug, but for some reason, which is not explained in the commit message, it fixes the comment to state that highest number of dquots of one type is 3 and not 2 (which leads to the assertion), without actually fixing it.
The change of wording from "usr, grp OR prj" to "usr, grp and prj" suggests that there may have been a confusion between "the number of dquote of one type" and "the number of dquot types" (which is also 3), so the comment change was only accidentally correct.
Fixes: 10f73d27c8e9 ("xfs: fix the comment explaining xfs_trans_dqlockedjoin") Cc: stable@vger.kernel.org Signed-off-by: Amir Goldstein amir73il@gmail.com
Catherine and Leah,
I decided that cherry-pick this upstream commit as is with a commit message addendum was the best stable tree strategy. The commit applies cleanly to 5.15.y, so I assume it does for 6.6 and 6.1 as well. I ran my tests on 5.15.y and nothing fell out, but did not try to reproduce these complex assertion in a test.
Could you take this candidate backport patch to a spin on your test branch?
Hi Catherine/Leah,
Do you plan to do a batch of backports to 6.6.y/6.1.y anytime soon. Would you mind adding this patch to your candidates for whenever you plan to test a batch?
Thanks! Amir.
Hi Amir,
This patch looks ok to me. I’ll add it to my branch and let you know if I come across any issues. Thanks!
Catherine