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.

Sign up for GitHub

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

Jump to bottom

FreeBSD: Reduce copy_file_range() source lock to shared #16797

Merged
merged 1 commit into from
Nov 23, 2024
Merged

FreeBSD: Reduce copy_file_range() source lock to shared #16797

merged 1 commit into from
Nov 23, 2024

Conversation

amotin
Copy link
Member

@amotin amotin commented Nov 22, 2024

Linux locks copy_file_range() source as shared. FreeBSD was doing it also, but then was changed to exclusive, partially because KPI of that time was doing so, and partially seems out of caution. Considering zfs_clone_range() uses range locks on both source and destination, neither should require exclusive vnode locks. But one step at a time, just sync it with Linux for now.

Closes #16789

How Has This Been Tested?

Passes fsx test from #16789, even though #16796 should be the proper fix.

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:

@amotin
FreeBSD: Reduce copy_file_range() source lock to shared
ff8d703 
Linux locks copy_file_range() source as shared.  FreeBSD was doing
it also, but then was changed to exclusive, partially because KPI
of that time was doing so, and partially seems out of caution.
Considering zfs_clone_range() uses range locks on both source and
destination, neither should require exclusive vnode locks. But one
step at a time, just sync it with Linux for now.

Signed-off-by:	Alexander Motin <[email protected]>
Sponsored by:	iXsystems, Inc.
Closes	openzfs#16789
@amotin amotin mentioned this pull request Nov 22, 2024
Closed
@amotin amotin added the Status: Code Review Needed Ready for review and testing label Nov 22, 2024
asomers
asomers approved these changes Nov 22, 2024
View reviewed changes
Copy link
Contributor

@asomers asomers left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks good to me. It's what same lock type that fuse_vnop_copy_file_range, vn_generic_copy_file_range, and nfs_copy_file_range use. But was it your intention that either this PR or #16796 alone should fix the panic? Because I can still reproduce the panic with this change but without #16796.

@amotin
Copy link
Member Author

amotin commented Nov 22, 2024 •
edited
Loading

But was it your intention that either this PR or #16796 alone should fix the panic?

No, not really. I thought that shared lock recursion should be less of a problem, and IIRC it passed some tests for me, but I don't insist on it.

@behlendorf behlendorf merged commit d0a91b9 into openzfs:master Nov 23, 2024
24 checks passed
@behlendorf behlendorf added Status: Accepted Ready to integrate (reviewed, tested) and removed Status: Code Review Needed Ready for review and testing labels Nov 23, 2024
behlendorf pushed a commit to behlendorf/zfs that referenced this pull request Nov 23, 2024
@amotin @behlendorf
FreeBSD: Reduce copy_file_range() source lock to shared
2db5bbe 
Linux locks copy_file_range() source as shared.  FreeBSD was doing
it also, but then was changed to exclusive, partially because KPI
of that time was doing so, and partially seems out of caution.
Considering zfs_clone_range() uses range locks on both source and
destination, neither should require exclusive vnode locks. But one
step at a time, just sync it with Linux for now.

Reviewed-by: Alan Somers <[email protected]>
Reviewed-by: Brian Behlendorf <[email protected]>
Signed-off-by:	Alexander Motin <[email protected]>
Sponsored by:	iXsystems, Inc.
Closes openzfs#16789
Closes openzfs#16797
@amotin amotin deleted the lk_shared branch November 24, 2024 00:04
ixhamza pushed a commit to truenas/zfs that referenced this pull request Dec 2, 2024
@amotin @ixhamza
FreeBSD: Reduce copy_file_range() source lock to shared
346aa14 
Linux locks copy_file_range() source as shared.  FreeBSD was doing
it also, but then was changed to exclusive, partially because KPI
of that time was doing so, and partially seems out of caution.
Considering zfs_clone_range() uses range locks on both source and
destination, neither should require exclusive vnode locks. But one
step at a time, just sync it with Linux for now.

Reviewed-by: Alan Somers <[email protected]>
Reviewed-by: Brian Behlendorf <[email protected]>
Signed-off-by:	Alexander Motin <[email protected]>
Sponsored by:	iXsystems, Inc.
Closes openzfs#16789
Closes openzfs#16797
behlendorf pushed a commit to behlendorf/zfs that referenced this pull request Dec 3, 2024
@amotin @behlendorf
FreeBSD: Reduce copy_file_range() source lock to shared
d359f7f 
Linux locks copy_file_range() source as shared.  FreeBSD was doing
it also, but then was changed to exclusive, partially because KPI
of that time was doing so, and partially seems out of caution.
Considering zfs_clone_range() uses range locks on both source and
destination, neither should require exclusive vnode locks. But one
step at a time, just sync it with Linux for now.

