From: Brian Foster <bfoster@redhat.com>
To: linux-xfs@vger.kernel.org
Subject: [PATCH v2 0/3] xfs: bli refcount fixups
Date: Mon, 27 Aug 2018 10:25:45 -0400 [thread overview]
Message-ID: <20180827142548.45029-1-bfoster@redhat.com> (raw)
Hi all,
This is a v2 of the stale buffer locking fix for an aborted transaction.
It has minor refactoring changes noted below. I've added two optional
patches on top because I wanted to take a stab at a bit more cleanup in
this area, but these are aesthetic changes only and can be dropped if
desired.
Patch 1 is the original bug fix. Patch 2 cleans up xfs_trans_brelse() to
remove some cruft and use similar logic/flow as xfs_buf_item_unlock().
Patch 3 refactors the bli refcount cleanup logic that is common between
the two functions. There is still open-coded bli refcount handling on
unpin because there are additional considerations in that path. Stale
inode buffer handling has special handling, for whatever reason. The
stale inode buf handling actually looks quite similar to the
non-specialized buffer handling, but further cleanup in that area would
require a more in-depth audit to be sure.
I find the end result a bit cleaner but I'm not wedded to it and I'm
fine with just dropping patches 2-3 if the current approach is
preferred. FWIW, this also raised a couple thoughts on alternative
approaches, such as reworking the bli refcount such that the AIL also
holds a reference, but it's not totally clear that (by itself)
simplifies things in the case of a shutdown with AIL-held blis.
Thoughts, reviews, flames appreciated.
Brian
v2:
- Refactor stale bli unlock logic to more closely resemble original.
- Use bool for 'freed' variable and clean up type casting.
- Reorder asserts/tracepoints and remove unused stale tracepoint.
- Added patches 2 and 3.
v1: https://marc.info/?l=linux-xfs&m=153486008127962&w=2
Brian Foster (3):
xfs: don't unlock invalidated buf on aborted tx commit
xfs: clean up xfs_trans_brelse()
xfs: refactor xfs_buf_log_item reference count handling
fs/xfs/xfs_buf_item.c | 115 +++++++++++++++++++++--------------------
fs/xfs/xfs_buf_item.h | 1 +
fs/xfs/xfs_trace.h | 1 -
fs/xfs/xfs_trans_buf.c | 98 +++++++++--------------------------
4 files changed, 84 insertions(+), 131 deletions(-)
--
2.17.1
next reply other threads:[~2018-08-27 18:12 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-08-27 14:25 Brian Foster [this message]
2018-08-27 14:25 ` [PATCH 1/3] xfs: don't unlock invalidated buf on aborted tx commit Brian Foster
2018-08-27 14:25 ` [PATCH 2/3] xfs: clean up xfs_trans_brelse() Brian Foster
2018-08-28 22:36 ` Dave Chinner
2018-08-29 13:55 ` Brian Foster
2018-08-27 14:25 ` [PATCH 3/3] xfs: refactor xfs_buf_log_item reference count handling Brian Foster
2018-08-28 22:59 ` Dave Chinner
2018-08-29 13:55 ` Brian Foster
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=20180827142548.45029-1-bfoster@redhat.com \
--to=bfoster@redhat.com \
--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;
as well as URLs for NNTP newsgroup(s).