kernel/fs/gfs2/util.c, branch 0x221E-v0.0.1-v6.19

gfs2: Clean up SDF_JOURNAL_LIVE flag handling

2025-11-26T23:52:28Z

Change do_withdraw() to clear the SDF_JOURNAL_LIVE flag under the log flush lock. In addition, change __gfs2_trans_begin() to check if the filesystem is already known to be withdrawn using gfs2_withdrawn(). Then, once we are holding the log flush lock, check if the SDF_JOURNAL_LIVE flag is still set. This second check ensures that the filesystem will remain live until the transaction is submitted. With these changes, it is no longer useful to clear SDF_JOURNAL_LIVE in gfs2_end_log_write() after calling gfs2_withdraw(). Signed-off-by: Andreas Gruenbacher

gfs2: No longer thaw filesystems during a withdraw

2025-11-26T23:52:28Z

Previously, when a withdraw occurred, we would wait for another node to recover our journal. This also meant that frozen filesystem needed to be thawed because otherwise, other nodes wouldn't be able to recover the filesystem. With the reversal of commit 601ef0d52e96 ("gfs2: Force withdraw to replay journals and wait for it to finish"), we are no longer waiting for journal recovery during a withdraw, so we no longer need to thaw frozen filesystems, either. This also fixes a potential deadlock reported by lockdep when running xfstest generic/108. In addition, there is nothing left in do_withdraw() that would require taking sd_freeze_mutex, so don't bother taking that lock there anymore. Signed-off-by: Andreas Gruenbacher

gfs2: New gfs2_withdraw_helper

2025-11-26T23:52:27Z

Currently, when a gfs2 filesystem is withdrawn, an "offline" uevent is triggered that invokes gfs2-util's gfs2_withdraw_helper script. The purpose of this script is to deactivate the filesystem's block device so that it can be withdrawn immediately, even before all the filesystem's caches have been discarded. The script provided by gfs2-utils never did anything useful, and there was no way for it to report back its status to the kernel. To fix that, extend the gfs2_withdraw_helper mechanism so that the script can report one of the following results by writing the corresponding value into "/sys$DEVPATH/lock_module/withdraw": 0 - The shared block device has been marked inactive. Future write operations will fail. 1 - The shared block device may still be active and carry out write operations. If the "offline" uevent isn't reacted upon within the timeout configured in /sys$DEVPATH/tune/withdraw_helper_timeout (default 5 seconds), the event handler is assumed to have failed. In addition, add an additional "errors=deactivate" mount option. With these changes, if fatal errors are detected on a gfs2 filesystem and the filesystem is mounted with the "errors=panic" option, the kernel will panic immediately. Otherwise, an attempt will be made to deactivate the underlying block device. If successful, the kernel will release all cluster-wide locks immediately so that the rest of the cluster can continue. If unsuccessful, the kernel will either panic ("errors=deactivate"), or it will purge all filesystem I/O before releasing all cluster-wide locks ("errors=withdraw"). Note that the gfs2_withdraw_helper script still needs to be fixed to take advantage of these improvements. It could be changed to use a mechanism like LVM Persistent Reservations. "dmsetup suspend" is not a suitable mechanism as it infinitely postpones I/O operations, which may prevent withdraw from completing. Signed-off-by: Andreas Gruenbacher

gfs2: Rename gfs2_{gl_dq_holders => withdraw_glocks}

2025-11-26T23:52:27Z

Rename function gfs2_gl_dq_holders() to gfs2_withdraw_glocks(). This function will soon be used for more than just dequeuing holders. Signed-off-by: Andreas Gruenbacher

Revert "gfs2: Force withdraw to replay journals and wait for it to finish" (6/6)

2025-11-26T23:52:27Z

The current withdraw code duplicates the journal recovery code gfs2 already has for dealing with node failures, and it does so poorly. That code was added because when releasing a lockspace, we didn't have a way to indicate that the lockspace needs recovery. We now do have this feature, so the current withdraw code can be removed almost entirely. This is one of several steps towards that. Reverts parts of commit 601ef0d52e96 ("gfs2: Force withdraw to replay journals and wait for it to finish"). Signed-off-by: Andreas Gruenbacher

Revert "gfs2: Force withdraw to replay journals and wait for it to finish" (2/6)

2025-11-26T23:52:26Z

Revert "gfs2: Force withdraw to replay journals and wait for it to finish" (1/6)

2025-11-26T23:52:26Z

Revert "gfs2: don't stop reads while withdraw in progress"

2025-11-26T23:52:26Z

The current withdraw code duplicates the journal recovery code gfs2 already has for dealing with node failures, and it does so poorly. That code was added because when releasing a lockspace, we didn't have a way to indicate that the lockspace needs recovery. We now do have this feature, so the current withdraw code can be removed almost entirely. This is one of several steps towards that. The withdrawing node has no role in recovering from the withdraw anymore, so it also no longer needs to read metadata blocks after a withdraw. We now only need to set a single bit in gfs2_withdraw(), so switch from try_cmpxchg() to test_and_set_bit(). Reverts commit 8cc67f704f4b ("gfs2: don't stop reads while withdraw in progress"). Signed-off-by: Andreas Gruenbacher

gfs2: Rename LM_FLAG_{NOEXP -> RECOVER}

2025-11-26T23:52:26Z

GFS sets the LM_FLAG_NOEXP flag on locking requests it makes during journal recovery, so rename the flag to LM_FLAG_RECOVER for improved code readability. Signed-off-by: Andreas Gruenbacher

gfs2: Kill gfs2_io_error_bh_wd

2025-11-26T23:52:26Z

All callers of gfs2_io_error_bh() call gfs2_withdraw() as well, so change gfs2_io_error_bh() to call gfs2_withdraw() directly. This also brings it in line with other similar error reporting functions. With that, gfs2_io_error_bh() is the same as gfs2_io_error_bh_wd(), so remove the latter. Signed-off-by: Andreas Gruenbacher