linux-ext4 - [PATCH RFC 0/2] iomap: ->iomap

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <20250902150755.289469-1-bfoster@redhat.com>
Date: Tue,  2 Sep 2025 11:07:53 -0400
From: Brian Foster <bfoster@...hat.com>
To: linux-fsdevel@...r.kernel.org,
	linux-ext4@...r.kernel.org,
	linux-xfs@...r.kernel.org
Cc: jack@...e.cz,
	djwong@...nel.org
Subject: [PATCH RFC 0/2] iomap: ->iomap_end() error handling fixes

Hi all,

This is a couple small error handling fixes for ->iomap_end() errors
(via iomap_iter()). The immediate problem here was that the
->iomap_end() error return started overriding an iter.status error code,
which on ext4 happened to trigger dio fallback to buffered I/O in some
cases. Jan has actually fixed that separately in ext4 [1], but I wanted
to take an independent look at iomap to see if it is worth fixing as
well.

The more I poked around the more it seemed like it's more appropriate to
return the initial error code in iter.status if one is pending. I also
eventually noticed the DAX vs. reflink case documented in patch 2, which
further tweaks the error handling and supports the former reasoning.

These are separate patches because they are separate issues, but I'm
still doing some testing and wanted to see if there was any initial
feedback before dropping the RFC. Thoughts?

Brian

[1] https://lore.kernel.org/linux-ext4/20250901112739.32484-2-jack@suse.cz/

Brian Foster (2):
  iomap: prioritize iter.status error over ->iomap_end()
  iomap: revert the iomap_iter pos on ->iomap_end() error

 fs/iomap/iter.c | 20 +++++++++++++++++++-
 1 file changed, 19 insertions(+), 1 deletion(-)

-- 
2.51.0