Comment 14 for bug 1973167

I have found a change between 176 and 177 that looks suspicious:

diff -upr --color 176/linux-source-4.15.0/kernel/module.c 177/linux-source-4.15.0/kernel/module.c
--- 176/linux-source-4.15.0/kernel/module.c 2022-03-29 19:39:48.000000000 +0200
+++ 177/linux-source-4.15.0/kernel/module.c 2022-04-14 22:22:50.000000000 +0200
@@ -3520,22 +3514,13 @@ static noinline int do_init_module(struc

- /*
- * We need to finish all async code before the module init sequence
- * is done. This has potential to deadlock. For example, a newly
- * detected block device can trigger request_module() of the
- * default iosched from async probing task. Once userland helper
- * reaches here, async_synchronize_full() will wait on the async
- * task waiting on request_module() and deadlock.
- *
- * This deadlock is avoided by perfomring async_synchronize_full()
- * iff module init queued any async jobs. This isn't a full
- * solution as it will deadlock the same if module loading from
- * async jobs nests more than once; however, due to the various
- * constraints, this hack seems to be the best option for now.
- * Please refer to the following thread for details.
- *
- * http://thread.gmane.org/gmane.linux.kernel/1420814
- */
- if (!mod->async_probe_requested && (current->flags & PF_USED_ASYNC))
+ /*
+ * We need to finish all async code before the module init sequence
+ * is done. This has potential to deadlock if synchronous module
+ * loading is requested from async (which is not allowed!).
+ *
+ * See commit 0fdff3ec6d87 ("async, kmod: warn on synchronous
+ * request_module() from async workers") for more details.
+ */
+ if (!mod->async_probe_requested)
   async_synchronize_full();

Maybe this is the deadlock we're all running into...?