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: <aFvbr6H3WUyix2fR@infradead.org>
Date: Wed, 25 Jun 2025 04:21:19 -0700
From: Christoph Hellwig <hch@...radead.org>
To: Jeff Layton <jlayton@...nel.org>
Cc: Christoph Hellwig <hch@...radead.org>,
	Yafang Shao <laoar.shao@...il.com>, david@...morbit.com,
	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 Wed, Jun 25, 2025 at 06:40:07AM -0400, Jeff Layton wrote:
> Another option:
> 
> We could expose this functionality in preadv2() with a new RWF_WBERR
> flag (better names welcome). That way applications could opt-in to
> checking for writeback errors like this. With that, the application is
> at least explicitly saying that it wants this behavior.

That sounds like a really strange interface to me.

I have to admit I don't fully understand the use case where an
application cares about these errors, but also doesn't use f(data)sync
or sync(fs) to actually persist the data.  If we can come up with a
coherent use case for that we should simply add a new syscall or fcntl
to query the delayed writeback errors instead of overloading other
interfaces.