nvmf/rdma host crash during heavy load and keep alive recovery

[swise@opengridcomputing.com (Steve Wise)]

> > Hey Sagi,
> >
> > Do you have any ideas on this crash? I could really use some help.
> 
> Not yet :(
> 
> > Is it
> > possible that recovery/reconnect/restart of a different controller is
somehow
> > restarting the requests for a controller still in recovery?
> 
> I don't think this is the case.
> Can you try and find out if the request is from the admin tagset or from
> the io tagset?

I wasn't sure how to tell easily which tagset the request was in, so instead I
changed nvme_rdma_admin_mq_ops.queue_rq to its own distinct function,
nvme_rdma_queue_admin_rq() which was a clone of nvme_rdma_queue_rq().  Thus when
it crashed, I could tell by the stack trace.  Anyway, the stack trace indicates
it was from the io tagset.

> 
> We rely on the fact that no I/O will be issued after we call
> nvme_stop_queues(). can you trace that we indeed call nvme_stop_queues
> when we start error recovery and do nvme_start_queues only when we
> successfully reconnect and not anywhere in between?
> 

I see from debugging that the nvme_ns->queue address of the queue being used
that causes the crash was stopped via nvme_stop_queues().  It was never started
via nvme_start_queues().

> If that is the case, I think we need to have a closer look at
> nvme_stop_queues...
> 

request_queue->queue_flags does have QUEUE_FLAG_STOPPED set:

#define QUEUE_FLAG_STOPPED      2       /* queue is stopped */

crash> request_queue.queue_flags -x 0xffff880397a13d28
  queue_flags = 0x1f07a04
crash> request_queue.mq_ops 0xffff880397a13d28
  mq_ops = 0xffffffffa084b140 <nvme_rdma_mq_ops>

So it appears the queue is stopped, yet a request is being processed for that
queue.  Perhaps there is a race where QUEUE_FLAG_STOPPED is set after a request
is scheduled?