On 2022/01/26 22:11, Jan Kara wrote:
> On Wed 26-01-22 19:27:17, Tetsuo Handa wrote:
>> Even if we can remove blk_mq_freeze_queue()/blk_mq_unfreeze_queue() from
>> lo_release(), we cannot remove
>> blk_mq_freeze_queue()/blk_mq_unfreeze_queue() from e.g.
>> loop_set_status(), right?
>
> Correct AFAICT.
OK.
>
>> Then, lo_release() which is called with disk->open_mutex held can be
>> still blocked at mutex_lock(&lo->lo_mutex) waiting for e.g.
>> loop_set_status() to call mutex_unlock(&lo->lo_mutex). That is,
>> lo_open() from e.g. /sys/power/resume can still wait for I/O completion
>> with disk->open_mutex held.
>
> I don't think this is a real problem. If someone is calling
> loop_set_status() it means the loop device is open and thus lo_release()
> cannot be running in parallel, can it?
lo_release() is called when a file descriptor is close()d.
That is, loop_set_status() and lo_release() can run in parallel, can't it?
Process-A Process-B
int fd1 = open("/dev/loop0", O_RDWR); int fd2 = open("/dev/loop0", O_RDWR);
ioctl(fd1, LOOP_SET_STATUS64, ...); close(fd2);
If lo_release() (which is called with disk->open_mutex held) waits for ioctl()
(which waits for I/O completion with lo->lo_mutex held), there is
disk->open_mutex => lo->lo_mutex => I/O completion dependency.
And the possibility of deadlock problem (when mixed with sysfs and fsfreeze)
happens at lo_open(). If lo_open() (which is called with disk->open_mutex held)
waits for ioctl() (which waits for I/O completion with lo->lo_mutex held), there
as well is disk->open_mutex => lo->lo_mutex => I/O completion dependency.
