From: Brian Foster <bfoster@redhat.com>
To: Dave Chinner <david@fromorbit.com>
Cc: Dan Carpenter <dan.carpenter@oracle.com>, xfs@oss.sgi.com
Subject: Re: [PATCH] xfs: fix error handling in xfs_qm_log_quotaoff()
Date: Mon, 20 Oct 2014 09:21:48 -0400 [thread overview]
Message-ID: <20141020132148.GB30254@bfoster.bfoster> (raw)
In-Reply-To: <20141020003120.GJ7169@dastard>
On Mon, Oct 20, 2014 at 11:31:20AM +1100, Dave Chinner wrote:
> On Thu, Oct 16, 2014 at 09:39:33AM -0400, Brian Foster wrote:
> > The error handling in xfs_qm_log_quotaoff() has a couple problems. If
> > xfs_trans_commit() fails, we fall through to the error block and call
> > xfs_trans_cancel(). This is incorrect on commit failure. If
> > xfs_trans_reserve() fails, we jump to the error block, cancel the tp and
> > restore the superblock qflags to oldsbqflag. However, oldsbqflag has
> > been initialized to zero and not yet updated from the original flags so
> > we set the flags to zero.
> >
> > Fix up the error handling in xfs_qm_log_quotaoff() to not restore flags
> > if they haven't been modified and not cancel the tp on commit failure.
> >
> > Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
> > Signed-off-by: Brian Foster <bfoster@redhat.com>
> > ---
> > fs/xfs/xfs_qm_syscalls.c | 35 ++++++++++++++++++++---------------
> > 1 file changed, 20 insertions(+), 15 deletions(-)
> >
> > diff --git a/fs/xfs/xfs_qm_syscalls.c b/fs/xfs/xfs_qm_syscalls.c
> > index 80f2d77..f2d454e 100644
> > --- a/fs/xfs/xfs_qm_syscalls.c
> > +++ b/fs/xfs/xfs_qm_syscalls.c
> > @@ -784,13 +784,17 @@ xfs_qm_log_quotaoff(
> > {
> > xfs_trans_t *tp;
> > int error;
> > - xfs_qoff_logitem_t *qoffi=NULL;
> > - uint oldsbqflag=0;
> > + xfs_qoff_logitem_t *qoffi;
> > + uint oldsbqflag;
> > +
> > + *qoffstartp = NULL;
> >
> > tp = xfs_trans_alloc(mp, XFS_TRANS_QM_QUOTAOFF);
> > error = xfs_trans_reserve(tp, &M_RES(mp)->tr_qm_quotaoff, 0, 0);
> > - if (error)
> > - goto error0;
> > + if (error) {
> > + xfs_trans_cancel(tp, 0);
> > + return error;
> > + }
> >
> > qoffi = xfs_trans_get_qoff_item(tp, NULL, flags & XFS_ALL_QUOTA_ACCT);
> > xfs_trans_log_quotaoff_item(tp, qoffi);
> > @@ -809,19 +813,20 @@ xfs_qm_log_quotaoff(
> > */
> > xfs_trans_set_sync(tp);
> > error = xfs_trans_commit(tp, 0);
> > + if (error)
> > + goto error_flags;
>
>
> If the commit fails, the filesystem will be shut down and the state
> of the quota flags is completely irrelevant at this point so there's
> no reason to restore them. Indeed, is restoring them even the right
> thing to do? The commit *may* have made it to disk, but a
> subsequent error during completion handling resulted in the commit
> failing....
>
Good point. We don't seem to try and undo this kind of state change
anywhere else that I can see either. At most, we release references or
free memory or other such things that aren't tied to the transaction in
any way.
Brian
> Cheers,
>
> Dave.
> --
> Dave Chinner
> david@fromorbit.com
>
> _______________________________________________
> xfs mailing list
> xfs@oss.sgi.com
> http://oss.sgi.com/mailman/listinfo/xfs
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
prev parent reply other threads:[~2014-10-20 13:21 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-10-16 13:39 [PATCH] xfs: fix error handling in xfs_qm_log_quotaoff() Brian Foster
2014-10-20 0:31 ` Dave Chinner
2014-10-20 13:21 ` Brian Foster [this message]
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=20141020132148.GB30254@bfoster.bfoster \
--to=bfoster@redhat.com \
--cc=dan.carpenter@oracle.com \
--cc=david@fromorbit.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