Comment 0 for bug 1834693

What I expected to happen: Loops can be successfully created and removed from multiple different threads without any adverse effects
What happened instead: Udev processes ended up in D state, which soft locked the system (unable to reboot without resorting to "echo b > /proc/sysrq-trigger", various other commands [losetup -a, mount -l] would hang)

The use case that this was originally reproduced on required frequent setup and teardown of loops in order to persist and access various snapshots of backup files. Through various methods of analysis, we were able to create a script that recreates the bad behavior relatively quickly (see attachment testudevLoopOnly.php).

We captured some stack traces from a locked up system, and found that many of the calls were originating from loop.c. Investigating that file (specifically lo_setup and lo_release functions) showed that the 4.4 usage of mutexes is different from earlier versions of the kernel package (4.4.0.142.148), which doesn't exhibit this same behavior. It's also different from the 4.15 version of the kernel package, which also does not exhibit the same (incorrect) behavior.