Same reproducer applies. Need to avoid destroy_workqueue() with &disk->open_mutex held. ---------------------------------------- #include <stdio.h> #include <stdlib.h> #include <sys/types.h> #include <sys/stat.h> #include <fcntl.h> #include <unistd.h> #include <sys/ioctl.h> #include <linux/loop.h> #include <sys/sendfile.h> int main(int argc, char *argv[]) { const int file_fd = open("testfile", O_RDWR | O_CREAT, 0600); ftruncate(file_fd, 1048576); char filename[128] = { }; const int loop_num = ioctl(open("/dev/loop-control", 3), LOOP_CTL_GET_FREE, 0); snprintf(filename, sizeof(filename) - 1, "/dev/loop%d", loop_num); const int loop_fd_1 = open(filename, O_RDWR); ioctl(loop_fd_1, LOOP_SET_FD, file_fd); const int loop_fd_2 = open(filename, O_RDWR); ioctl(loop_fd_1, LOOP_CLR_FD, 0); const int sysfs_fd = open("/sys/power/resume", O_RDWR); sendfile(file_fd, sysfs_fd, 0, 1048576); sendfile(loop_fd_2, file_fd, 0, 1048576); write(sysfs_fd, "700", 3); return 0; } ---------------------------------------- #syz dup: possible deadlock in blkdev_put (2) I think that not only we can remove destroy_workqueue() from __loop_clear_fd() but also we can make whole __loop_clear_fd() be called without &disk->open_mutex held. Jens, any questions remaining on https://lkml.kernel.org/r/c205dcd2-db55-a35c-e2ef-20193b5ac0da@xxxxxxxxxxxxxxxxxxx ?