Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Linux 6.8 compat: use splice_copy_file_range() for fallback #15931

Merged
merged 1 commit into from
Mar 20, 2024

Conversation

robn
Copy link
Member

@robn robn commented Feb 24, 2024

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:

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.

Signed-off-by: Rob Norris <robn@despairlabs.com>
Sponsored-by: https://despairlabs.com/sponsor/
@satmandu
Copy link
Contributor

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
Copy link
Member Author

robn commented Feb 26, 2024

@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.

@behlendorf behlendorf added the Status: Accepted Ready to integrate (reviewed, tested) label Feb 27, 2024
@darkbasic
Copy link

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:
Screenshot from 2024-03-11 21-41-23

@bjin
Copy link

bjin commented Mar 12, 2024

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
Copy link
Member Author

robn commented Mar 12, 2024

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

@darkbasic
Copy link

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
Copy link

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
Copy link
Member Author

robn commented Mar 12, 2024

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
Copy link

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

archlinux-github pushed a commit to archlinux/aur that referenced this pull request Mar 20, 2024
@behlendorf behlendorf merged commit ef08a4d into openzfs:master Mar 20, 2024
22 of 26 checks passed
robn added a commit to robn/zfs that referenced this pull request Mar 21, 2024
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.

Sponsored-by: https://despairlabs.com/sponsor/
Reviewed-by: Tony Hutter <hutter2@llnl.gov>
Reviewed by: Brian Behlendorf <behlendorf1@llnl.gov>
Signed-off-by: Rob Norris <robn@despairlabs.com>
Closes openzfs#15930
Closes openzfs#15931
(cherry picked from commit ef08a4d)
behlendorf pushed a commit that referenced this pull request Mar 21, 2024
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.

Sponsored-by: https://despairlabs.com/sponsor/
Reviewed-by: Tony Hutter <hutter2@llnl.gov>
Reviewed by: Brian Behlendorf <behlendorf1@llnl.gov>
Signed-off-by: Rob Norris <robn@despairlabs.com>
Closes #15930
Closes #15931
(cherry picked from commit ef08a4d)
@robn robn mentioned this pull request Mar 27, 2024
13 tasks
stgraber pushed a commit to zabbly/zfs that referenced this pull request Mar 28, 2024
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.

Sponsored-by: https://despairlabs.com/sponsor/
Reviewed-by: Tony Hutter <hutter2@llnl.gov>
Reviewed by: Brian Behlendorf <behlendorf1@llnl.gov>
Signed-off-by: Rob Norris <robn@despairlabs.com>
Closes openzfs#15930
Closes openzfs#15931
(cherry picked from commit ef08a4d)
stgraber pushed a commit to zabbly/zfs that referenced this pull request May 1, 2024
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.

Sponsored-by: https://despairlabs.com/sponsor/
Reviewed-by: Tony Hutter <hutter2@llnl.gov>
Reviewed by: Brian Behlendorf <behlendorf1@llnl.gov>
Signed-off-by: Rob Norris <robn@despairlabs.com>
Closes openzfs#15930
Closes openzfs#15931
(cherry picked from commit ef08a4d)
lundman pushed a commit to openzfsonwindows/openzfs that referenced this pull request Sep 4, 2024
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.

Sponsored-by: https://despairlabs.com/sponsor/
Reviewed-by: Tony Hutter <hutter2@llnl.gov>
Reviewed by: Brian Behlendorf <behlendorf1@llnl.gov>
Signed-off-by: Rob Norris <robn@despairlabs.com>
Closes openzfs#15930 
Closes openzfs#15931
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Status: Accepted Ready to integrate (reviewed, tested)
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Possible copy_file_range issue with OpenZFS 2.2.3 and Kernel 6.8-rc5
6 participants