[REGRESSION] fuse: copy_file_range() fails with EIO

["Jürg Billeter" <j@bitron.ch>]

Starting with 6.10, I'm seeing `copy_file_range()`, with source and
destination being on the same FUSE filesystem[1], failing with EIO in
some cases. The (low-level libfuse3) userspace filesystem does not
implement `copy_file_range`, so the kernel falls back to the generic
implementation. The userspace filesystem receives read requests and
replies with the `FUSE_BUF_SPLICE_MOVE` flag.

I'm not sure what exactly triggers the issue but it may depend on the
file size, among other things. I can reproduce it fairly reliably
attempting to copy files that are exactly 65536 bytes in size.

6.9 works fine but I see the issue in 6.10, 6.10.3 and also in current
master ee9a43b7cfe2.

413e8f014c8b848e4ce939156f210df59fbd1c24 is the first bad commit
commit 413e8f014c8b848e4ce939156f210df59fbd1c24 (HEAD)
Author: Matthew Wilcox (Oracle) <willy@infradead.org>
Date:   Sat Apr 20 03:50:06 2024 +0100

    fuse: Convert fuse_readpages_end() to use folio_end_read()
    
    Nobody checks the error flag on fuse folios, so stop setting it.
    Optimise the (optional) setting of the uptodate flag and clearing
    of the lock flag by using folio_end_read().
    
    Signed-off-by: Matthew Wilcox (Oracle) <willy@infradead.org>
    Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>

I've confirmed the bisection by reverting this commit on top of 6.10.3,
which resolves the issue.

#regzbot introduced: 413e8f014c8b

Cheers,
Jürg

[1] https://gitlab.com/BuildGrid/buildbox/buildbox/-/tree/master/fuse