Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 14 Jan 2025 11:06:12 +0000
From:      bugzilla-noreply@freebsd.org
To:        net@FreeBSD.org
Subject:   [Bug 284057] vmxnet3/iflib: crash in vmxnet3_isc_txd_credits_update
Message-ID:  <bug-284057-7501-mbsj7oAmIS@https.bugs.freebsd.org/bugzilla/>
In-Reply-To: <bug-284057-7501@https.bugs.freebsd.org/bugzilla/>
References:  <bug-284057-7501@https.bugs.freebsd.org/bugzilla/>

next in thread | previous in thread | raw e-mail | index | archive | help

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=284057

--- Comment #7 from Andriy Gapon <avg@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.


Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-284057-7501-mbsj7oAmIS>