Re: [PATCH 2/2] loop: use task_work for autoclear operation

On 12/23/21 12:01 AM, Tetsuo Handa wrote:

On 2021/12/23 0:56, Jens Axboe wrote:

quoted

On 12/22/21 8:27 AM, Tetsuo Handa wrote:

quoted

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.

Try to make the autoclear operation upon close() synchronous, by calling
__loop_clr_fd() from current thread's task work rather than a WQ thread.

Doesn't this potentially race with fput?

What race?

loop_schedule_rundown() is called from lo_release() from blkdev_put()
from blkdev_close() from __fput() from task_work_run(). And
loop_schedule_rundown() calls kobject_get(&bdev->bd_device.kobj)
before put_device() from blkdev_put_no_open() from blkdev_put() from
blkdev_close() from __fput() from task_work_run() calls
kobject_put(&bdev->bd_device.kobj).

Race is the wrong word, I mean ordering issues. If the fput happens
before you queue your task_work, then it'll be run before that.

-- 
Jens Axboe