bhyve: block_if: do not compare pthread objects with NULL

[wanpengqian_gmail.com]

Summary

blockif_open()'s error path decides what to destroy by comparing the
mutex and the condition variables with NULL. That relies on
pthread_mutex_t and pthread_cond_t being pointers, as they are in
FreeBSD's libthr (the context is calloc'ed, so the test works there),
but it does not compile where they are structures. Record which objects
were initialized instead; the behaviour on FreeBSD does not change.

The comparisons came in with the leak fixes of 0228338fc9c6 (D57887,
July 2026), which was merged to stable/15 as 429e2c587b3a.

Fixes: 0228338fc9c6 ("bhyve: Fix some leaks in usr.sbin/bhyve/block_if.c")
Signed-off-by: Wanpeng Qian <[e-mail]>
Sponsored by: keelos.dev

Test Plan

Built usr.sbin/bhyve on main 7cb4d4dfd with and without the change, plain
and WITH_BHYVE_SNAPSHOT, -Werror: 0 warnings.

On FreeBSD pthread_mutex_t and pthread_cond_t are pointers, so the old
NULL comparisons compile and happen to work (the softc is calloc'ed, and an
uninitialized object is a NULL pointer). The change keeps the same
behaviour with explicit flags; it is needed where these types are
structures (found while porting bhyve to macOS's Hypervisor.framework,
where the old code does not compile).

Regression in a nested FreeBSD main guest (bhyveload, -s 2,ahci-hd and
-s 4,virtio-blk): boots, 256 MB written to vtbd0 and read back with the
same MD5. The error path itself needs a failing pthread_*_init() and was
not exercised.