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

BRT: Check bv_mos_entries in brt_entry_lookup() #16851

Merged
merged 1 commit into from
Dec 12, 2024
Merged

BRT: Check bv_mos_entries in brt_entry_lookup() #16851

merged 1 commit into from
Dec 12, 2024

Conversation

amotin
Copy link
Member

@amotin amotin commented Dec 9, 2024 •
edited
Loading

When vdev first sees some block cloning, there is a window when brt_maybe_exists() might already return true since something was cloned, but bv_mos_entries is still 0 since BRT ZAP was not yet created. In such case we should not try to look into the ZAP and dereference NULL bv_mos_entries_dnode.

How Has This Been Tested?

The issue was reported here: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=283218 . The fix was confirmed there too.

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
BRT: Check bv_mos_entries in brt_entry_lookup()
376958c 
When vdev first sees some block cloning, there is a window when
brt_maybe_exists() might already return true since something was
cloned, but bv_mos_entries is still 0 since BRT ZAP was not yet
created.  In such case we should not try to look into the ZAP
and dereference NULL bv_mos_entries_dnode.

Signed-off-by:	Alexander Motin <mav@FreeBSD.org>
Sponsored by:	iXsystems, Inc.
@amotin amotin added the Status: Code Review Needed Ready for review and testing label Dec 9, 2024
@amotin amotin requested a review from behlendorf December 10, 2024 14:25
robn
robn approved these changes Dec 11, 2024
View reviewed changes
Copy link
Member

@robn robn 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 right. Good find.

@behlendorf behlendorf added Status: Accepted Ready to integrate (reviewed, tested) and removed Status: Code Review Needed Ready for review and testing labels Dec 12, 2024
@behlendorf behlendorf merged commit 19a04e5 into openzfs:master Dec 12, 2024
24 checks passed
@amotin amotin deleted the mos_entries branch December 12, 2024 18:31
behlendorf pushed a commit to behlendorf/zfs that referenced this pull request Dec 13, 2024
@amotin @behlendorf
BRT: Check bv_mos_entries in brt_entry_lookup()
3887591 
When vdev first sees some block cloning, there is a window when
brt_maybe_exists() might already return true since something was
cloned, but bv_mos_entries is still 0 since BRT ZAP was not yet
created.  In such case we should not try to look into the ZAP
and dereference NULL bv_mos_entries_dnode.

Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Reviewed-by: Rob Norris <robn@despairlabs.com>
Signed-off-by:	Alexander Motin <mav@FreeBSD.org>
Sponsored by:	iXsystems, Inc.
Closes openzfs#16851
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

@robn robn robn 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.
3 participants
@amotin @robn @behlendorf