https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=284057
--- Comment #7 from Andriy Gapon <a...@freebsd.org> --- (In reply to Kristof Provost from comment #6) My thinking on purely defensive code is that maybe we can stash vxcr_next into a local variable, check and increment it (with the wraparound) and then update back vxcr_next, maybe using atomic compare and set. This won't eliminate the race and won't improve correctness of vmxnet3_isc_txd_credits_update result, but it should make the code even safer comparing to your proposed patch where the initial array access indexed by vxcr_next may still be out of bounds. In the crash that I reported here, vxcr_next didn't run wild, it got wrapped around. But for a moment it was equal to vxcr_ndesc and that was enough to cause the crash. Which is very rare, admittedly. -- You are receiving this mail because: You are the assignee for the bug.