[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150615172210.GB14982@obsidianresearch.com>
Date: Mon, 15 Jun 2015 11:22:10 -0600
From: Jason Gunthorpe <jgunthorpe@...idianresearch.com>
To: Haggai Eran <haggaie@...lanox.com>
Cc: Doug Ledford <dledford@...hat.com>, linux-rdma@...r.kernel.org,
netdev@...r.kernel.org, Liran Liss <liranl@...lanox.com>,
Guy Shapiro <guysh@...lanox.com>,
Shachar Raindel <raindel@...lanox.com>,
Yotam Kenneth <yotamke@...lanox.com>
Subject: Re: [PATCH 02/11] IB/ipoib: Return IPoIB devices matching connection
parameters
On Mon, Jun 15, 2015 at 11:47:07AM +0300, Haggai Eran wrote:
> +/* Called with an RCU read lock taken */
Add _rcu to the name? That is the standard convention.
> +/* returns an IPoIB netdev on top a given ipoib device matching a pkey_index
> + * and address, if one exists. */
> +static struct net_device *ipoib_match_gid_pkey_addr(struct ipoib_dev_priv *priv,
> + const union ib_gid *gid,
> + u16 pkey_index,
> + const struct sockaddr *addr)
> +{
> + struct ipoib_dev_priv *child_priv;
> + struct net_device *net_dev = NULL;
> +
> + if (priv->pkey_index == pkey_index &&
> + (!gid || !memcmp(gid, &priv->local_gid, sizeof(*gid)))) {
> + net_dev = ipoib_get_net_dev_match_addr(addr, priv->dev);
> + if (net_dev)
> + return net_dev;
As I said already, this should not even look at the sockaddr unless
there are multiple possible hits on the other parameters, and there
should be a comment explaining the sockaddr is only a hack to make up
for having an incomplete LLADDR.
That way people not using same guid children do not get incorrect
functionality..
> +static struct net_device *ipoib_get_net_dev_by_params(
> + struct ib_device *dev, u8 port, u16 pkey,
> + const union ib_gid *gid, const struct sockaddr *addr)
[..]
> + ret = ib_find_cached_pkey(dev, port, pkey, &pkey_index);
> + if (ret)
> + return NULL;
> +
> + if (!rdma_protocol_ib(dev, port))
> + return NULL;
This if should be first I'd think.
> + dev_list = ib_get_client_data(dev, &ipoib_client);
> + if (!dev_list)
> + return NULL;
Is the locking OK here? This access protected by lists_rwsem -
but for instance ib_unregister_device holds only the device_mutex when
calling client->remove, which kfree's dev_list. Looks wrong to me.
Jason
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists