From: Bob Peterson <rpeterso@redhat.com>
To: cluster-devel.redhat.com
Subject: [Cluster-devel] [PATCH] gfs2: Move iomap_get before taking sd_quota_mutex
Date: Fri, 11 Feb 2022 10:51:51 -0500 [thread overview]
Message-ID: <20220211155151.108646-1-rpeterso@redhat.com> (raw)
Before this patch quota function bh_get called gfs2_iomap_get after it
had locked the sd_quota_mutex. That's a problem because that holds the
i_rw_mutex, and that lock order is different from other code that
locks i_rw_mutex first, then the sd_quota_mutex:
punch_hole
sweep_bh_for_rgrps
down_write(&ip->i_rw_mutex)
...
__gfs2_free_blocks(ip, rgd, bstart, (u32)blen, meta);
gfs2_quota_change
do_qc
lock(&sdp->sd_quota_mutex);
This patch changes the order of events to this:
1. If qd->qd_bh_count is zero (we're likely but not guaranteed to be
the first qd holder) it calls gfs2_iomap_get to determine which
block should be read.
2. Lock the sd_quota_mutex
3. If qd->qd_bh_count is still zero (now it's guaranteed) it reads
in the necessary block.
4. If qd_bh_count is no longer zero (because it wasn't holding the
mutex) the iomap_get was wasted time, so return.
The case in which it wastes time (step 4) should be very rare and
only occur when sd_quota_mutex is contended. But this avoids the ABBA
deadlock.
Signed-off-by: Bob Peterson <rpeterso@redhat.com>
---
fs/gfs2/quota.c | 39 +++++++++++++++++++++++++++------------
1 file changed, 27 insertions(+), 12 deletions(-)
diff --git a/fs/gfs2/quota.c b/fs/gfs2/quota.c
index 91bc3affe460..fe98b2a6c0b6 100644
--- a/fs/gfs2/quota.c
+++ b/fs/gfs2/quota.c
@@ -368,9 +368,23 @@ static int bh_get(struct gfs2_quota_data *qd)
struct gfs2_inode *ip = GFS2_I(sdp->sd_qc_inode);
unsigned int block, offset;
struct buffer_head *bh;
- struct iomap iomap = { };
+ struct iomap iomap = { .addr = IOMAP_NULL_ADDR, };
int error;
+ block = qd->qd_slot / sdp->sd_qc_per_block;
+ offset = qd->qd_slot % sdp->sd_qc_per_block;
+
+retry:
+ if (!qd->qd_bh_count) {
+ error = gfs2_iomap_get(sdp->sd_qc_inode,
+ (loff_t)block << sdp->sd_qc_inode->i_blkbits,
+ sdp->sd_sb.sb_bsize, &iomap);
+ if (error)
+ return error;
+ if (iomap.addr == IOMAP_NULL_ADDR)
+ return -ENOENT;
+ }
+
mutex_lock(&sdp->sd_quota_mutex);
if (qd->qd_bh_count++) {
@@ -378,17 +392,18 @@ static int bh_get(struct gfs2_quota_data *qd)
return 0;
}
- block = qd->qd_slot / sdp->sd_qc_per_block;
- offset = qd->qd_slot % sdp->sd_qc_per_block;
-
- error = gfs2_iomap_get(sdp->sd_qc_inode,
- (loff_t)block << sdp->sd_qc_inode->i_blkbits,
- sdp->sd_sb.sb_bsize, &iomap);
- if (error)
- goto fail;
- if (iomap.addr == IOMAP_NULL_ADDR) {
- error = -ENOENT;
- goto fail;
+ /*
+ * Make sure we called iomap_get. If qd_bh_count was non-zero at
+ * the start of the function, but was changed to 0 (by someone else's
+ * decrement) and we discover it after we acquired the mutex, we will
+ * have skipped the call to gfs2_iomap_get() and therefore don't know
+ * the block number we need to read. In that case we need to start
+ * over to get the block number.
+ */
+ if (unlikely(iomap.addr == IOMAP_NULL_ADDR)) {
+ qd->qd_bh_count--;
+ mutex_unlock(&sdp->sd_quota_mutex);
+ goto retry;
}
error = gfs2_meta_read(ip->i_gl, iomap.addr >> sdp->sd_qc_inode->i_blkbits,
--
2.34.1
next reply other threads:[~2022-02-11 15:51 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-02-11 15:51 Bob Peterson [this message]
2022-05-17 12:40 ` [Cluster-devel] [PATCH] * Andreas Gruenbacher
2022-05-17 12:42 ` [Cluster-devel] [PATCH] gfs2: Move iomap_get before taking sd_quota_mutex Andreas Gruenbacher
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=20220211155151.108646-1-rpeterso@redhat.com \
--to=rpeterso@redhat.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).