More aggressively assert that db_mtx protects db.db_data

[asomers]

db.db_mtx must be held any time that db.db_data is accessed. All of these functions do have the lock held by a parent; add assertions to ensure that it stays that way.

Also, refactor dbuf_read_bonus to make it obvious why db_rwlock isn't required.

See #17118

Sponsored by: ConnectWise
Signed-off-by: Alan Somers [email protected]

Motivation and Context

Bug #16626 probably results from improper locking around db.db_data. Any time that variable is accessed, db_mtx must be held.

Description

As a first step to fixing that bug, add some more assertions in places that already do have the lock, but don't currently assert that they do. This will make the problem more clear, and prevent regressions in those functions.

How Has This Been Tested?

I ran the ZFS test suite in FreeBSD 15.0-CURRENT.

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.

[asomers]

@pcd1193182 could you review, please?

[snajpa]

From one of the test runs:

   [ 3615.299691] VERIFY(MUTEX_HELD(&db->db_mtx)) failed
  [ 3615.300875] PANIC at dmu.c:1730:dmu_object_cached_size()

it would seem that dmu_object_cached_size is called without db_mtx

[asomers]

it would seem that dmu_object_cached_size is called without db_mtx

It looks like that's a Linux-only panic, which is why I didn't see it . I'll investigate.