dmu_buf_will_clone: change assertion to fix 32-bit compiler warning

[DimitryAndric]

Building module/zfs/dbuf.c for 32-bit targets can result in a warning:

In file included from /workspace/src/sys/contrib/openzfs/include/sys/zfs_context.h:97,
                 from /workspace/src/sys/contrib/openzfs/module/zfs/dbuf.c:32:
/workspace/src/sys/contrib/openzfs/module/zfs/dbuf.c: In function 'dmu_buf_will_clone':
/workspace/src/sys/contrib/openzfs/lib/libspl/include/assert.h:116:33: error: cast from pointer to integer of different size [-Werror=pointer-to-int-cast]
  116 |         const uint64_t __left = (uint64_t)(LEFT);                       \
      |                                 ^
/workspace/src/sys/contrib/openzfs/lib/libspl/include/assert.h:148:25: note: in expansion of macro 'VERIFY0'
  148 | #define ASSERT0         VERIFY0
      |                         ^~~~~~~
/workspace/src/sys/contrib/openzfs/module/zfs/dbuf.c:2704:9: note: in expansion of macro 'ASSERT0'
 2704 |         ASSERT0(dbuf_find_dirty_eq(db, tx->tx_txg));
      |         ^~~~~~~

This is because dbuf_find_dirty_eq() returns a pointer, which if pointers are 32-bit results in a warning about the cast to uint64_t.

Instead, use the regular ASSERT() macro, and compare the return value with NULL, which should work regardless of the target's bitness.

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.

[amotin]

Actually it could be ASSERT3P(dbuf_find_dirty_eq(db, tx->tx_txg), ==, NULL); in case somebody want to see the pointer in the panic message.

[DimitryAndric]

Actually it could be ASSERT3P(dbuf_find_dirty_eq(db, tx->tx_txg), ==, NULL); in case somebody want to see the pointer in the panic message.

If that would help people when they encounter this problem, it is probably a better fix. It might save a trip into the debugger?

[amotin]

If that would help people when they encounter this problem, it is probably a better fix. It might save a trip into the debugger?

Most of our systems are normally limited to textdumps or even the panic message and a stack trace before reboot. We can not afford getting into debugger in production. So generally it is good to collect as much information in the panic messages as possible. I don't know if the pointer here gives much, if anything, but why not?

[bwatkinson]

This looks good to me, but can you update the commit message so make checkstyle passes?

[DimitryAndric]

This looks good to me, but can you update the commit message so make checkstyle passes?

Is there a convention on how to wrap compiler messages such as these? I usually don't wrap them, since they become unreadable. I can also summarize the compiler message, instead of a verbatim representation.