lib: fix uninitialized value created by stack allocation

[martin-gpy]

Valgrind complained of an uninitialized value created by stack allocation warning while running nvme discover:

==8257== Syscall param ioctl(generic) points to uninitialised byte(s)
==8257== at 0x49E582B: ioctl (in /lib64/libc.so.6)
==8257== by 0x4876C96: __nvme_transport_handle_open_direct (lib.c:192)
==8257== by 0x4876C96: libnvme_open (lib.c:258)
==8257== by 0x488579A: nvmf_create_discovery_ctrl (fabrics.c:2257)
==8257== by 0x4888372: libnvmf_discovery (fabrics.c:3108)
==8257== by 0x456FCE: fabrics_discovery (fabrics.c:675)
==8257== by 0x4451A8: handle_plugin (plugin.c:190)
==8257== by 0x407F40: main (nvme.c:11330)
==8257== Address 0x1ffeffeef4 is on thread 1's stack
==8257== in frame #1, created by libnvme_open (lib.c:230)
==8257== Uninitialised value was created by a stack allocation
==8257== at 0x48769E0: libnvme_open (lib.c:230)

Fix the same.

[igaw]

That approach is really just papering over the underlying problem. The namespace won’t have a valid ID, so ioctl probing ends up triggering a kernel warning. What we actually need is smarter probing logic. Potentially by issuing a proper NVMe command instead.

For the admin queue, using Identify Controller Data Structure (CNS 01h) should be reliable across all transports and command sets.

The I/O path is trickier. Flush looks like the only reasonable option, but it requires an nsid. While nsid=0xffffffff could be used, support isn’t mandatory, and even if it is supported, it affects all namespaces. So it’s not a great fit.

A better approach might be to avoid probing altogether. Try the 64-bit ioctl first, and if that fails, fall back to the 32-bit version. This would also reduce overhead on systems that already support 64-bit ioctls.