linux-kernel - Re: [PATCH] xfs: report a writeback error on a read() call

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-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <aF0gEWcA6bX1eNzU@infradead.org>
Date: Thu, 26 Jun 2025 03:25:21 -0700
From: Christoph Hellwig <hch@...radead.org>
To: Dave Chinner <david@...morbit.com>
Cc: Yafang Shao <laoar.shao@...il.com>, Jeff Layton <jlayton@...nel.org>,
	Christoph Hellwig <hch@...radead.org>, djwong@...nel.org,
	linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
	linux-xfs@...r.kernel.org, yc1082463@...il.com
Subject: Re: [PATCH] xfs: report a writeback error on a read() call

On Thu, Jun 26, 2025 at 01:57:59PM +1000, Dave Chinner wrote:
> writeback errors. Because scientists and data analysts that wrote
> programs to chew through large amounts of data didn't care about
> persistence of their data mid-processing. They just wanted what they
> wrote to be there the next time the processing pipeline read it.

That's only going to work if your RAM is as large as your permanent
storage :)

> IOWs, checking for a past writeback IO error is as simple as:
> 
> 	if (sync_file_range(fd, 0, 0, SYNC_FILE_RANGE_WAIT_BEFORE) < 0) {
> 		/* An unreported writeback error was pending on the file */
> 		wb_err = -errno;
> 		......
> 	}
> 
> This does not cause new IO to be issued, it only blocks on writeback
> that is currently in progress, and it has no data integrity
> requirements at all. If the writeback has already been done, all it
> will do is sweep residual errors out to userspace.....

Not quite.

This will still wait for all I/O on the range, and given that
sync_file_range treats a 0 length as the entire file that might actually
do a significant amount of waiting.  But yes, it's the closest we get
right now.