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: <6ac46aa32eee969d9d8bc55be035247e3fdc0ac8.camel@kernel.org>
Date: Wed, 25 Jun 2025 07:49:31 -0400
From: Jeff Layton <jlayton@...nel.org>
To: Christoph Hellwig <hch@...radead.org>
Cc: 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, 2025-06-25 at 04:21 -0700, Christoph Hellwig wrote:
> 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.

It is weird, but I do sort of get the motivation.

In a some cases you want to be able to stream writes as fast as
possible and let the kernel lazily write that back (because you don't
want to block a thread), but knowing if a prior writeback error has
occurred is a good thing too.

Another idea: add a new generic ioctl() that checks for writeback
errors without syncing anything. That would be fairly simple to do and
sounds like it would be useful, but I'd want to hear a better
description of the use-case before we did anything like that.
-- 
Jeff Layton <jlayton@...nel.org>