Andreas Gruenbacher 1c5ffd27c5 gfs2: don't withdraw if init_threads() got interrupted
commit 0cdc6f44e9fdc2d20d720145bf99a39f611f6d61 upstream.

In gfs2_fill_super(), when mounting a gfs2 filesystem is interrupted,
kthread_create() can return -EINTR.  When that happens, we roll back
what has already been done and abort the mount.

Since commit 62dd0f98a0e5 ("gfs2: Flag a withdraw if init_threads()
fails), we are calling gfs2_withdraw_delayed() in gfs2_fill_super();
first via gfs2_make_fs_rw(), then directly.  But gfs2_withdraw_delayed()
only marks the filesystem as withdrawing and relies on a caller further
up the stack to do the actual withdraw, which doesn't exist in the
gfs2_fill_super() case.  Because the filesystem is marked as withdrawing
/ withdrawn, function gfs2_lm_unmount() doesn't release the dlm
lockspace, so when we try to mount that filesystem again, we get:

    gfs2: fsid=gohan:gohan0: Trying to join cluster "lock_dlm", "gohan:gohan0"
    gfs2: fsid=gohan:gohan0: dlm_new_lockspace error -17

Since commit b77b4a4815a9 ("gfs2: Rework freeze / thaw logic"), the
deadlock this gfs2_withdraw_delayed() call was supposed to work around
cannot occur anymore because freeze_go_callback() won't take the
sb->s_umount semaphore unconditionally anymore, so we can get rid of the
gfs2_withdraw_delayed() in gfs2_fill_super() entirely.

Reported-by: Alexander Aring <aahringo@redhat.com>
Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com>
Cc: stable@vger.kernel.org # v6.5+
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-11-28 17:15:13 +00:00
..
2023-01-19 09:24:28 +01:00
2023-01-19 09:24:27 +01:00
2023-09-19 12:30:13 +02:00
2023-06-06 18:35:06 +02:00
2023-04-18 14:40:12 +02:00
2022-08-06 14:44:49 -07:00
2023-08-07 18:42:04 +02:00
2023-10-06 13:16:17 +02:00
2023-10-06 13:15:45 +02:00
2023-09-19 12:30:13 +02:00
2023-11-28 17:14:51 +00:00
2023-11-28 17:14:51 +00:00
2023-07-03 22:25:02 +02:00
2023-07-03 22:30:48 +02:00
2023-07-03 22:30:26 +02:00
2023-03-06 09:57:12 +01:00