From mboxrd@z Thu Jan 1 00:00:00 1970 From: Chuck Lever Subject: Re: [PATCH V1] NFS-RDMA: fix qp pointer validation checks Date: Thu, 10 Apr 2014 13:51:04 -0400 Message-ID: References: <014738b6-698e-4ea1-82f9-287378bfec19@CMEXHTCAS2.ad.emulex.com> Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: QUOTED-PRINTABLE Return-path: In-Reply-To: Sender: linux-rdma-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Devesh Sharma Cc: Linux NFS Mailing List , "linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , Trond Myklebust List-Id: linux-rdma@vger.kernel.org On Apr 10, 2014, at 1:42 PM, Devesh Sharma w= rote: >> However it seems to me the new (!ia->ri_id->qp) checks outside the c= onnect >> logic are unnecessary. >>=20 >> Clearly, as you noticed, the ib_post_{send,recv} verbs do not check = that their >> "qp" argument is NULL before dereferencing it. >>=20 >> But I don't understand how xprtrdma can post any operation if the tr= ansport >> 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= ? >>=20 >> If disconnect wipes ia->ri_id->qp while there are still operations i= n 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 yo= u missioned is really happening. I=92d like to see the crash data (back trace, etc), if you=92ve got it. -- Chuck Lever chuck[dot]lever[at]oracle[dot]com -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" i= n the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: linux-nfs-owner@vger.kernel.org Received: from userp1040.oracle.com ([156.151.31.81]:17155 "EHLO userp1040.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1758734AbaDJRvS convert rfc822-to-8bit (ORCPT ); Thu, 10 Apr 2014 13:51:18 -0400 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: [PATCH V1] NFS-RDMA: fix qp pointer validation checks From: Chuck Lever In-Reply-To: Date: Thu, 10 Apr 2014 13:51:04 -0400 Cc: Linux NFS Mailing List , "linux-rdma@vger.kernel.org" , Trond Myklebust Message-Id: References: <014738b6-698e-4ea1-82f9-287378bfec19@CMEXHTCAS2.ad.emulex.com> To: Devesh Sharma Sender: linux-nfs-owner@vger.kernel.org List-ID: On Apr 10, 2014, at 1:42 PM, Devesh Sharma 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