Bug 1898549

We usually do not rebase packages. Especially not if the new version breaks a compatibility, like this one (RHEL-8.4 has 4.04 version, upstream removed quot tool in 4.05, the latest upstream is 4.06).
Though we can port patches.

Can you tell me what exactly fails (bug #1827913 does list any quota tool invocation), what changes you did in the kernel, and which kernel build contains them so that I can test quota tools against the right kernel?

I believe some of these upstream's quota tools patches are need:

e777f46 Handle grace time overflows for XFS quotas
16b60cb Support grace period expirations past y2038 for XFS
13bb8c2 Fix limits setting on XFS filesystem
be96da2 quota-tools: Set FS_DQ_TIMER_MASK for individual xfs grace times
fdd774b quota-tools: pass quota type to QCMD for Q_XFS_GETQSTAT

repquota and setquota are invoked by xfstests generic/594
At a minimum, 
commit be96da23536 quota-tools: Set FS_DQ_TIMER_MASK for individual xfs grace times
is required.
Thanks-
Bill

my kernel tree containing the patches is here:
http://git.engineering.redhat.com/git/users/bodonnel/kernel-rhel/.git/

Also, note that an upstream version of xfsprogs is required. I'm in the midst of pinpointing
the upstream xfsprogs patches required for rhel8. Meantime, I've simply been using a newish
xfsprogs (5.9.0).

Thanks-
Bill

I think this fix isn't enough, due to generic/600 still fails at below:

generic/600     - output mismatch (see /home/xfstests-dev/results//generic/600.out.bad)
    --- tests/generic/600.out   2020-06-23 03:09:19.624557385 -0400
    +++ /home/xfstests-dev/results//generic/600.out.bad 2020-12-17 01:59:37.421060416 -0500
    @@ -1,2 +1,3 @@
     QA output created by 600
     Silence is golden
    +set grace to 1608188473 but got grace 1608188371
    ...
    (Run 'diff -u /home/xfstests-dev/tests/generic/600.out /home/xfstests-dev/results//generic/600.out.bad'  to see the entire diff)

But when I use upstream quota-tools (https://git.kernel.org/pub/scm/utils/quota/quota-tools.git), this test passed:

# ./check generic/600
FSTYP         -- xfs (non-debug)
PLATFORM      -- Linux/x86_64 hp-dl380pg8-01 4.18.0-262.el8.test.x86_64+debug #1 SMP Wed Dec 16 08:36:54 EST 2020
MKFS_OPTIONS  -- -f -bsize=4096 /dev/mapper/rhel_hp--dl380pg8--01-xfscratch
MOUNT_OPTIONS -- -o context=system_u:object_r:root_t:s0 /dev/mapper/rhel_hp--dl380pg8--01-xfscratch /mnt/scratch

generic/600      13s
Ran: generic/600
Passed all 1 tests

So I think we still need more patches for this bug?

Thanks,
Zorro

generic/600 passes for me in Fedora 34 with the RHEL quota package. What kernel do you use in RHEL? Does generic/594, you reported originally, still pass for you?

I played with old 4.18.0-250.el811162020.x86_64 RHEL kernel and I can see that generic/600 fails there (in contrast to Fedora 34).
I debugged it and I believe it's a bug in the RHEL kernel. RHEL kernel does not store or wrongly reports d_itimer value for non-root users:

# date +%s; strace -e quotactl -v -- setquota -T -u fsgqa 0 100 /mnt/2 2>&1 | tail -n2 ; strace -e quotactl -v -- repquota -u -p /mnt/2 2>&1 | tail -n 15
1608201948
quotactl(QCMD(Q_XSETQLIM, USRQUOTA), "/dev/loop1", 4245, {d_version=0, d_flags=XFS_USER_QUOTA, d_fieldmask=0x1c0, d_id=4245, d_blk_hardlimit=0, d_blk_softlimit=0, d_ino_hardlimit=5, d_ino_softlimit=1, d_bcount=0, d_icount=2, d_itimer=1608202048, d_btimer=0, d_iwarns=0, d_bwarns=0, d_rtb_hardlimit=0, d_rtb_softlimit=0, d_rtbcount=0, d_rtbtimer=0, d_rtbwarns=0}) = 0
+++ exited with 0 +++
quotactl(QCMD(Q_XGETQSTAT, USRQUOTA), "/dev/loop1", {qs_version=1, qs_flags=XFS_QUOTA_UDQ_ACCT|XFS_QUOTA_UDQ_ENFD, qs_uquota={qfs_ino=11075, qfs_nblks=2, qfs_nextents=2}, qs_gquota={qfs_ino=18446744073709551615, qfs_nblks=0, qfs_nextents=0}, qs_incoredqs=60, qs_btimelimit=0, qs_itimelimit=1, qs_rtbtimelimit=0, qs_bwarnlimit=5, qs_iwarnlimit=5}) = 0
quotactl(QCMD(Q_XGETNEXTQUOTA, USRQUOTA), "/dev/loop1", 0, {d_version=1, d_flags=XFS_USER_QUOTA, d_fieldmask=0, d_id=0, d_blk_hardlimit=0, d_blk_softlimit=0, d_ino_hardlimit=0, d_ino_softlimit=0, d_bcount=0, d_icount=5, d_itimer=1, d_btimer=0, d_iwarns=0, d_bwarns=0, d_rtb_hardlimit=0, d_rtb_softlimit=0, d_rtbcount=0, d_rtbtimer=0, d_rtbwarns=0}) = 0
quotactl(QCMD(Q_XGETNEXTQUOTA, USRQUOTA), "/dev/loop1", 0, {d_version=1, d_flags=XFS_USER_QUOTA, d_fieldmask=0, d_id=0, d_blk_hardlimit=0, d_blk_softlimit=0, d_ino_hardlimit=0, d_ino_softlimit=0, d_bcount=0, d_icount=5, d_itimer=1, d_btimer=0, d_iwarns=0, d_bwarns=0, d_rtb_hardlimit=0, d_rtb_softlimit=0, d_rtbcount=0, d_rtbtimer=0, d_rtbwarns=0}) = 0
quotactl(QCMD(Q_XGETNEXTQUOTA, USRQUOTA), "/dev/loop1", 1, {d_version=1, d_flags=XFS_USER_QUOTA, d_fieldmask=0, d_id=4245, d_blk_hardlimit=0, d_blk_softlimit=0, d_ino_hardlimit=5, d_ino_softlimit=1, d_bcount=0, d_icount=2, d_itimer=1608200085, d_btimer=0, d_iwarns=0, d_bwarns=0, d_rtb_hardlimit=0, d_rtb_softlimit=0, d_rtbcount=0, d_rtbtimer=0, d_rtbwarns=0}) = 0
quotactl(QCMD(Q_XGETNEXTQUOTA, USRQUOTA), "/dev/loop1", 4246, 0x7ffc7e2d0690) = -1 ENOENT (No such file or directory)
*** Report for user quotas on device /dev/loop1
Block grace time: 00:00; Inode grace time: 00:00
                        Block limits                File limits
User            used    soft    hard  grace    used  soft  hard  grace
----------------------------------------------------------------------
root      --       0       0       0      0       5     0     0      0
fsgqa     -+       0       0       0      0       2     1     5 1608200085


+++ exited with 0 +++

The command line prints current time (1608201948), sets i-node timer to +100 seconds (1608202048) for fsgqa user (UID 4245),
and finally lists quotas for all users and the last one for UID 4245 reports d_itimer=1608200085 instead of 1608202048.

If I set soft and hard limits for root user and repeat the command line for root, I can see the d_itimer value is properly reported.

Thanks. I confirm that the tests pass with 4.18.0-262.el8.test.x86_64 kernel.

By the way, xfs_repair tool dies on 16-MB loop devices I use for testing. "-o force_geometry" option is necessary to overcome it.

(In reply to Petr Pisar from comment #26)
> Thanks. I confirm that the tests pass with 4.18.0-262.el8.test.x86_64 kernel.
> 
> By the way, xfs_repair tool dies on 16-MB loop devices I use for testing.
> "-o force_geometry" option is necessary to overcome it.

Sorry, I might test on wrong version. I just tested again, can't reproduce that error. Please ignore comment 22.

Thanks,
Zorro

(In reply to Petr Pisar from comment #26)
> Thanks. I confirm that the tests pass with 4.18.0-262.el8.test.x86_64 kernel.
> 
> By the way, xfs_repair tool dies on 16-MB loop devices I use for testing.
> "-o force_geometry" option is necessary to overcome it.

Petr, FWIW 16MB is really too small for this purpose, it will result in the single-AG filesystems that cause this complaint from xfs_repair.

I typically use 16G loopback if I have to resort to loopback for testing.

Thanks,
-Eric

I confirm that my tests pass with kernel-4.18.0-269.el8. Gating waits on the new kernel to reach a CI system.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (quota bug fix and enhancement update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2021:1590