I'm not familiar with IFLIB. From the driver code it looks only this function vmxnet3_isc_txd_credits_update() can increase txc->vxcr_next. So if ++txc->vxcr_next > txc->vxcr_ndesc happens then I guess the function vmxnet3_isc_txd_credits_update() is called by multiple threads concurrently. If that is the desired behavior we probably want atomic increasing of txc->vxcr_next.

The idx is on local stack, so if ++idx > rxc->vxcr_ndesc happens, it actually hints that the passed in idx is wrong, since &rxc->vxcr_u.rxcd[idx] would lead to OOB access.

Hence I'd prefer a KASSERT or panic right before the for loop, rather than *HIDING* the real problem and let driver code just WORK.

KASSERT(idx < rxc->vxcr_ndesc);

That's my understanding as well, yes.

I am insufficiently familiar with this driver to do more than fix the immediate problem. I'm hoping that the maintainers and/or original authors will look at fixing the fundamental problem.

In the mean time this workaround should stop the panics we see.

We could do both while we wait for those familiar with this code to fix it fully.

That would mean that non-debug kernel will work, and debug kernels will assert and demonstrate the problem.

Although that's really only for the ++txc->vxcr_next >= txc->vxcr_ndesc case, because it's indeed a local variable here and there's no way for that to race.

Dereferencing txcd may result in crash if vxcr_next happens to be >= txc->vxcr_ndesc at this point of execution because of the same race.