]> www.infradead.org Git - users/hch/block.git/commit
make autoclear operation synchronous again part_tbl_mutex
authorTetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>
Sun, 26 Dec 2021 07:06:27 +0000 (16:06 +0900)
committerChristoph Hellwig <hch@lst.de>
Thu, 20 Jan 2022 07:37:59 +0000 (08:37 +0100)
commitbafaf27edb6e6bdf824d4c4ab045326eb064415b
tree5162335befe97a0b8cd02222295f1048628593e1
parent4d3e705f87e304a12c650c32ef6d41fbcdb75086
make autoclear operation synchronous again

The kernel test robot is reporting that xfstest can fail at

  umount ext2 on xfs
  umount xfs

sequence, for commit 322c4293ecc58110 ("loop: make autoclear operation
asynchronous") broke what commit ("loop: Make explicit loop device
destruction lazy") wanted to achieve.

Although we cannot guarantee that nobody is holding a reference when
"umount xfs" is called, we should try to close a race window opened
by asynchronous autoclear operation.

It turned out that there is no need to call flush_workqueue() from
__loop_clr_fd(), for blk_mq_freeze_queue() blocks until all pending
"struct work_struct" are processed by loop_process_work().

Revert commit 322c4293ecc58110 ("loop: make autoclear operation
asynchronous"), and simply defer calling destroy_workqueue() till
loop_remove().

Since a loop device is likely reused after once created thanks to
ioctl(LOOP_CTL_GET_FREE), being unable to destroy corresponding WQ
when ioctl(LOOP_CLR_FD) is called should be an acceptable waste.

Reported-by: kernel test robot <oliver.sang@intel.com>
Suggested-by: Christoph Hellwig <hch@lst.de>
Tested-by: syzbot <syzbot+643e4ce4b6ad1347d372@syzkaller.appspotmail.com>
Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Signed-off-by: Christoph Hellwig <hch@lst.de>
drivers/block/loop.c
drivers/block/loop.h