gfs2: Improve gfs2_upgrade_iopen_glock comment

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>

diff --git a/fs/gfs2/super.c b/fs/gfs2/super.c
index de99505..a857b99 100644 (file)
--- a/fs/gfs2/super.c
+++ b/fs/gfs2/super.c
@@ -1175,15 +1175,23 @@ static bool gfs2_upgrade_iopen_glock(struct inode *inode)
        gfs2_glock_dq_wait(gh);
 
        /*
-        * If there are no other lock holders, we'll get the lock immediately.
+        * If there are no other lock holders, we will immediately get
+        * exclusive access to the iopen glock here.
+        *
         * Otherwise, the other nodes holding the lock will be notified about
-        * our locking request.  If they don't have the inode open, they'll
-        * evict the cached inode and release the lock.  Otherwise, if they
-        * poke the inode glock, we'll take this as an indication that they
-        * still need the iopen glock and that they'll take care of deleting
-        * the inode when they're done.  As a last resort, if another node
-        * keeps holding the iopen glock without showing any activity on the
-        * inode glock, we'll eventually time out.
+        * our locking request.  If they do not have the inode open, they are
+        * expected to evict the cached inode and release the lock, allowing us
+        * to proceed.
+        *
+        * Otherwise, if they cannot evict the inode, they are expected to poke
+        * the inode glock (note: not the iopen glock).  We will notice that
+        * and stop waiting for the iopen glock immediately.  The other node(s)
+        * are then expected to take care of deleting the inode when they no
+        * longer use it.
+        *
+        * As a last resort, if another node keeps holding the iopen glock
+        * without showing any activity on the inode glock, we will eventually
+        * time out and fail the iopen glock upgrade.
         *
         * Note that we're passing the LM_FLAG_TRY_1CB flag to the first
         * locking request as an optimization to notify lock holders as soon as