ACK: [SRU][B][PATCH 0/1] loop: fix I/O error on fsync() in detached loop devices

Tim Gardner tim.gardner at canonical.com
Fri Mar 31 13:15:02 UTC 2023


On 3/30/23 3:56 PM, Jorge Merlino wrote:
> BugLink: https://bugs.launchpad.net/bugs/1856871
> 
> SRU Justification:
> 
> [Impact]
> 
> * There's an I/O error on fsync() in a detached loop device if it has
> been previously attached. The issue is that 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.
> 
> * fsync() on detached loop devices can be called by partition tools and
> commands run by sosreport, so the unexpected kernel error message might
> surprise users or even distract from the actual issue being
> investigatedr. It might also trigger alerts in
> logging/monitoring/alerting stacks
> 
> [Fix]
> 
> * Disable write cache in the detach path
> 
> [Test Plan]
> 
> * Attach and detach an image to a loop device and test fsync return
> value aterwards
> 
> # 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
> 
> [Where problems could occur]
> 
> * The detach path for block devices is modified. Worst case scenario
> would be an error when detaching loop devices.
> 
> Mauricio Faria de Oliveira (1):
>    loop: fix I/O error on fsync() in detached loop devices
> 
>   drivers/block/loop.c | 3 +++
>   1 file changed, 3 insertions(+)
> 
Acked-by: Tim Gardner <tim.gardner at canonical.com>
-- 
-----------
Tim Gardner
Canonical, Inc




More information about the kernel-team mailing list