Fix panic in iflib when out of mbuf clusters

[• hselasky]

Summary

Fix panic in iflib when out of mbuf clusters by not flushing the RX descriptor in that case.

Backtrace:
panic: Assertion *sd->ifsd_cl != NULL failed at /usr/src/sys/net/iflib.c:2632
iflib_rxeof()
_task_fn_rx()
gtaskqueue_run_locked()
gtaskqueue_thread_loop()
fork_exit()

Sponsored by: Mellanox Technologies

Test Plan

Inserted probe in code to force error path.

[gallatin]

Picture a case where you're asked to refill 128 slots, and fail after 127. Don't you want to at least flush the 127 that you were able to allocate?

Eg, do the work currently at the bottom of the loop in the (n == 0 || i == IFLIB_MAX_RX_REFRESH) when you've managed any allocations at all.

[• hselasky]

For a reason I don't fully understand, if we do exactly that, we end up with a panic in rxeof, because the cluster pointer is NULL. I suspect something goes wrong with the ifl_pidx logic.

[• hselasky]

sys/net/iflib.c

2600

This is the assertion we hit! Can you explain why?

[gallatin]

sys/net/iflib.c

2600

I wonder if it is a bug in the lower-level driver, and it is giving the hardware ring entries beyond pidx? Aside from that, I don't know.

[• hselasky]

This happens when we only feed one and one mbuf cluster. It can easily be reproduced! What happens if pidx wraps too fast?

[• hselasky]

Superceeded by D25489 .