On 12/23/21 12:01 AM, Tetsuo Handa wrote:
> On 2021/12/23 0:56, Jens Axboe wrote:
>> On 12/22/21 8:27 AM, Tetsuo Handa wrote:
>>> 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
