<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/fs/gfs2/sys.c, branch v6.19.12</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v6.19.12</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v6.19.12'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2025-11-26T23:52:27+00:00</updated>
<entry>
<title>gfs2: New gfs2_withdraw_helper</title>
<updated>2025-11-26T23:52:27+00:00</updated>
<author>
<name>Andreas Gruenbacher</name>
<email>agruenba@redhat.com</email>
</author>
<published>2025-08-02T10:56:37+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=bbbf1529ea9b85072e58c164a9a5d82554ffa941'/>
<id>urn:sha1:bbbf1529ea9b85072e58c164a9a5d82554ffa941</id>
<content type='text'>
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 &lt;agruenba@redhat.com&gt;
</content>
</entry>
<entry>
<title>Revert "gfs2: Force withdraw to replay journals and wait for it to finish" (3/6)</title>
<updated>2025-11-26T23:52:27+00:00</updated>
<author>
<name>Andreas Gruenbacher</name>
<email>agruenba@redhat.com</email>
</author>
<published>2025-07-25T19:40:45+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=4cee5b0f7a82776dfcb33bc28b236a289d0e6b4c'/>
<id>urn:sha1:4cee5b0f7a82776dfcb33bc28b236a289d0e6b4c</id>
<content type='text'>
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 &lt;agruenba@redhat.com&gt;
</content>
</entry>
<entry>
<title>Revert "gfs2: Force withdraw to replay journals and wait for it to finish" (1/6)</title>
<updated>2025-11-26T23:52:26+00:00</updated>
<author>
<name>Andreas Gruenbacher</name>
<email>agruenba@redhat.com</email>
</author>
<published>2025-08-05T21:43:12+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=20b44ddbbb0712db15c6946eb94a9e240c1ba271'/>
<id>urn:sha1:20b44ddbbb0712db15c6946eb94a9e240c1ba271</id>
<content type='text'>
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 &lt;agruenba@redhat.com&gt;
</content>
</entry>
<entry>
<title>Revert "gfs2: don't stop reads while withdraw in progress"</title>
<updated>2025-11-26T23:52:26+00:00</updated>
<author>
<name>Andreas Gruenbacher</name>
<email>agruenba@redhat.com</email>
</author>
<published>2025-07-25T20:06:56+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=833c93caea00b0aef3e22a08fd20acacf212b6fc'/>
<id>urn:sha1:833c93caea00b0aef3e22a08fd20acacf212b6fc</id>
<content type='text'>
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 &lt;agruenba@redhat.com&gt;
</content>
</entry>
<entry>
<title>gfs2: Rename gfs2_{withdrawing_or_ =&gt; }withdrawn</title>
<updated>2025-11-26T23:52:23+00:00</updated>
<author>
<name>Andreas Gruenbacher</name>
<email>agruenba@redhat.com</email>
</author>
<published>2025-08-06T15:30:40+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=1b7d498dcab489c4bcbc46870264fbeaf81c16e7'/>
<id>urn:sha1:1b7d498dcab489c4bcbc46870264fbeaf81c16e7</id>
<content type='text'>
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 &lt;agruenba@redhat.com&gt;
</content>
</entry>
<entry>
<title>gfs2: Get rid of delayed withdraws</title>
<updated>2025-11-26T23:51:47+00:00</updated>
<author>
<name>Andreas Gruenbacher</name>
<email>agruenba@redhat.com</email>
</author>
<published>2025-08-05T21:32:39+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=8daf6c2b3d8ceea5559cceb8ed7e1275ee72a7be'/>
<id>urn:sha1:8daf6c2b3d8ceea5559cceb8ed7e1275ee72a7be</id>
<content type='text'>
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 &lt;agruenba@redhat.com&gt;
</content>
</entry>
<entry>
<title>gfs2/sysfs: Replace sprintf/snprintf with sysfs_emit</title>
<updated>2025-10-31T21:00:42+00:00</updated>
<author>
<name>Utkarsh Singh</name>
<email>utkarsh.singh.em@gmail.com</email>
</author>
<published>2025-09-22T17:52:22+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=02c03021e2fced59b3b5b200fdd00018725d4ee2'/>
<id>urn:sha1:02c03021e2fced59b3b5b200fdd00018725d4ee2</id>
<content type='text'>
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 &lt;utkarsh.singh.em@gmail.com&gt;
Signed-off-by: Andreas Gruenbacher &lt;agruenba@redhat.com&gt;
</content>
</entry>
<entry>
<title>gfs2: Don't clear sb-&gt;s_fs_info in gfs2_sys_fs_add</title>
<updated>2025-05-30T17:20:20+00:00</updated>
<author>
<name>Andrew Price</name>
<email>anprice@redhat.com</email>
</author>
<published>2025-05-28T15:02:37+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=9126d2754c5e5d1818765811a10af0a14cf1fa0a'/>
<id>urn:sha1:9126d2754c5e5d1818765811a10af0a14cf1fa0a</id>
<content type='text'>
When gfs2_sys_fs_add() fails, it sets sb-&gt;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-&gt;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()
-&gt; gfs2_drop_inode(), and accessing sdp-&gt;sd_flags will be a NULL pointer
dereference.

Fix that by only setting sb-&gt;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 &lt;anprice@redhat.com&gt;
Signed-off-by: Andreas Gruenbacher &lt;agruenba@redhat.com&gt;
</content>
</entry>
<entry>
<title>super: add filesystem freezing helpers for suspend and hibernate</title>
<updated>2025-05-09T10:41:02+00:00</updated>
<author>
<name>Christian Brauner</name>
<email>brauner@kernel.org</email>
</author>
<published>2025-03-29T08:42:19+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=1af3331764b9356fadc4652af77bbbc97f3d7f78'/>
<id>urn:sha1:1af3331764b9356fadc4652af77bbbc97f3d7f78</id>
<content type='text'>
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 &lt;jack@suse.cz&gt;
Signed-off-by: Christian Brauner &lt;brauner@kernel.org&gt;
</content>
</entry>
<entry>
<title>gfs2: Use [NO_]CREATE consistently for gfs2_glock_get</title>
<updated>2024-04-09T16:35:57+00:00</updated>
<author>
<name>Andreas Gruenbacher</name>
<email>agruenba@redhat.com</email>
</author>
<published>2024-01-15T21:01:12+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=3592bfaf746a4d0fefe6fe11527aa335073674c1'/>
<id>urn:sha1:3592bfaf746a4d0fefe6fe11527aa335073674c1</id>
<content type='text'>
When calling gfs2_glock_get(), consistently pass the CREATE or NO_CREATE
flag for the create argument.  This is the only place that passes 0
instead.

Signed-off-by: Andreas Gruenbacher &lt;agruenba@redhat.com&gt;
</content>
</entry>
</feed>
