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: <CALOAHbDtFh5P_P0aTzaKRcwGfQmkrhgmk09BQ1tu9ZdXvKi8vQ@mail.gmail.com>
Date: Thu, 26 Jun 2025 10:41:47 +0800
From: Yafang Shao <laoar.shao@...il.com>
To: Jeff Layton <jlayton@...nel.org>
Cc: Christoph Hellwig <hch@...radead.org>, 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 10:06 PM Jeff Layton <jlayton@...nel.org> wrote:
>
> On Wed, 2025-06-25 at 04:56 -0700, Christoph Hellwig wrote:
> > On Wed, Jun 25, 2025 at 07:49:31AM -0400, Jeff Layton wrote:
> > > 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.

As you mentioned earlier, calling fsync()/fdatasync() after every
write() blocks the thread, degrading performance—especially on HDDs.
However, this isn’t the main issue in practice.
The real problem is that users typically don’t understand "writeback
errors". If you warn them, "You should call fsync() because writeback
errors might occur," their response will likely be: "What the hell is
a writeback error?"

For example, our users (a big data platform) demanded that we
immediately shut down the filesystem upon writeback errors. These
users are algorithm analysts who write Python/Java UDFs for custom
logic—often involving temporary disk writes followed by reads to pass
data downstream. Yet, most have no idea how these underlying processes
work.

> >
> > That's what I mean with my above proposal, except that I though of an
> > fcntl or syscall and not an ioctl.
>
> Yeah, a fcntl() would be reasonable, I think.
>
> For a syscall, I guess we could add an fsync2() which just adds a flags
> field. Then add a FSYNC_JUSTCHECK flag that makes it just check for
> errors and return.
>
> Personally, I like the fcntl() idea better for this, but maybe we have
> other uses for a fsync2().

What do you expect users to do with this new fcntl() or fsync2()? Call
fsync2() after every write()? That would still require massive
application refactoring.

Writeback errors are fundamentally bugs in the filesystem/block
layer/driver stack. It makes no sense to expose kernel implementation
flaws to userspace, forcing developers to compensate for kernel-level
issues with additional syscalls.

Most users neither have the patience nor should they need to
understand the deepest intricacies of Linux kernel internals. The
proper fix should happen in the kernel—not by pushing workarounds onto
applications.

-- 
Regards
Yafang