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: <e4d49263644f7704074ea0a5149fd834fb3f3603.camel@kernel.org>
Date: Tue, 24 Jun 2025 16:25:41 -0400
From: Jeff Layton <jlayton@...nel.org>
To: Matthew Wilcox <willy@...radead.org>
Cc: Christoph Hellwig <hch@...radead.org>, ying chen <yc1082463@...il.com>, 
	djwong@...nel.org, linux-xfs@...r.kernel.org, linux-kernel@...r.kernel.org,
 	linux-fsdevel@...r.kernel.org
Subject: Re: [PATCH] xfs: report a writeback error on a read() call

On Tue, 2025-06-24 at 20:56 +0100, Matthew Wilcox wrote:
> On Tue, Jun 24, 2025 at 02:26:18PM -0400, Jeff Layton wrote:
> > On Tue, 2025-06-24 at 07:14 -0700, Christoph Hellwig wrote:
> > > On Sun, Jun 22, 2025 at 08:32:18PM +0800, ying chen wrote:
> > > > Normally, user space returns immediately after writing data to the
> > > > buffer cache. However, if an error occurs during the actual disk
> > > > write operation, data loss may ensue, and there is no way to report
> > > > this error back to user space immediately. Current kernels may report
> > > > writeback errors when fsync() is called, but frequent invocations of
> > > > fsync() can degrade performance. Therefore, a new sysctl
> > > > fs.xfs.report_writeback_error_on_read is introduced, which, when set
> > > > to 1, reports writeback errors when read() is called. This allows user
> > > > space to be notified of writeback errors more promptly.
> > > 
> > > That's really kernel wide policy and not something magic done by a
> > > single file system.
> > 
> > ...not to mention that getting an error back on a read for a prior
> > writeback error would be completely unexpected by most applications.
> 
> Well.  It's somewhat understandable:
> 
> 	write() (returns success)
> 	writeback happens, error logged
> 	memory pressure evicts folio
> 	read() brings folio into page cache
> 	attempt to read contents fails, error returned
> 
> I'm not sure it's a good solution, but it's plausible.

Personally, I find it confusing. The range you're trying to read might
actually be fine if the error happened in a different range.

It also has the same problem as reporting writeback errors on close(),
in that it's non-deterministic. You might not see an error if writeback
didn't happen yet. Just because you didn't get an error when reading,
that doesn't mean that your data is actually safe.

Maybe this is ok as an opt-in thing for some workloads, but it does
have some potential footguns.
-- 
Jeff Layton <jlayton@...nel.org>