On Thu, Mar 10, 2022 at 01:53:39PM -0800, Darrick J. Wong wrote: > From: Darrick J. Wong <djwong@xxxxxxxxxx> > > XFS does not reserve quota for directory expansion when renaming > children into a directory. This means that we don't reject the > expansion with EDQUOT when we're at or near a hard limit, which means > that unprivileged userspace can use rename() to exceed quota. > > Rename operations don't always expand the target directory, and we allow > a rename to proceed with no space reservation if we don't need to add a > block to the target directory to handle the addition. Moreover, the > unlink operation on the source directory generally does not expand the > directory (you'd have to free a block and then cause a btree split) and > it's probably of little consequence to leave the corner case that > renaming a file out of a directory can increase its size. > > As with link and unlink, there is a further bug in that we do not > trigger the blockgc workers to try to clear space when we're out of > quota. > > Because rename is its own special tricky animal, we'll patch xfs_rename > directly to reserve quota to the rename transaction. We'll leave > cleaning up the rest of xfs_rename for the metadata directory tree > patchset. > > Signed-off-by: Darrick J. Wong <djwong@xxxxxxxxxx> > --- > fs/xfs/xfs_inode.c | 33 ++++++++++++++++++++++++++++++++- > 1 file changed, 32 insertions(+), 1 deletion(-) LGTM. Reviewed-by: Dave Chinner <dchinner@xxxxxxxxxx> -- Dave Chinner david@xxxxxxxxxxxxx
