Skip to content

Commit 3d763b5

Browse files
committed
gfs2: Improve gfs2_upgrade_iopen_glock comment
jira LE-2169 Rebuild_History Non-Buildable kernel-4.18.0-553.27.1.el8_10 commit-author Andreas Gruenbacher <agruenba@redhat.com> commit 2d14395 Improve the comment describing the inode and iopen glock interactions and the glock poking related to inode evict. Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com> (cherry picked from commit 2d14395) Signed-off-by: Jonathan Maple <jmaple@ciq.com>
1 parent dd234f8 commit 3d763b5

File tree

1 file changed

+16
-8
lines changed

1 file changed

+16
-8
lines changed

fs/gfs2/super.c

Lines changed: 16 additions & 8 deletions
Original file line numberDiff line numberDiff line change
@@ -1298,15 +1298,23 @@ static bool gfs2_upgrade_iopen_glock(struct inode *inode)
12981298
gfs2_glock_dq_wait(gh);
12991299

13001300
/*
1301-
* If there are no other lock holders, we'll get the lock immediately.
1301+
* If there are no other lock holders, we will immediately get
1302+
* exclusive access to the iopen glock here.
1303+
*
13021304
* Otherwise, the other nodes holding the lock will be notified about
1303-
* our locking request. If they don't have the inode open, they'll
1304-
* evict the cached inode and release the lock. Otherwise, if they
1305-
* poke the inode glock, we'll take this as an indication that they
1306-
* still need the iopen glock and that they'll take care of deleting
1307-
* the inode when they're done. As a last resort, if another node
1308-
* keeps holding the iopen glock without showing any activity on the
1309-
* inode glock, we'll eventually time out.
1305+
* our locking request. If they do not have the inode open, they are
1306+
* expected to evict the cached inode and release the lock, allowing us
1307+
* to proceed.
1308+
*
1309+
* Otherwise, if they cannot evict the inode, they are expected to poke
1310+
* the inode glock (note: not the iopen glock). We will notice that
1311+
* and stop waiting for the iopen glock immediately. The other node(s)
1312+
* are then expected to take care of deleting the inode when they no
1313+
* longer use it.
1314+
*
1315+
* As a last resort, if another node keeps holding the iopen glock
1316+
* without showing any activity on the inode glock, we will eventually
1317+
* time out and fail the iopen glock upgrade.
13101318
*
13111319
* Note that we're passing the LM_FLAG_TRY_1CB flag to the first
13121320
* locking request as an optimization to notify lock holders as soon as

0 commit comments

Comments
 (0)