linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jan Kara <jack@suse.cz>
To: Eric Sandeen <sandeen@redhat.com>
Cc: linux-fsdevel@vger.kernel.org, xfs@oss.sgi.com, jack@suse.cz
Subject: Re: [PATCH 2/7] quota: add new quotactl Q_XGETNEXTQUOTA
Date: Fri, 22 Jan 2016 09:55:49 +0100	[thread overview]
Message-ID: <20160122085549.GB16898@quack.suse.cz> (raw)
In-Reply-To: <1453435644-32261-3-git-send-email-sandeen@redhat.com>

On Thu 21-01-16 22:07:19, Eric Sandeen wrote:
> Q_XGETNEXTQUOTA is exactly like Q_XGETQUOTA, except that it
> will return quota information for the id equal to or greater
> than the id requested.  In other words, if the requested id has
> no quota, the command will return quota information for the
> next higher id which does have a quota set.  If no higher id
> has an active quota, -ESRCH is returned.
> 
> This allows filesystems to do efficient iteration in kernelspace,
> much like extN filesystems do in userspace when asked to report
> all active quotas.
> 
> The patch adds a d_id field to struct qc_dqblk so that we can
> pass back the id of the quota which was found, and return it
> to userspace.
> 
> Today, filesystems such as XFS require getpwent-style iterations,
> and for systems which have i.e. LDAP backends, this can be very
> slow, or even impossible if iteration is not allowed in the
> configuration.
> 
> Signed-off-by: Eric Sandeen <sandeen@redhat.com>
...
> diff --git a/fs/quota/quota.c b/fs/quota/quota.c
> index ea66670..4bf8d40 100644
> --- a/fs/quota/quota.c
> +++ b/fs/quota/quota.c
> @@ -33,6 +33,7 @@ static int check_quotactl_permission(struct super_block *sb, int type, int cmd,
>  	/* allow to query information for dquots we "own" */
>  	case Q_GETQUOTA:
>  	case Q_XGETQUOTA:
> +	case Q_XGETNEXTQUOTA:

IMO you should require CAP_SYS_ADMIN for the quotactl. Definitely doing the
UID and GID checks for GETNEXTQUOTA looks strange to me since the returned
structure may be for a different ID. Or did you assume that existing user
will have quota structure allocated so we always return quotas for that ID
in that case? I'm not sure this is good to rely on...

> +	ret = sb->s_qcop->get_nextdqblk(sb, qid, &qdq);
> +	if (ret)
> +	        return ret;
> +	copy_to_xfs_dqblk(&fdq, &qdq, type, qdq.d_id);
> +	if (copy_to_user(addr, &fdq, sizeof(fdq)))
> +	        return -EFAULT;
> +	return ret;
> +}

So how about passing pointer to 'qid' to ->get_nextdqblk() and return the ID
that way? That will also force you to fix the issue that you currently
completely miss user-namespace conversions for the ID ;).

I definitely dislike mixing d_id in the qdq structure with arguments of fs
callbacks and that d_id doesn't get filled for most callbacks. That is going
to cause confusion.

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

  reply	other threads:[~2016-01-22  8:55 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-01-22  4:07 [PATCH 0/7 V2] quota: add new quotactl Q_GETNEXTQUOTA Eric Sandeen
2016-01-22  4:07 ` [PATCH 1/7] quota: remove unused cmd argument from quota_quotaon() Eric Sandeen
2016-01-22  4:07 ` [PATCH 2/7] quota: add new quotactl Q_XGETNEXTQUOTA Eric Sandeen
2016-01-22  8:55   ` Jan Kara [this message]
2016-01-22 13:57     ` Eric Sandeen
2016-01-22  4:07 ` [PATCH 3/7] quota: add new quotactl Q_GETNEXTQUOTA Eric Sandeen
2016-01-22  9:28   ` Jan Kara
2016-01-22 13:58     ` Eric Sandeen
2016-01-22  4:07 ` [PATCH 4/7] xfs: don't overflow quota ID when initializing dqblk Eric Sandeen
2016-01-22  4:07 ` [PATCH 5/7] xfs: get quota inode from mp & flags rather than dqp Eric Sandeen
2016-01-22  4:07 ` [PATCH 6/7] xfs: Factor xfs_seek_hole_data into helper Eric Sandeen
2016-01-22  4:07 ` [PATCH 7/7] xfs: wire up Q_XGETNEXTQUOTA / get_nextdqblk Eric Sandeen
  -- strict thread matches above, loose matches on Subject: below --
2016-01-22 18:25 [PATCH 0/7 V3] quota: add new quotactl Q_GETNEXTQUOTA Eric Sandeen
2016-01-22 18:25 ` [PATCH 2/7] quota: add new quotactl Q_XGETNEXTQUOTA Eric Sandeen
2016-01-25 14:51   ` Jan Kara
2016-01-26 12:57   ` Jan Kara
2016-01-26 15:00     ` Eric Sandeen
2016-01-26 17:52       ` Jan Kara
2016-01-26 17:57         ` Eric Sandeen
2016-01-26 18:39         ` Eric Sandeen
2016-01-26 20:40           ` Jan Kara

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20160122085549.GB16898@quack.suse.cz \
    --to=jack@suse.cz \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=sandeen@redhat.com \
    --cc=xfs@oss.sgi.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).