Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755617AbbDNP7A (ORCPT ); Tue, 14 Apr 2015 11:59:00 -0400 Received: from mail-wi0-f170.google.com ([209.85.212.170]:36063 "EHLO mail-wi0-f170.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751770AbbDNP6w (ORCPT ); Tue, 14 Apr 2015 11:58:52 -0400 Message-ID: <552D3939.6010802@profitbricks.com> Date: Tue, 14 Apr 2015 17:58:49 +0200 From: Michael Wang User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: "ira.weiny" CC: "Hefty, Sean" , Roland Dreier , Hal Rosenstock , "linux-rdma@vger.kernel.org" , "linux-kernel@vger.kernel.org" , Tom Tucker , Steve Wise , Hoang-Nam Nguyen , Christoph Raisch , infinipath , Eli Cohen , "Latif, Faisal" , Jack Morgenstein , Or Gerlitz , Haggai Eran , Tom Talpey , Jason Gunthorpe , Doug Ledford Subject: Re: [PATCH v3 10/28] IB/Verbs: Reform cm related part in IB-core cma References: <552BB470.4090407@profitbricks.com> <552BB60F.60109@profitbricks.com> <1828884A29C6694DAF28B7E6B8A82373A8FC0ACF@ORSMSX109.amr.corp.intel.com> <552CD156.9060709@profitbricks.com> <20150414155033.GB13852@phlsvsds.ph.intel.com> In-Reply-To: <20150414155033.GB13852@phlsvsds.ph.intel.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1824 Lines: 51 On 04/14/2015 05:50 PM, ira.weiny wrote: > On Tue, Apr 14, 2015 at 10:35:34AM +0200, Michael Wang wrote: >> >> >> On 04/13/2015 09:25 PM, Hefty, Sean wrote: >>>> @@ -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.) >> >> Agree, seems like this is very similar to the case of cma_listen_on_dev() which >> do not associated with any particular port in #24. >> >> If the port 1 is enough to present the whole device's cm capability, maybe we can >> get rid of cap_ib_cm_dev() too? >> >> And maybe cap_ib_cm(device, device->node_type == RDMA_NODE_IB_SWITCH ? 0:1) would >> be safer? > > I don't see support for switch port 0 in cm_add_one() now. Are switches supposed > to be supported? Just concern about the validation of port... is it possible that the device we check in here don't have port 1? (forgive me if the question is too silly :-P) Regards, Michael Wang > > Ira > >> >> Regards, >> Michael Wang >> -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/