From: Theodore Ts'o <tytso@mit.edu>
To: Jan Kara <jack@suse.cz>
Cc: linux-ext4@vger.kernel.org, linux-fsdevel@vger.kernel.org,
ocfs2-devel@oss.oracle.com
Subject: Re: [PATCH 1/2] quota: Handle Q_GETNEXTQUOTA when quota is disabled
Date: Fri, 1 Apr 2016 10:39:56 -0400 [thread overview]
Message-ID: <20160401143956.GD29897@thunk.org> (raw)
In-Reply-To: <1459267904-10755-1-git-send-email-jack@suse.cz>
On Tue, Mar 29, 2016 at 06:11:43PM +0200, Jan Kara wrote:
> Currently we oopsed when Q_GETNEXTQUOTA got called when quota was
> disabled. Properly check whether quota is enabled for the filesystem
> before calling into quota format handler.
>
> diff --git a/fs/quota/dquot.c b/fs/quota/dquot.c
> index ba827daea5a0..ff21980d0119 100644
> --- a/fs/quota/dquot.c
> +++ b/fs/quota/dquot.c
> @@ -2047,11 +2047,20 @@ int dquot_get_next_id(struct super_block *sb, struct kqid *qid)
> struct quota_info *dqopt = sb_dqopt(sb);
> int err;
>
> - if (!dqopt->ops[qid->type]->get_next_id)
> - return -ENOSYS;
> + mutex_lock(&dqopt->dqonoff_mutex);
> + if (!sb_has_quota_active(sb, qid->type)) {
> + err = -ESRCH;
> + goto out;
> + }
> + if (!dqopt->ops[qid->type]->get_next_id) {
> + err = -ENOSYS;
> + goto out;
> + }
Don't you also have to test if dqopt->ops[qid->type] is NULL? e.g.,
if the quota inode hasn't been loaded for that quota type?
Also, I notice you have this queued on the for_next branch and not the
for_linus branch. I was hoping you could push this to Linus sooner
than the next merge cycle, since this is (a) making my testing hard,
and (b) it makes it easy for an attacker to crash the system. For
similar reasons, perhaps this should have a cc: stable@vger.kernel.org
tag?
Thanks,
- Ted
WARNING: multiple messages have this Message-ID (diff)
From: Theodore Ts'o <tytso@mit.edu>
To: Jan Kara <jack@suse.cz>
Cc: linux-ext4@vger.kernel.org, linux-fsdevel@vger.kernel.org,
ocfs2-devel@oss.oracle.com
Subject: [Ocfs2-devel] [PATCH 1/2] quota: Handle Q_GETNEXTQUOTA when quota is disabled
Date: Fri, 1 Apr 2016 10:39:56 -0400 [thread overview]
Message-ID: <20160401143956.GD29897@thunk.org> (raw)
In-Reply-To: <1459267904-10755-1-git-send-email-jack@suse.cz>
On Tue, Mar 29, 2016 at 06:11:43PM +0200, Jan Kara wrote:
> Currently we oopsed when Q_GETNEXTQUOTA got called when quota was
> disabled. Properly check whether quota is enabled for the filesystem
> before calling into quota format handler.
>
> diff --git a/fs/quota/dquot.c b/fs/quota/dquot.c
> index ba827daea5a0..ff21980d0119 100644
> --- a/fs/quota/dquot.c
> +++ b/fs/quota/dquot.c
> @@ -2047,11 +2047,20 @@ int dquot_get_next_id(struct super_block *sb, struct kqid *qid)
> struct quota_info *dqopt = sb_dqopt(sb);
> int err;
>
> - if (!dqopt->ops[qid->type]->get_next_id)
> - return -ENOSYS;
> + mutex_lock(&dqopt->dqonoff_mutex);
> + if (!sb_has_quota_active(sb, qid->type)) {
> + err = -ESRCH;
> + goto out;
> + }
> + if (!dqopt->ops[qid->type]->get_next_id) {
> + err = -ENOSYS;
> + goto out;
> + }
Don't you also have to test if dqopt->ops[qid->type] is NULL? e.g.,
if the quota inode hasn't been loaded for that quota type?
Also, I notice you have this queued on the for_next branch and not the
for_linus branch. I was hoping you could push this to Linus sooner
than the next merge cycle, since this is (a) making my testing hard,
and (b) it makes it easy for an attacker to crash the system. For
similar reasons, perhaps this should have a cc: stable at vger.kernel.org
tag?
Thanks,
- Ted
next prev parent reply other threads:[~2016-04-01 14:39 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-29 16:11 [PATCH 1/2] quota: Handle Q_GETNEXTQUOTA when quota is disabled Jan Kara
2016-03-29 16:11 ` [Ocfs2-devel] " Jan Kara
2016-03-29 16:11 ` [PATCH 2/2] ocfs2: Fix Q_GETNEXTQUOTA for filesystem without quotas Jan Kara
2016-03-29 16:11 ` [Ocfs2-devel] " Jan Kara
2016-04-01 14:39 ` Theodore Ts'o [this message]
2016-04-01 14:39 ` [Ocfs2-devel] [PATCH 1/2] quota: Handle Q_GETNEXTQUOTA when quota is disabled Theodore Ts'o
2016-04-04 9:40 ` Jan Kara
2016-04-04 9:40 ` [Ocfs2-devel] " 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=20160401143956.GD29897@thunk.org \
--to=tytso@mit.edu \
--cc=jack@suse.cz \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=ocfs2-devel@oss.oracle.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.