From: Brian Foster <bfoster@redhat.com>
To: Christoph Hellwig <hch@infradead.org>
Cc: linux-xfs@vger.kernel.org
Subject: Re: [PATCH v3 3/3] xfs: refactor xfs_buf_log_item reference count handling
Date: Fri, 31 Aug 2018 09:22:39 -0400 [thread overview]
Message-ID: <20180831132239.GC39825@bfoster> (raw)
In-Reply-To: <20180831073038.GB7079@infradead.org>
On Fri, Aug 31, 2018 at 12:30:38AM -0700, Christoph Hellwig wrote:
> > +bool
> > +xfs_buf_item_put(
> > + struct xfs_buf_log_item *bip)
>
> Any reason to not have this above the caller? Also a little
> top of function comment explaining this helper might be nice.
>
Ok, I can move it and add a comment.
> > + /*
> > + * We dropped the last ref and must free the item if clean or aborted.
> > + * If the bli is dirty and non-aborted, the buffer was clean in the
> > + * transaction but still awaiting writeback from previous changes. In
> > + * that case, the bli is freed on buffer writeback completion.
> > + */
> > + aborted = test_bit(XFS_LI_ABORTED, &lip->li_flags) ||
> > + XFS_FORCED_SHUTDOWN(lip->li_mountp);
> > + dirty = bip->bli_flags & XFS_BLI_DIRTY;
> > + if (dirty && !aborted)
> > + return false;
> > +
> > + /*
> > + * The bli is aborted or clean. An aborted item may be in the AIL
> > + * regardless of dirty state. For example, consider an aborted
> > + * transaction that invalidated a dirty bli and cleared the dirty
> > + * state.
> > + */
> > + if (aborted)
> > + xfs_trans_ail_remove(lip, SHUTDOWN_LOG_IO_ERROR);
>
> Hmm, why not:
>
> if (test_bit(XFS_LI_ABORTED, &lip->li_flags) ||
> XFS_FORCED_SHUTDOWN(lip->li_mountp))
> xfs_trans_ail_remove(lip, SHUTDOWN_LOG_IO_ERROR);
> else if (dirty)
> return false;
Because 1.) I wanted to separate the logic and comments for when we must
free the item from when we don't and 2.) I don't want to look at this
function and see the aborted logic first and then try to grok the more
common case in an 'else' branch. I want to see the common case logic
front and center and consider the aborted case as the outlier.
IOW, the aborted state shouldn't really drive the logical flow of this
function:
- if the bli is still referenced, return
- if the bli is unreferenced but is going to be written back, return
- otherwise we're the last user, free the item appropriately
Brian
prev parent reply other threads:[~2018-08-31 17:30 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-08-29 17:26 [PATCH v3 0/3] xfs: bli refcount fixups Brian Foster
2018-08-29 17:26 ` [PATCH v3 1/3] xfs: don't unlock invalidated buf on aborted tx commit Brian Foster
2018-08-31 7:24 ` Christoph Hellwig
2018-08-31 13:21 ` Brian Foster
2018-09-01 11:05 ` Christoph Hellwig
2018-09-03 0:18 ` Dave Chinner
2018-08-29 17:26 ` [PATCH v3 2/3] xfs: clean up xfs_trans_brelse() Brian Foster
2018-08-29 17:26 ` [PATCH v3 3/3] xfs: refactor xfs_buf_log_item reference count handling Brian Foster
2018-08-31 7:30 ` Christoph Hellwig
2018-08-31 13:22 ` 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=20180831132239.GC39825@bfoster \
--to=bfoster@redhat.com \
--cc=hch@infradead.org \
--cc=linux-xfs@vger.kernel.org \
/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