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

["Darrick J. Wong" <djwong@kernel.org>]

On Wed, Mar 18, 2026 at 06:29:47PM +0100, Jan Kara wrote:
> Hello!
> 
> On Tue 17-03-26 09:31:59, Theodore Tso wrote:
> > On Tue, Mar 17, 2026 at 01:19:23PM +0100, Jan Kara wrote:
> > > On Tue 17-03-26 14:59:47, Ravi Singh wrote:
> > > > When an ID has no dquot on disk, Q_XGETQUOTA returns -ENOENT even
> > > > though default quota limits are configured and enforced against that
> > > > ID.  This means unprivileged users who have never used any resources
> > > > cannot see the limits that apply to them.
> > > > 
> > > > When xfs_qm_dqget() returns -ENOENT for a non-zero ID, return a
> > > > zero-usage response with the default limits filled in from
> > > > m_quotainfo rather than propagating the error.  This is consistent
> > > > with the enforcement behavior in xfs_qm_adjust_dqlimits(), which
> > > > pushes the same default limits into a dquot when it is first
> > > > allocated.
> > > > 
> > > > Signed-off-by: Ravi Singh <ravising@redhat.com>
> > > 
> > > So XFS guys should also review this but from quota POV this looks like a
> > > right fix to me. So feel free to add:
> > > 
> > > Reviewed-by: Jan Kara <jack@suse.cz>
> > 
> > This was discussed at last week's ext4 conference call, and we
> > wondered whether we might be better off adding a new
> > Q_XGETDEFAULTQUOTA or some such which returned the default quota.
> > This would that the quota userspace utilities would have to be
> > changed, but it would also mean that userspace could distinguish
> > between whether the quota limit was due to a default value being used,
> > or because the user had an actual quota value set.
> 
> First thing to note is that the notion of "default limit" is specific to
> XFS. Other filesystems using quota don't have any default limits. I guess
> most people here know this but I'm spelling it out so that we are all on
> the same page.

*I* actually didn't know that, so thank you for pointing that out!!

> > It also means that in the future, if we wanted to change where the
> > default quota was stored, it would be possible to do that instead of
> > overloading the quota value for uid/gid 0.
> > 
> > We also speculated that perhaps there might be cases where if some
> > process might be running without CAP_SYS_ADMIN, there might be a
> > reason that quota for uid=0 might actually make sense, and so perhaps
> > some future file system format change might want to decouple where the
> > default quota was stored.
> 
> Right. That's why I didn't like the v1 version of the patch. But v2 version
> hides the XFS specific behavior of default limits inside XFS function for
> fetching quotas so that is fully transparent. If XFS decides to change its
> quota format to support limits for root, it can also change this code

Wait, do the other filesystems enforce limits on id 0?

Also, do those non-xfs filesystems also not have default limits?

> fetching and filling in default limits for the user. So until XFS decides
> to change the format, current solution looks fine to me, once it decides to
> change it, it is easy to change this code as well. But obviously this is
> fully XFS developers' area of code so they can do whatever they wish :)

/me bets nobody cares that much in xfsland other than not breaking
userspace tools. ;)

> The only improvement I can see is if we explicitely wanted to expose the
> XFS default limits in some generic way for userspace tools to show. But
> then I'd think we don't really need new quotactl, we could just put this
> into the result of existing Q_XGETQSTATV quotactl.
> 
> Overall I don't have a strong opinion on this and consider these questions
> mostly specific to XFS so XFS guys should decide what they want...

We're stuck with the old ABI behavior unless you all want to add a
Q_<whatever>V2 quotactl command.

--D

> 
> 								Honza
> -- 
> Jan Kara <jack@suse.com>
> SUSE Labs, CR
>