CSan race in cpu_count_sync() coming from ZFS

Kernel compiled with KCSAN (and clang) reports two different potential
concurrency issues on NetBSD 10. One of them is in cpu_count_sync()
function and can be trivally fixed with a spinlock around memcpy but
that function has a comment that says:

   It's tempting to use a spin mutex here but this routine is called from DDB.


I wonder if ZFS should be fixed instead to avoid calling cpu_count_sync() from
two different threads at the same time?

CSan: Racy Access [Cpu5 Write Addr=0xffffffff81726fc0 Size=384 PC=0xffffffff80d6d0a6<cpu_count_sync>] [Cpu10 Write Addr=0xffffffff81726fc0 Size=384 PC=0xffffffff80d6d0a6<cpu_count_sync>]
#0 0xffffffff80d6e68f in kcsan_memcpy <netbsd>
#1 0xffffffff80d6d0a6 in cpu_count_sync <netbsd>
#2 0xffffffff80d09b39 in uvm_availmem <netbsd>
#3 0xffffffff8256c969 in arc_available_memory <zfs>
#4 0xffffffff8256dc3e in arc_get_data_buf.constprop.0 <zfs>
#5 0xffffffff8256e0a1 in arc_hdr_alloc_pdata <zfs>
#6 0xffffffff8256eda9 in arc_write_ready <zfs>
#7 0xffffffff826131e2 in zio_ready <zfs>
#8 0xffffffff826120fa in zio_execute <zfs>
#9 0xffffffff82698bce in task_executor <solaris>
#10 0xffffffff80d5de14 in threadpool_thread <netbsd>
#11 0xffffffff8020b707 in lwp_trampoline <netbsd>

--
Alex