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
