On Apr 10, 2014, at 1:42 PM, Devesh Sharma <Devesh.Sharma@xxxxxxxxxx> wrote:
>> However it seems to me the new (!ia->ri_id->qp) checks outside the connect
>> logic are unnecessary.
>>
>> Clearly, as you noticed, the ib_post_{send,recv} verbs do not check that their
>> "qp" argument is NULL before dereferencing it.
>>
>> But I don't understand how xprtrdma can post any operation if the transport
>> isn't connected. In other words, how would it be possible to call
>> rpcrdma_ep_post_recv() if the connect had failed and there was no QP?
>>
>> If disconnect wipes ia->ri_id->qp while there are still operations in progress,
>> that would be the real bug.
> Yes!, But I have seen one more kernel oops where QP is destroyed and xprtrdma still try to post in LOCAL_INV
> WR on a NULL QP pointer and hence system crashes. So, I think what you missioned is really happening.
I’d like to see the crash data (back trace, etc), if you’ve got it.
--
Chuck Lever
chuck[dot]lever[at]oracle[dot]com
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
