Re: [PATCH] iomap: reject delalloc mappings during writeback

["Darrick J. Wong" <djwong@kernel.org>]

On Thu, Feb 26, 2026 at 01:29:37PM -0800, Christoph Hellwig wrote:
> On Thu, Feb 26, 2026 at 10:00:58AM -0800, Darrick J. Wong wrote:
> > From: Darrick J. Wong <djwong@kernel.org>
> > 
> > Filesystems should never provide a delayed allocation mapping to
> > writeback; they're supposed to allocate the space before replying.
> > This can lead to weird IO errors and crashes in the block layer if the
> > filesystem is being malicious, or if it hadn't set iomap->dev because
> > it's a delalloc mapping.
> > 
> > Fix this by failing writeback on delalloc mappings.  Currently no
> > filesystems actually misbehave in this manner, but we ought to be
> > stricter about things like that.
> 
> Maybe switch to to explicitly listing the acceptable types and rejecting
> the rest instead?

Yeah, that's a better solution, particularly if we ever add a new
mapping type.

--D

> diff --git a/fs/iomap/ioend.c b/fs/iomap/ioend.c
> index e4d57cb969f1..2dd49677905f 100644
> --- a/fs/iomap/ioend.c
> +++ b/fs/iomap/ioend.c
> @@ -169,17 +169,18 @@ ssize_t iomap_add_to_ioend(struct iomap_writepage_ctx *wpc, struct folio *folio,
>  	WARN_ON_ONCE(!folio->private && map_len < dirty_len);
>  
>  	switch (wpc->iomap.type) {
> -	case IOMAP_INLINE:
> -		WARN_ON_ONCE(1);
> -		return -EIO;
> +	case IOMAP_UNWRITTEN:
> +		ioend_flags |= IOMAP_IOEND_UNWRITTEN;
> +		fallthrough;
> +	case IOMAP_MAPPED:
> +		break;
>  	case IOMAP_HOLE:
>  		return map_len;
>  	default:
> -		break;
> +		WARN_ON_ONCE(1);
> +		return -EIO;
>  	}
>  
> -	if (wpc->iomap.type == IOMAP_UNWRITTEN)
> -		ioend_flags |= IOMAP_IOEND_UNWRITTEN;
>  	if (wpc->iomap.flags & IOMAP_F_SHARED)
>  		ioend_flags |= IOMAP_IOEND_SHARED;
>  	if (folio_test_dropbehind(folio))
>