Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S932685AbbDMT1T (ORCPT <rfc822;w@1wt.eu>);
	Mon, 13 Apr 2015 15:27:19 -0400
Received: from mga03.intel.com ([134.134.136.65]:49022 "EHLO mga03.intel.com"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S1751809AbbDMTZ6 (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Mon, 13 Apr 2015 15:25:58 -0400
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.11,571,1422950400"; 
   d="scan'208";a="694657092"
From: "Hefty, Sean" <sean.hefty@intel.com>
To: Michael Wang <yun.wang@profitbricks.com>,
        Roland Dreier <roland@kernel.org>,
        Hal Rosenstock <hal.rosenstock@gmail.com>,
        "linux-rdma@vger.kernel.org" <linux-rdma@vger.kernel.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
CC: Tom Tucker <tom@opengridcomputing.com>,
        Steve Wise <swise@opengridcomputing.com>,
        Hoang-Nam Nguyen <hnguyen@de.ibm.com>,
        Christoph Raisch <raisch@de.ibm.com>,
        infinipath <infinipath@intel.com>, Eli Cohen <eli@mellanox.com>,
        "Latif, Faisal" <faisal.latif@intel.com>,
        Jack Morgenstein <jackm@dev.mellanox.co.il>,
        Or Gerlitz <ogerlitz@mellanox.com>, Haggai Eran <haggaie@mellanox.com>,
        "Weiny, Ira" <ira.weiny@intel.com>, Tom Talpey <tom@talpey.com>,
        Jason Gunthorpe <jgunthorpe@obsidianresearch.com>,
        Doug Ledford <dledford@redhat.com>
Subject: RE: [PATCH v3 10/28] IB/Verbs: Reform cm related part in IB-core cma
Thread-Topic: [PATCH v3 10/28] IB/Verbs: Reform cm related part in IB-core
 cma
Thread-Index: AQHQdeUuGutiT7s6bE23niQY7GYk/51LT6Eg
Date: Mon, 13 Apr 2015 19:25:48 +0000
Message-ID: <1828884A29C6694DAF28B7E6B8A82373A8FC0ACF@ORSMSX109.amr.corp.intel.com>
References: <552BB470.4090407@profitbricks.com>
 <552BB60F.60109@profitbricks.com>
In-Reply-To: <552BB60F.60109@profitbricks.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.22.254.139]
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from base64 to 8bit by nfs id t3DJRMil006096
Content-Length: 1329
Lines: 31

> @@ -1037,17 +1033,13 @@ void rdma_destroy_id(struct rdma_cm_id *id)
>  	mutex_unlock(&id_priv->handler_mutex);
> 
>  	if (id_priv->cma_dev) {
> -		switch (rdma_node_get_transport(id_priv->id.device-
> >node_type)) {
> -		case RDMA_TRANSPORT_IB:
> +		if (rdma_ib_or_iboe(id_priv->id.device, id_priv->id.port_num))

A listen id can be associated with a device without being associated with a port (see the listen_any_list).  Some other check is needed to handle this case.  I guess the code could check the first port on the device (replace port_num with hardcoded value 1).  Then we wouldn't be any more broken than the code already is.  (The 'break' is conceptual, not practical.)

This appears to be highlighting an architectural flaw in the iboe integration.

> {
>  			if (id_priv->cm_id.ib)
>  				ib_destroy_cm_id(id_priv->cm_id.ib);
> -			break;
> -		case RDMA_TRANSPORT_IWARP:
> +		} else if (rdma_tech_iwarp(id_priv->id.device,
> +					   id_priv->id.port_num)) {
>  			if (id_priv->cm_id.iw)
>  				iw_destroy_cm_id(id_priv->cm_id.iw);
> -			break;
> -		default:
> -			break;
>  		}
>  		cma_leave_mc_groups(id_priv);
>  		cma_release_dev(id_priv);

 - Sean
????{.n?+???????+%?????ݶ??w??{.n?+????{??G?????{ay?ʇڙ?,j??f???h?????????z_??(?階?ݢj"???m??????G????????????&???~???iO???z??v?^?m????????????I?