Incorrect user quota handling in fallocate

[Martin Svec <martin.svec@zoner.cz>]

Hi all,

I've found a bug in XFS user quota handling in two subsequent fallocate() calls. This bug can be
easily reproduced by the following script:

# assume empty XFS mounted on /mnt/testxfs with -o usrquota, grpquota

FILE="/mnt/testxfs/test.file"
USER="testuser"

setquota -u $USER $QUOTA $QUOTA 0 0 -a
touch $FILE
chown $USER:users $FILE
fallocate --keep-size -o 0 -l $FILESIZE $FILE
fallocate -o 0 -l $FILESIZE $FILE

That is, we create an empty file, preallocate requested size while keeping zero file size and then
call fallocate again to set the file size. Assume that there's enaugh free quota to fit the
requested file size. In this case, both fallocate calls should succeed because the second one just
increases the file size but does not change the allocated space. However, I observed that the second
fallocate fails with EDQUOT if the free quota is less than _two times_ of the requested file size. I
guess that the second fallocate ignores the fact that the space was already preallocated and
accounts the requested size for the second time. For example, if QUOTA=2GiB, file size FILESIZE=800
MiB succeeds but FILESIZE=1600 MiB triggers EDQUOT in second fallocate. The same test performed on
EXT4 always succeeds.

I've found this issue while investigating why Samba (ver. 4.9.5) returns disk full error although
there's still enaugh room for the copied file. Indeed, when Samba's "strict allocate" options is
turned on Samba uses the above described sequence of two fallocate() syscalls to create a new file.

We noticed this behavior on Debian Buster 4.19 kernel and confirmed on stable 5.10.15 vanilla kernel.

Best regards,

Martin