Andreas Gruenbacher c7e9a84826 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:20:11 +00:00
..
2023-01-19 09:24:27 +01:00
2023-09-05 13:00:28 -07:00
2023-09-05 13:00:28 -07:00
2023-04-18 14:40:12 +02:00
2023-08-31 15:02:12 -07:00
2023-09-18 16:00:50 +02:00
2023-09-05 15:58:16 +02:00
2023-09-18 16:00:49 +02:00
2023-08-02 09:13:09 -06:00
2023-09-05 15:58:16 +02:00
2023-09-05 15:58:17 +02:00
2023-11-28 17:19:46 +00:00
2023-09-18 16:26:24 +02:00
2023-09-05 13:00:28 -07:00
2023-09-05 15:58:17 +02:00
2023-07-03 22:30:26 +02:00