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