kernel/git/stable/linux.git/fs/gfs2/sys.c, branch master

gfs2: Skip dlm unlocks earlier

2026-07-19T13:19:21+00:00

When we were still caching unreferenced glocks, evicting all the cached inodes in gfs2_kill_sb() did put the unreferenced glocks onto the glock lru list, and they would be freed in gfs2_gl_hash_clear(). We could set the SDF_SKIP_DLM_UNLOCK flag in gfs2_gl_hash_clear() to indicate to gdlm_put_lock() to skip unlocking glocks explicitly when possible. Now, glocks are demoted and dropped immediately though, so to allow gdlm_put_lock() to skip unnecessary unlocking, we need to set some "unmount" flag before calling gfs2_evict_inodes(). We can use the existing SDF_KILL flag for that if we set it before calling gfs2_evict_inodes() in gfs2_kill_sb(). Signed-off-by: Andreas Gruenbacher

gfs2: New gfs2_withdraw_helper

2025-11-26T23:52:27+00:00

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

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

2025-11-26T23:52:27+00:00

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" (1/6)

2025-11-26T23:52:26+00:00

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

2025-11-26T23:52:26+00:00

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 gfs2_{withdrawing_or_ => }withdrawn

2025-11-26T23:52:23+00:00

With delayed withdraws and the SDF_WITHDRAWING flag gone, we can now rename gfs2_withdrawing_or_withdrawn() back to gfs2_withdrawn(). Signed-off-by: Andreas Gruenbacher

gfs2: Get rid of delayed withdraws

2025-11-26T23:51:47+00:00

Now that gfs2_withdraw() is asynchronous, is can be called in any context and there is no more need for gfs2_withdraw_delayed() or for turning delayed withdraws into actual withdraws. Remove the now-obsolete code. Signed-off-by: Andreas Gruenbacher

gfs2/sysfs: Replace sprintf/snprintf with sysfs_emit

2025-10-31T21:00:42+00:00

Documentation/filesystems/sysfs.rst mentions that show() should only use sysfs_emit() or sysfs_emit_at() when formatting values returned to user space. This patch updates the GFS2 sysfs interface accordingly. It replaces uses of sprintf() and snprintf() in all *_show() functions with sysfs_emit() to align with current kernel sysfs API best practices. It also updates the TUNE_ATTR_2 macro to use sysfs_emit() instead of snprintf(). Signed-off-by: Utkarsh Singh Signed-off-by: Andreas Gruenbacher

gfs2: Don't clear sb->s_fs_info in gfs2_sys_fs_add

2025-05-30T17:20:20+00:00

When gfs2_sys_fs_add() fails, it sets sb->s_fs_info to NULL on its error path (see commit 0d515210b696 ("GFS2: Add kobject release method")). The intention seems to be to prevent dereferencing sb->s_fs_info once the object pointed to has been deallocated, but that would be better achieved by setting the pointer to NULL in free_sbd(). As a consequence, when the call to gfs2_sys_fs_add() fails in gfs2_fill_super(), sdp = GFS2_SB(inode) will evaluate to NULL in iput() -> gfs2_drop_inode(), and accessing sdp->sd_flags will be a NULL pointer dereference. Fix that by only setting sb->s_fs_info to NULL when actually freeing the object pointed to in free_sbd(). Fixes: ae9f3bd8259a ("gfs2: replace sd_aspace with sd_inode") Reported-by: syzbot+b12826218502df019f9d@syzkaller.appspotmail.com Signed-off-by: Andrew Price Signed-off-by: Andreas Gruenbacher

super: add filesystem freezing helpers for suspend and hibernate

2025-05-09T10:41:02+00:00

Allow the power subsystem to support filesystem freeze for suspend and hibernate. For some kernel subsystems it is paramount that they are guaranteed that they are the owner of the freeze to avoid any risk of deadlocks. This is the case for the power subsystem. Enable it to recognize whether it did actually freeze the filesystem. If userspace has 10 filesystems and suspend/hibernate manges to freeze 5 and then fails on the 6th for whatever odd reason (current or future) then power needs to undo the freeze of the first 5 filesystems. It can't just walk the list again because while it's unlikely that a new filesystem got added in the meantime it still cannot tell which filesystems the power subsystem actually managed to get a freeze reference count on that needs to be dropped during thaw. There's various ways out of this ugliness. For example, record the filesystems the power subsystem managed to freeze on a temporary list in the callbacks and then walk that list backwards during thaw to undo the freezing or make sure that the power subsystem just actually exclusively freezes things it can freeze and marking such filesystems as being owned by power for the duration of the suspend or resume cycle. I opted for the latter as that seemed the clean thing to do even if it means more code changes. If hibernation races with filesystem freezing (e.g. DM reconfiguration), then hibernation need not freeze a filesystem because it's already frozen but userspace may thaw the filesystem before hibernation actually happens. If the race happens the other way around, DM reconfiguration may unexpectedly fail with EBUSY. So allow FREEZE_EXCL to nest with other holders. An exclusive freezer cannot be undone by any of the other concurrent freezers. Link: https://lore.kernel.org/r/20250329-work-freeze-v2-6-a47af37ecc3d@kernel.org Reviewed-by: Jan Kara Signed-off-by: Christian Brauner