Thread (19 messages) flat view 19 messages, 4 authors, 2021-12-08

Re: [syzbot] possible deadlock in blkdev_put (2)

From: Christoph Hellwig <hch@infradead.org>
Date: 2021-11-29 11:05:37

On Sun, Nov 28, 2021 at 04:42:35PM +0900, Tetsuo Handa wrote:
On 2021/11/28 14:32, Tetsuo Handa wrote:
quoted
If we can unconditionally start __loop_clr_fd() upon ioctl(LOOP_CLR_FD), I think
we can avoid circular locking between disk->open_mutex and flush_workqueue().
Too bad. There is ioctl(LOOP_SET_STATUS) which allows forcing __loop_clr_fd() to be
called without ioctl(LOOP_CLR_FD). We have to support __loop_clr_fd() upon lo_release().

Is dropping disk->open_mutex inside lo_release()
( https://lkml.kernel.org/r/e4bdc6b1-701d-6cc1-5d42-65564d2aa089@I-love.SAKURA.ne.jp ) possible?
I don't think we can drop open_mutex inside ->release. What is the
problem with offloading the clearing to a different context than the
one that calls ->release?
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help