e1dd85a5b7
When a connection goes to close and has no I/O outstanding, the current_recv_depth was being decremented beyond 0 and rolling over. If the poll group then finds a successful receive completion on the next poll (for a command that arrived prior to starting the disconnect but hadn't been processed yet), it would trip the max queue depth check added recently and start another disconnect process. If only one command arrives in this window, everything actually works out ok. However, if there are two receive completions sitting in the completion queue after the disconnect process is started, the first one does the double disconnect and the second one does another disconnect which ends up dereferencing a null pointer. Since there is always a special reserved slot for the dummy recv, don't do decrements or increments of the current_recv_depth for the dummy recv. This allows the code to still enforce the actual max_queue_depth on recvs without underflowing or overflowing the counter. Change-Id: I56c95b2424e956a3b007b25c50cbf47262245b8f Signed-off-by: Ben Walker <benjamin.walker@intel.com> Reviewed-on: https://review.gerrithub.io/c/442642 Tested-by: SPDK CI Jenkins <sys_sgci@intel.com> Reviewed-by: Seth Howell <seth.howell5141@gmail.com> Reviewed-by: Jim Harris <james.r.harris@intel.com> |
||
|---|---|---|
| .. | ||
| ctrlr_bdev.c | ||
| ctrlr_discovery.c | ||
| ctrlr.c | ||
| Makefile | ||
| nvmf_fc.h | ||
| nvmf_internal.h | ||
| nvmf.c | ||
| rdma.c | ||
| request.c | ||
| subsystem.c | ||
| tcp.c | ||
| transport.c | ||
| transport.h | ||