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 ?
