Re: [PATCH v2] loop: fix I/O error on fsync() in detached loop devices

[Ming Lei <ming.lei@redhat.com>]

On Tue, Jan 05, 2021 at 10:54:19AM -0300, Mauricio Faria de Oliveira wrote:
> There's an I/O error on fsync() in a detached loop device
> if it has been previously attached.
> 
> The issue is write cache is enabled in the attach path in
> loop_configure() but it isn't disabled in the detach path;
> thus it remains enabled in the block device regardless of
> whether it is attached or not.
> 
> Now fsync() can get an I/O request that will just be failed
> later in loop_queue_rq() as device's state is not 'Lo_bound'.
> 
> So, disable write cache in the detach path.
> 
> Test-case:
> 
>     # DEV=/dev/loop7
> 
>     # IMG=/tmp/image
>     # truncate --size 1M $IMG
> 
>     # losetup $DEV $IMG
>     # losetup -d $DEV
> 
> Before:
> 
>     # strace -e fsync parted -s $DEV print 2>&1 | grep fsync
>     fsync(3)                                = -1 EIO (Input/output error)
>     Warning: Error fsyncing/closing /dev/loop7: Input/output error
>     [  982.529929] blk_update_request: I/O error, dev loop7, sector 0 op 0x1:(WRITE) flags 0x800 phys_seg 0 prio class 0
> 
> After:
> 
>     # strace -e fsync parted -s $DEV print 2>&1 | grep fsync
>     fsync(3)                                = 0

But IO on detached loop should have been failed, right? The magic is
that submit_bio_checks() filters FLUSH request for queues which doesn't
support writeback cache, and always fake a normal completion.

I understand that the issue is that user becomes confused with this observation
because no such failure if they run 'parted -s /dev/loop0 print' on one detached
loop disk if it is never attached.


Thanks, 
Ming