Re: [PATCH v2] xfs: return default quota limits for IDs without a dquot

[Ravi Singh <ravising@redhat.com>]

On Wed, Mar 25, 2026 at 5:46 AM Darrick J. Wong <djwong@kernel.org> wrote:
>
> On Mon, Mar 23, 2026 at 04:55:31PM +0530, Ravi Singh wrote:
> > Hi all,
> >
> > Thanks for the feedback. Before posting a v3, I wanted to share some
> > additional findings. The v2 patch only covers one of three scenarios
> > where an unprivileged user cannot see the default limits applying to them.
> >
> > Scenario 1: No dquot on disk (v2 fixes this):
> > xfs_qm_dqget() returns -ENOENT, and v2 catches it.
> >
> > mkfs.xfs /dev/vde -f
> > mount -o quota /dev/vde /mnt/test
> > xfs_quota -xc 'limit -u bsoft=10m bhard=20m 0' /mnt/test
> > # Do NOT chown anything to testuser8 - no dquot exists
> > su - testuser8 -c "xfs_quota -c 'quota -ub' /mnt/test/"
> >
> > Without fix: empty output
> > With fix:
> > Disk quotas for User testuser8 (1003)
> > Filesystem              Blocks      Quota      Limit  Warn/Time      Mounted on
> >  /dev/vde                     0      10240      20480   00 [--------] /mnt/test
>
> Hmm, yes, that looks like a bug to me.

Thanks for confirming.

>
> > Scenario 2: dquot exists with non-zero counts but zero limits (v2 does NOT fix):
> >
> > A dquot is created for testuser8 before default limits are configured.
> > When the chown runs, xfs_qm_adjust_dqlimits() is called in
> > xfs_trans_apply_dquot_deltas(), but the defaults are all zero at that
> > point so nothing is pushed into the dquot. When the admin later sets
> > limits on ID 0, testuser8's existing dquot is not retroactively updated.
> > xfs_qm_dqget() succeeds and XFS_IS_DQUOT_UNINITIALIZED is
> > false (q_ino.count != 0), so xfs_qm_scall_getquota_fill_qc() returns
> > the dquot's zero limits.
>
> I think this is a difference in opinion -- the last time I checked, the
> default limits are only supposed to be propagated to newly allocated
> ondisk dquots.

Understood: Scenario 2 is by design.

>
> It's true that it would make more sense if the ondisk dquot had a flag
> to say "I've had limits applied here" such that default limits would
> apply to a dquot that already existed on disk but hadn't had limits set.
> Plus then you could modify a dquot with explicit limits to revert back
> to the defaults.
>
> Unfortunately there's no such flag in the ondisk format so we'd have to
> rev the disk format to add that behavior.  As such ... I don't think
> this is easily fixable.  The only way you could revert to defaults is
> if...
>
> > mkfs.xfs /dev/vde -f
> > mount -o quota /dev/vde /mnt/test
> > mkdir /mnt/test/testuser8
> > chown testuser8:testuser8 /mnt/test/testuser8
> > xfs_quota -xc 'limit -u bsoft=10m bhard=20m 0' /mnt/test
> > su - testuser8 -c "xfs_quota -c 'quota -ub' /mnt/test/"
> > # empty output
> >
> > Scenario 3 : dquot all zeros / XFS_IS_DQUOT_UNINITIALIZED (v2 does NOT fix):
> >
> > A dquot record persists on disk with all zero fields after ownership
> > is transferred away. xfs_qm_dqget() succeeds, but XFS_IS_DQUOT_UNINITIALIZED
> > returns true and the query returns -ENOENT. The v2 fallback does not
> > trigger because it only handles the xfs_qm_dqget() error path.
>
> ...you delete all usage for the dquot and set the limits to zero, right?
> Or does setting the limits to zero actually work even if there's quota
> usage?

Setting limits to zero alone isn't enough. XFS_IS_DQUOT_UNINITIALIZED
checks both limits and counts (q_blk.count, q_rtb.count, q_ino.count),
so all of them must be zero. In the reproduction, the chown back to
root moves the inode count back to 0, that's what makes all fields zero.
If the user still owns any files, q_ino.count would be non-zero
and the dquot would not be considered uninitialized.

>
> Either way if the ondisk dquot is totally uninitialized then I don't
> think we need to emit a record unless there's also a default limit.
>
> > mkfs.xfs /dev/vde -f
> > mount -o quota /dev/vde /mnt/test
> > mkdir /mnt/test/testuser8
> > chown testuser8:testuser8 /mnt/test/testuser8
> > chown root:root /mnt/test/testuser8
> > xfs_quota -xc 'limit -u bsoft=10m bhard=20m 0' /mnt/test
> > su - testuser8 -c "xfs_quota -c 'quota -ub' /mnt/test/"
> > # empty output
> >
> > I see two approaches for v3 and would appreciate guidance:
> >
> > 1. Fix all three in xfs_qm_scall_getquota() by merging default limits
> >     into the response for any zero-valued limit field, mirroring
> >     xfs_qm_adjust_dqlimits().
> > 2.  Expose default limits through Q_XGETQSTATV using the available
> >      padding space in fs_quota_statv, as Jan suggested, and let
> >      userspace tools merge them.
> >
> > Thoughts?
>
> I don't think we should create more userspace abi since nobody seems to
> think that anyone uses quota limit reporting aggressively.  But if
> anyone does, now would be a good time to say something.

Agreed. Thanks for the feedback!

>
> --D
>
> > Thanks,
> > Ravi
> >
> >
>