Reviewed-by: Alan Somers <[email protected]>
Reviewed-by: Brian Behlendorf <[email protected]>
Signed-off-by:	Alexander Motin <[email protected]>
Sponsored by:	iXsystems, Inc.
Closes openzfs#16789
Closes openzfs#16797
rkojedzinszky pushed a commit to dravanet/openzfs-zfs that referenced this pull request Dec 16, 2024
@amotin @rkojedzinszky
FreeBSD: Reduce copy_file_range() source lock to shared
c2a788a 
Linux locks copy_file_range() source as shared.  FreeBSD was doing
it also, but then was changed to exclusive, partially because KPI
of that time was doing so, and partially seems out of caution.
Considering zfs_clone_range() uses range locks on both source and
destination, neither should require exclusive vnode locks. But one
step at a time, just sync it with Linux for now.

Reviewed-by: Alan Somers <[email protected]>
Reviewed-by: Brian Behlendorf <[email protected]>
Signed-off-by:	Alexander Motin <[email protected]>
Sponsored by:	iXsystems, Inc.
Closes openzfs#16789
Closes openzfs#16797
rkojedzinszky pushed a commit to dravanet/openzfs-zfs that referenced this pull request Dec 16, 2024
@amotin @rkojedzinszky
FreeBSD: Reduce copy_file_range() source lock to shared
9c2d933 
Linux locks copy_file_range() source as shared.  FreeBSD was doing
it also, but then was changed to exclusive, partially because KPI
of that time was doing so, and partially seems out of caution.
Considering zfs_clone_range() uses range locks on both source and
destination, neither should require exclusive vnode locks. But one
step at a time, just sync it with Linux for now.

Reviewed-by: Alan Somers <[email protected]>
Reviewed-by: Brian Behlendorf <[email protected]>
Signed-off-by:	Alexander Motin <[email protected]>
Sponsored by:	iXsystems, Inc.
Closes openzfs#16789
Closes openzfs#16797
rkojedzinszky pushed a commit to dravanet/openzfs-zfs that referenced this pull request Dec 16, 2024
@amotin @rkojedzinszky
FreeBSD: Reduce copy_file_range() source lock to shared
d4c8c8a 
Linux locks copy_file_range() source as shared.  FreeBSD was doing
it also, but then was changed to exclusive, partially because KPI
of that time was doing so, and partially seems out of caution.
Considering zfs_clone_range() uses range locks on both source and
destination, neither should require exclusive vnode locks. But one
step at a time, just sync it with Linux for now.

Reviewed-by: Alan Somers <[email protected]>
Reviewed-by: Brian Behlendorf <[email protected]>
Signed-off-by:	Alexander Motin <[email protected]>
Sponsored by:	iXsystems, Inc.
Closes openzfs#16789
Closes openzfs#16797
rkojedzinszky pushed a commit to dravanet/openzfs-zfs that referenced this pull request Dec 30, 2024
@amotin @rkojedzinszky
FreeBSD: Reduce copy_file_range() source lock to shared
28b7c7f 
Linux locks copy_file_range() source as shared.  FreeBSD was doing
it also, but then was changed to exclusive, partially because KPI
of that time was doing so, and partially seems out of caution.
Considering zfs_clone_range() uses range locks on both source and
destination, neither should require exclusive vnode locks. But one
step at a time, just sync it with Linux for now.

Reviewed-by: Alan Somers <[email protected]>
Reviewed-by: Brian Behlendorf <[email protected]>
Signed-off-by:	Alexander Motin <[email protected]>
Sponsored by:	iXsystems, Inc.
Closes openzfs#16789
Closes openzfs#16797
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@behlendorf behlendorf behlendorf approved these changes

@asomers asomers asomers approved these changes

Assignees
No one assigned
Labels
Status: Accepted Ready to integrate (reviewed, tested)
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.

panic: excl->share in zfs_clone_range when block_cloning is enabled
3 participants
@amotin @asomers @behlendorf