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

[syzbot] possible deadlock in blkdev_put (2) · syzbot <hidden> · 2021-11-27
Re: [syzbot] possible deadlock in blkdev_put (2) · Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> · 2021-11-27
Re: [syzbot] possible deadlock in blkdev_put (2) · Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp> · 2021-11-28
Re: [syzbot] possible deadlock in blkdev_put (2) · Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp> · 2021-11-28
Re: [syzbot] possible deadlock in blkdev_put (2) · Christoph Hellwig <hch@infradead.org> · 2021-11-29
Re: [syzbot] possible deadlock in blkdev_put (2) · Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp> · 2021-11-29
Re: [syzbot] possible deadlock in blkdev_put (2) · Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp> · 2021-11-29
Re: [syzbot] possible deadlock in blkdev_put (2) · Christoph Hellwig <hch@infradead.org> · 2021-11-30
[PATCH] loop: make autoclear operation asynchronous · Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp> · 2021-12-01
Re: [PATCH] loop: make autoclear operation asynchronous · Christoph Hellwig <hch@infradead.org> · 2021-12-02
Re: [PATCH] loop: make autoclear operation asynchronous · Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp> · 2021-12-02
Re: [PATCH] loop: make autoclear operation asynchronous · Jan Kara <jack@suse.cz> · 2021-12-02
Re: [PATCH] loop: make autoclear operation asynchronous · Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp> · 2021-12-02
Re: [PATCH] loop: make autoclear operation asynchronous · Jan Kara <jack@suse.cz> · 2021-12-02
Re: [PATCH] loop: make autoclear operation asynchronous · Christoph Hellwig <hch@infradead.org> · 2021-12-03
Re: [PATCH] loop: make autoclear operation asynchronous · Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp> · 2021-12-03
Re: [PATCH] loop: make autoclear operation asynchronous · Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp> · 2021-12-08
Re: [syzbot] possible deadlock in blkdev_put (2) · syzbot <hidden> · 2021-12-08
Re: [syzbot] possible deadlock in blkdev_put (2) · syzbot <hidden> · 2021-12-08

From: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>
Date: 2021-11-28 07:44:59

On 2021/11/28 14:32, Tetsuo Handa wrote:

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?

`h`	back out one level
`j`	next message in thread
`k`	previous message in thread
`l`	drill in
`Esc`	close help / fold thread tree
`?`	toggle this help