Linux 6.8 compat: use splice_copy_file_range() for fallback

[robn]

Motivation and Context

Closes #15930.

Description

Linux 6.8 removes generic_copy_file_range(), which had been reduced to a simple wrapper around splice_copy_file_range(). Detect that function directly and use it if generic_ is not available.

How Has This Been Tested?

Run block_cloning tests against kernels: 6.8.0-rc3 6.7.1 6.6.15 6.4.15 5.10.170 4.9.337.

6.8.0-rc3 fails without this patch, succeeds with. All others succeed without and with.

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Performance enhancement (non-breaking change which improves efficiency)
• Code cleanup (non-breaking change which makes code smaller or more readable)
• Breaking change (fix or feature that would cause existing functionality to change)
• Library ABI change (libzfs, libzfs_core, libnvpair, libuutil and libzfsbootenv)
• Documentation (a change to man pages or other documentation)

Checklist:

• My code follows the OpenZFS code style requirements.
• I have updated the documentation accordingly.
• I have read the contributing document.
• I have added tests to cover my changes.
• I have run the ZFS Test Suite with this change applied.
• All commit messages are properly formatted and contain Signed-off-by.

[satmandu]

I take it we will have to wait for this to be backported to a 2.2.x point release for this to be officially released (or get distributions to get this added as an additional patch until that happens?)

(It's working fine with my ppa, and on two local 6.8-rc6 systems that I have running.)

[robn]

@satmandu yep, once its landed I'll prepare the backport for 2.2.4. There's no particular urgency from the OpenZFS side, as 6.8 is not yet an officially-supported kernel.

[darkbasic]

There's no particular urgency

I don't agree, this leads to corruption on 6.8. Even if 6.8 is not officially supported this PR fixes the issue and should be merged ASAP. Had to reinstall a Steam game because it got corrupted, I've been lucky that I wanted to do some benchmarks and I've noticed the issue with non-valuable data:

[bjin]

Just a friendly reminder, Linux 6.8 has been released

There's no particular urgency from the OpenZFS side, as 6.8 is not yet an officially-supported kernel.

[robn]

I meant, there is no particular urgency on the OpenZFS side - we currently only support up to 6.7 in official releases.

[darkbasic]

Yes but compat patches already landed in stable releases and people are starting to use it with the recently released 6.8. Since this issue leads to data loss this is a potential bomb. I've already added a warning in the AUR and Gentoo is next.
This is the third issue leading to data loss that I experience since the release of 2.2. While I purposefully test bleeding edge features to help iron bugs out (and luckily I caught a similar zvol issue just days before the 2.2.0 release) most users don't care and I'm already starting to see a shift in the public opinion after the recent reflink issues.
IMO this must be somehow dealt with. What I can do is talk to rolling release distribution maintainers and try to add a warning in post-install/dkms scripts. On the other hand I think that upstream should prioritize reviewing and merging this PR, so that distributions can feel better about backporting the patch if they decide to do so instead of adding a warning.

[darkbasic]

By the way while I can't review the patch I've already backported it in my own branch on tested it: it fixed the issue for me.

[robn]

I don't disagree in principle, but there's limits to what the OpenZFS project itself can provide, which is why there's an upper bound on the supported versions. If distribution or an individual decides to try and use OpenZFS in an unsupported configuration and it blows up, that sucks, but that's the warranty. Still, I've just posted #15986, which might at least make it clearer that you're entering the danger zone.

Anyway, this patch is reviewed and approved; its just waiting to be merged. Nothing else to see.

[darkbasic]

I think that #15986 is indeed the best solution to this issue.