2005-04-17 00:20:36 +02:00
|
|
|
/*
|
|
|
|
|
* Copyright (c) 2004, 2005 Topspin Communications. All rights reserved.
|
2005-08-11 08:03:10 +02:00
|
|
|
* Copyright (c) 2005 Sun Microsystems, Inc. All rights reserved.
|
|
|
|
|
* Copyright (c) 2004 Voltaire, Inc. All rights reserved.
|
2005-04-17 00:20:36 +02:00
|
|
|
*
|
|
|
|
|
* This software is available to you under a choice of one of two
|
|
|
|
|
* licenses. You may choose to be licensed under the terms of the GNU
|
|
|
|
|
* General Public License (GPL) Version 2, available from the file
|
|
|
|
|
* COPYING in the main directory of this source tree, or the
|
|
|
|
|
* OpenIB.org BSD license below:
|
|
|
|
|
*
|
|
|
|
|
* Redistribution and use in source and binary forms, with or
|
|
|
|
|
* without modification, are permitted provided that the following
|
|
|
|
|
* conditions are met:
|
|
|
|
|
*
|
|
|
|
|
* - Redistributions of source code must retain the above
|
|
|
|
|
* copyright notice, this list of conditions and the following
|
|
|
|
|
* disclaimer.
|
|
|
|
|
*
|
|
|
|
|
* - Redistributions in binary form must reproduce the above
|
|
|
|
|
* copyright notice, this list of conditions and the following
|
|
|
|
|
* disclaimer in the documentation and/or other materials
|
|
|
|
|
* provided with the distribution.
|
|
|
|
|
*
|
|
|
|
|
* THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
|
|
|
|
|
* EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
|
|
|
|
|
* MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
|
|
|
|
|
* NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS
|
|
|
|
|
* BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN
|
|
|
|
|
* ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
|
|
|
|
|
* CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
|
|
|
|
|
* SOFTWARE.
|
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
#ifndef _IPOIB_H
|
|
|
|
|
#define _IPOIB_H
|
|
|
|
|
|
|
|
|
|
#include <linux/list.h>
|
|
|
|
|
#include <linux/skbuff.h>
|
|
|
|
|
#include <linux/netdevice.h>
|
|
|
|
|
#include <linux/workqueue.h>
|
|
|
|
|
#include <linux/kref.h>
|
|
|
|
|
#include <linux/if_infiniband.h>
|
2006-01-13 23:51:39 +01:00
|
|
|
#include <linux/mutex.h>
|
2005-04-17 00:20:36 +02:00
|
|
|
|
|
|
|
|
#include <net/neighbour.h>
|
2012-02-07 15:51:21 +01:00
|
|
|
#include <net/sch_generic.h>
|
2005-04-17 00:20:36 +02:00
|
|
|
|
2011-07-27 01:09:06 +02:00
|
|
|
#include <linux/atomic.h>
|
2005-04-17 00:20:36 +02:00
|
|
|
|
2005-08-25 22:40:04 +02:00
|
|
|
#include <rdma/ib_verbs.h>
|
|
|
|
|
#include <rdma/ib_pack.h>
|
|
|
|
|
#include <rdma/ib_sa.h>
|
2011-01-11 02:41:54 +01:00
|
|
|
#include <linux/sched.h>
|
2005-04-17 00:20:36 +02:00
|
|
|
/* constants */
|
|
|
|
|
|
2008-07-15 08:48:49 +02:00
|
|
|
enum ipoib_flush_level {
|
|
|
|
|
IPOIB_FLUSH_LIGHT,
|
|
|
|
|
IPOIB_FLUSH_NORMAL,
|
|
|
|
|
IPOIB_FLUSH_HEAVY
|
|
|
|
|
};
|
|
|
|
|
|
2005-04-17 00:20:36 +02:00
|
|
|
enum {
|
2007-10-24 04:57:54 +02:00
|
|
|
IPOIB_ENCAP_LEN = 4,
|
IB/ipoib: move back IB LL address into the hard header
After the commit 9207f9d45b0a ("net: preserve IP control block
during GSO segmentation"), the GSO CB and the IPoIB CB conflict.
That destroy the IPoIB address information cached there,
causing a severe performance regression, as better described here:
http://marc.info/?l=linux-kernel&m=146787279825501&w=2
This change moves the data cached by the IPoIB driver from the
skb control lock into the IPoIB hard header, as done before
the commit 936d7de3d736 ("IPoIB: Stop lying about hard_header_len
and use skb->cb to stash LL addresses").
In order to avoid GRO issue, on packet reception, the IPoIB driver
stash into the skb a dummy pseudo header, so that the received
packets have actually a hard header matching the declared length.
To avoid changing the connected mode maximum mtu, the allocated
head buffer size is increased by the pseudo header length.
After this commit, IPoIB performances are back to pre-regression
value.
v2 -> v3: rebased
v1 -> v2: avoid changing the max mtu, increasing the head buf size
Fixes: 9207f9d45b0a ("net: preserve IP control block during GSO segmentation")
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2016-10-13 18:26:56 +02:00
|
|
|
IPOIB_PSEUDO_LEN = 20,
|
|
|
|
|
IPOIB_HARD_LEN = IPOIB_ENCAP_LEN + IPOIB_PSEUDO_LEN,
|
2005-04-17 00:20:36 +02:00
|
|
|
|
2008-04-23 20:55:45 +02:00
|
|
|
IPOIB_UD_HEAD_SIZE = IB_GRH_BYTES + IPOIB_ENCAP_LEN,
|
|
|
|
|
IPOIB_UD_RX_SG = 2, /* max buffer needed for 4K mtu */
|
|
|
|
|
|
2007-10-24 04:57:54 +02:00
|
|
|
IPOIB_CM_MTU = 0x10000 - 0x10, /* padding to align header to 16 */
|
|
|
|
|
IPOIB_CM_BUF_SIZE = IPOIB_CM_MTU + IPOIB_ENCAP_LEN,
|
|
|
|
|
IPOIB_CM_HEAD_SIZE = IPOIB_CM_BUF_SIZE % PAGE_SIZE,
|
|
|
|
|
IPOIB_CM_RX_SG = ALIGN(IPOIB_CM_BUF_SIZE, PAGE_SIZE) / PAGE_SIZE,
|
2008-07-15 08:48:52 +02:00
|
|
|
IPOIB_RX_RING_SIZE = 256,
|
|
|
|
|
IPOIB_TX_RING_SIZE = 128,
|
2006-04-10 18:43:58 +02:00
|
|
|
IPOIB_MAX_QUEUE_SIZE = 8192,
|
|
|
|
|
IPOIB_MIN_QUEUE_SIZE = 2,
|
2008-01-25 23:15:24 +01:00
|
|
|
IPOIB_CM_MAX_CONN_QP = 4096,
|
2005-04-17 00:20:36 +02:00
|
|
|
|
2007-10-24 04:57:54 +02:00
|
|
|
IPOIB_NUM_WC = 4,
|
2005-04-17 00:20:36 +02:00
|
|
|
|
|
|
|
|
IPOIB_MAX_PATH_REC_QUEUE = 3,
|
2015-09-26 04:30:24 +02:00
|
|
|
IPOIB_MAX_MCAST_QUEUE = 64,
|
2007-10-24 04:57:54 +02:00
|
|
|
|
|
|
|
|
IPOIB_FLAG_OPER_UP = 0,
|
|
|
|
|
IPOIB_FLAG_INITIALIZED = 1,
|
|
|
|
|
IPOIB_FLAG_ADMIN_UP = 2,
|
|
|
|
|
IPOIB_PKEY_ASSIGNED = 3,
|
|
|
|
|
IPOIB_FLAG_SUBINTERFACE = 5,
|
|
|
|
|
IPOIB_STOP_REAPER = 7,
|
|
|
|
|
IPOIB_FLAG_ADMIN_CM = 9,
|
2007-08-16 14:36:16 +02:00
|
|
|
IPOIB_FLAG_UMCAST = 10,
|
IPoIB: Use a private hash table for path lookup in xmit path
Dave Miller <davem@davemloft.net> provided a detailed description of
why the way IPoIB is using neighbours for its own ipoib_neigh struct
is buggy:
Any time an ipoib_neigh is changed, a sequence like the following is made:
spin_lock_irqsave(&priv->lock, flags);
/*
* It's safe to call ipoib_put_ah() inside
* priv->lock here, because we know that
* path->ah will always hold one more reference,
* so ipoib_put_ah() will never do more than
* decrement the ref count.
*/
if (neigh->ah)
ipoib_put_ah(neigh->ah);
list_del(&neigh->list);
ipoib_neigh_free(dev, neigh);
spin_unlock_irqrestore(&priv->lock, flags);
ipoib_path_lookup(skb, n, dev);
This doesn't work, because you're leaving a stale pointer to the freed up
ipoib_neigh in the special neigh->ha pointer cookie. Yes, it even fails
with all the locking done to protect _changes_ to *ipoib_neigh(n), and
with the code in ipoib_neigh_free() that NULLs out the pointer.
The core issue is that read side calls to *to_ipoib_neigh(n) are not
being synchronized at all, they are performed without any locking. So
whether we hold the lock or not when making changes to *ipoib_neigh(n)
you still can have threads see references to freed up ipoib_neigh
objects.
cpu 1 cpu 2
n = *ipoib_neigh()
*ipoib_neigh() = NULL
kfree(n)
n->foo == OOPS
[..]
Perhaps the ipoib code can have a private path database it manages
entirely itself, which holds all the necessary information and is
looked up by some generic key which is available easily at transmit
time and does not involve generic neighbour entries.
See <http://marc.info/?l=linux-rdma&m=132812793105624&w=2> and
<http://marc.info/?l=linux-rdma&w=2&r=1&s=allows+references+to+freed+memory&q=b>
for the full discussion.
This patch aims to solve the race conditions found in the IPoIB driver.
The patch removes the connection between the core networking neighbour
structure and the ipoib_neigh structure. In addition to avoiding the
race described above, it allows us to handle SKBs carrying IP packets
that don't have any associated neighbour.
We add an ipoib_neigh hash table with N buckets where the key is the
destination hardware address. The ipoib_neigh is fetched from the
hash table and instead of the stashed location in the neighbour
structure. The hash table uses both RCU and reference counting to
guarantee that no ipoib_neigh instance is ever deleted while in use.
Fetching the ipoib_neigh structure instance from the hash also makes
the special code in ipoib_start_xmit that handles remote and local
bonding failover redundant.
Aged ipoib_neigh instances are deleted by a garbage collection task
that runs every M seconds and deletes every ipoib_neigh instance that
was idle for at least 2*M seconds. The deletion is safe since the
ipoib_neigh instances are protected using RCU and reference count
mechanisms.
The number of buckets (N) and frequency of running the GC thread (M),
are taken from the exported arb_tbl.
Signed-off-by: Shlomo Pongratz <shlomop@mellanox.com>
Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com>
Signed-off-by: Roland Dreier <roland@purestorage.com>
2012-07-24 19:05:22 +02:00
|
|
|
IPOIB_STOP_NEIGH_GC = 11,
|
|
|
|
|
IPOIB_NEIGH_TBL_FLUSH = 12,
|
IB/IPoIB: Allow setting the device address
In IB networks, and specifically in IPoIB/rdmacm traffic, the device
address of an IPoIB interface is used as a means to exchange information
between nodes needed for communication.
Currently an IPoIB interface will always be created with a device
address based on its node GUID without a way to change that.
This change adds the ability to set the device address of an IPoIB
interface by value. We use the set mac address ndo to do that.
The flow should be broken down to two:
1) The GID value is already in the GID table,
in this case the interface will be able to set carrier up.
2) The GID value is not yet in the GID table,
in this case the interface won't try to join the multicast group
and will wait (listen on GID_CHANGE event) until the GID is inserted.
In order to track those changes, we add a new flag:
* IPOIB_FLAG_DEV_ADDR_SET.
When set, it means the dev_addr is a based on a value in the gid
table. this bit will be cleared upon a dev_addr change triggered
by the user and set after validation.
Per IB spec the port GUID can't change if the module is loaded.
port GUID is the basis for GID at index 0 which is the basis for
the default device address of a ipoib interface.
The issue is that there are devices that don't follow the spec,
they change the port GUID while HCA is powered on, so in order
not to break userspace applications. We need to check if the
user wanted to control the device address and we assume that
if he sets the device address back to be based on GID index 0,
he no longer wishs to control it.
In order to track this, we add an additional flag:
* IPOIB_FLAG_DEV_ADDR_CTRL
When setting the device address, there is no validation of the upper
twelve bytes of the device address (flags, qpn, subnet prefix) as those
bytes are not under the control of the user.
Signed-off-by: Mark Bloch <markb@mellanox.com>
Reviewed-by: Leon Romanovsky <leonro@mellanox.com>
Signed-off-by: Leon Romanovsky <leon@kernel.org>
Signed-off-by: Doug Ledford <dledford@redhat.com>
2016-05-18 15:42:43 +02:00
|
|
|
IPOIB_FLAG_DEV_ADDR_SET = 13,
|
|
|
|
|
IPOIB_FLAG_DEV_ADDR_CTRL = 14,
|
2016-06-04 14:15:20 +02:00
|
|
|
IPOIB_FLAG_GOING_DOWN = 15,
|
2005-04-17 00:20:36 +02:00
|
|
|
|
|
|
|
|
IPOIB_MAX_BACKOFF_SECONDS = 16,
|
|
|
|
|
|
2007-10-24 04:57:54 +02:00
|
|
|
IPOIB_MCAST_FLAG_FOUND = 0, /* used in set_multicast_list */
|
2005-04-17 00:20:36 +02:00
|
|
|
IPOIB_MCAST_FLAG_SENDONLY = 1,
|
IB/ipoib: fix MCAST_FLAG_BUSY usage
Commit a9c8ba5884 ("IPoIB: Fix usage of uninitialized multicast
objects") added a new flag MCAST_JOIN_STARTED, but was not very strict
in how it was used. We didn't always initialize the completion struct
before we set the flag, and we didn't always call complete on the
completion struct from all paths that complete it. And when we did
complete it, sometimes we continued to touch the mcast entry after
the completion, opening us up to possible use after free issues.
This made it less than totally effective, and certainly made its use
confusing. And in the flush function we would use the presence of this
flag to signal that we should wait on the completion struct, but we never
cleared this flag, ever.
In order to make things clearer and aid in resolving the rtnl deadlock
bug I've been chasing, I cleaned this up a bit.
1) Remove the MCAST_JOIN_STARTED flag entirely
2) Change MCAST_FLAG_BUSY so it now only means a join is in-flight
3) Test mcast->mc directly to see if we have completed
ib_sa_join_multicast (using IS_ERR_OR_NULL)
4) Make sure that before setting MCAST_FLAG_BUSY we always initialize
the mcast->done completion struct
5) Make sure that before calling complete(&mcast->done), we always clear
the MCAST_FLAG_BUSY bit
6) Take the mcast_mutex before we call ib_sa_multicast_join and also
take the mutex in our join callback. This forces
ib_sa_multicast_join to return and set mcast->mc before we process
the callback. This way, our callback can safely clear mcast->mc
if there is an error on the join and we will do the right thing as
a result in mcast_dev_flush.
7) Because we need the mutex to synchronize mcast->mc, we can no
longer call mcast_sendonly_join directly from mcast_send and
instead must add sendonly join processing to the mcast_join_task
8) Make MCAST_RUN mean that we have a working mcast subsystem, not that
we have a running task. We know when we need to reschedule our
join task thread and don't need a flag to tell us.
9) Add a helper for rescheduling the join task thread
A number of different races are resolved with these changes. These
races existed with the old MCAST_FLAG_BUSY usage, the
MCAST_JOIN_STARTED flag was an attempt to address them, and while it
helped, a determined effort could still trip things up.
One race looks something like this:
Thread 1 Thread 2
ib_sa_join_multicast (as part of running restart mcast task)
alloc member
call callback
ifconfig ib0 down
wait_for_completion
callback call completes
wait_for_completion in
mcast_dev_flush completes
mcast->mc is PTR_ERR_OR_NULL
so we skip ib_sa_leave_multicast
return from callback
return from ib_sa_join_multicast
set mcast->mc = return from ib_sa_multicast
We now have a permanently unbalanced join/leave issue that trips up the
refcounting in core/multicast.c
Another like this:
Thread 1 Thread 2 Thread 3
ib_sa_multicast_join
ifconfig ib0 down
priv->broadcast = NULL
join_complete
wait_for_completion
mcast->mc is not yet set, so don't clear
return from ib_sa_join_multicast and set mcast->mc
complete
return -EAGAIN (making mcast->mc invalid)
call ib_sa_multicast_leave
on invalid mcast->mc, hang
forever
By holding the mutex around ib_sa_multicast_join and taking the mutex
early in the callback, we force mcast->mc to be valid at the time we
run the callback. This allows us to clear mcast->mc if there is an
error and the join is going to fail. We do this before we complete
the mcast. In this way, mcast_dev_flush always sees consistent state
in regards to mcast->mc membership at the time that the
wait_for_completion() returns.
Signed-off-by: Doug Ledford <dledford@redhat.com>
2015-02-22 01:27:05 +01:00
|
|
|
/*
|
|
|
|
|
* For IPOIB_MCAST_FLAG_BUSY
|
|
|
|
|
* When set, in flight join and mcast->mc is unreliable
|
|
|
|
|
* When clear and mcast->mc IS_ERR_OR_NULL, need to restart or
|
|
|
|
|
* haven't started yet
|
|
|
|
|
* When clear and mcast->mc is valid pointer, join was successful
|
|
|
|
|
*/
|
|
|
|
|
IPOIB_MCAST_FLAG_BUSY = 2,
|
2005-04-17 00:20:36 +02:00
|
|
|
IPOIB_MCAST_FLAG_ATTACHED = 3,
|
2008-04-29 22:46:53 +02:00
|
|
|
|
2017-10-19 06:56:44 +02:00
|
|
|
MAX_SEND_CQE = 64,
|
IPoIB: Copy small received SKBs in connected mode
The connected mode implementation in the IPoIB driver has a large
overhead in the way SKBs are handled in the receive flow. It usually
allocates an SKB with as big as was used in the currently received SKB
and moves unused fragments from the old SKB to the new one. This
involves a loop on all the remaining fragments and incurs overhead on
the CPU. This patch, for small SKBs, allocates an SKB just large
enough to contain the received data and copies to it the data from the
received SKB. The newly allocated SKB is passed to the stack and the
old SKB is reposted.
When running netperf, UDP small messages, without this pach I get:
UDP UNIDIRECTIONAL SEND TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to
14.4.3.178 (14.4.3.178) port 0 AF_INET
Socket Message Elapsed Messages
Size Size Time Okay Errors Throughput
bytes bytes secs # # 10^6bits/sec
114688 128 10.00 5142034 0 526.31
114688 10.00 1130489 115.71
With this patch I get both send and receive at ~315 mbps.
The reason that send performance actually slows down is as follows:
When using this patch, the overhead of the CPU for handling RX packets
is dramatically reduced. As a result, we do not experience RNR NAK
messages from the receiver which cause the connection to be closed and
reopened again; when the patch is not used, the receiver cannot handle
the packets fast enough so there is less time to post new buffers and
hence the mentioned RNR NACKs. So what happens is that the
application *thinks* it posted a certain number of packets for
transmission but these packets are flushed and do not really get
transmitted. Since the connection gets opened and closed many times,
each time netperf gets the CPU time that otherwise would have been
given to IPoIB to actually transmit the packets. This can be verified
when looking at the port counters -- the output of ifconfig and the
oputput of netperf (this is for the case without the patch):
tx packets
==========
port counter: 1,543,996
ifconfig: 1,581,426
netperf: 5,142,034
rx packets
==========
netperf 1,1304,089
Signed-off-by: Eli Cohen <eli@mellanox.co.il>
2008-07-15 08:48:44 +02:00
|
|
|
IPOIB_CM_COPYBREAK = 256,
|
2012-09-13 07:56:36 +02:00
|
|
|
|
|
|
|
|
IPOIB_NON_CHILD = 0,
|
|
|
|
|
IPOIB_LEGACY_CHILD = 1,
|
|
|
|
|
IPOIB_RTNL_CHILD = 2,
|
2005-04-17 00:20:36 +02:00
|
|
|
};
|
|
|
|
|
|
2007-02-05 21:12:23 +01:00
|
|
|
#define IPOIB_OP_RECV (1ul << 31)
|
|
|
|
|
#ifdef CONFIG_INFINIBAND_IPOIB_CM
|
2007-08-16 14:36:16 +02:00
|
|
|
#define IPOIB_OP_CM (1ul << 30)
|
2007-02-05 21:12:23 +01:00
|
|
|
#else
|
2007-08-16 14:36:16 +02:00
|
|
|
#define IPOIB_OP_CM (0)
|
2007-02-05 21:12:23 +01:00
|
|
|
#endif
|
|
|
|
|
|
2013-02-19 16:40:22 +01:00
|
|
|
#define IPOIB_QPN_MASK ((__force u32) cpu_to_be32(0xFFFFFF))
|
|
|
|
|
|
2005-04-17 00:20:36 +02:00
|
|
|
/* structs */
|
|
|
|
|
|
|
|
|
|
struct ipoib_header {
|
2005-08-14 06:05:57 +02:00
|
|
|
__be16 proto;
|
|
|
|
|
u16 reserved;
|
2005-04-17 00:20:36 +02:00
|
|
|
};
|
|
|
|
|
|
IB/ipoib: move back IB LL address into the hard header
After the commit 9207f9d45b0a ("net: preserve IP control block
during GSO segmentation"), the GSO CB and the IPoIB CB conflict.
That destroy the IPoIB address information cached there,
causing a severe performance regression, as better described here:
http://marc.info/?l=linux-kernel&m=146787279825501&w=2
This change moves the data cached by the IPoIB driver from the
skb control lock into the IPoIB hard header, as done before
the commit 936d7de3d736 ("IPoIB: Stop lying about hard_header_len
and use skb->cb to stash LL addresses").
In order to avoid GRO issue, on packet reception, the IPoIB driver
stash into the skb a dummy pseudo header, so that the received
packets have actually a hard header matching the declared length.
To avoid changing the connected mode maximum mtu, the allocated
head buffer size is increased by the pseudo header length.
After this commit, IPoIB performances are back to pre-regression
value.
v2 -> v3: rebased
v1 -> v2: avoid changing the max mtu, increasing the head buf size
Fixes: 9207f9d45b0a ("net: preserve IP control block during GSO segmentation")
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2016-10-13 18:26:56 +02:00
|
|
|
struct ipoib_pseudo_header {
|
|
|
|
|
u8 hwaddr[INFINIBAND_ALEN];
|
2005-04-17 00:20:36 +02:00
|
|
|
};
|
|
|
|
|
|
IB/ipoib: move back IB LL address into the hard header
After the commit 9207f9d45b0a ("net: preserve IP control block
during GSO segmentation"), the GSO CB and the IPoIB CB conflict.
That destroy the IPoIB address information cached there,
causing a severe performance regression, as better described here:
http://marc.info/?l=linux-kernel&m=146787279825501&w=2
This change moves the data cached by the IPoIB driver from the
skb control lock into the IPoIB hard header, as done before
the commit 936d7de3d736 ("IPoIB: Stop lying about hard_header_len
and use skb->cb to stash LL addresses").
In order to avoid GRO issue, on packet reception, the IPoIB driver
stash into the skb a dummy pseudo header, so that the received
packets have actually a hard header matching the declared length.
To avoid changing the connected mode maximum mtu, the allocated
head buffer size is increased by the pseudo header length.
After this commit, IPoIB performances are back to pre-regression
value.
v2 -> v3: rebased
v1 -> v2: avoid changing the max mtu, increasing the head buf size
Fixes: 9207f9d45b0a ("net: preserve IP control block during GSO segmentation")
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2016-10-13 18:26:56 +02:00
|
|
|
static inline void skb_add_pseudo_hdr(struct sk_buff *skb)
|
2014-09-18 20:00:27 +02:00
|
|
|
{
|
IB/ipoib: move back IB LL address into the hard header
After the commit 9207f9d45b0a ("net: preserve IP control block
during GSO segmentation"), the GSO CB and the IPoIB CB conflict.
That destroy the IPoIB address information cached there,
causing a severe performance regression, as better described here:
http://marc.info/?l=linux-kernel&m=146787279825501&w=2
This change moves the data cached by the IPoIB driver from the
skb control lock into the IPoIB hard header, as done before
the commit 936d7de3d736 ("IPoIB: Stop lying about hard_header_len
and use skb->cb to stash LL addresses").
In order to avoid GRO issue, on packet reception, the IPoIB driver
stash into the skb a dummy pseudo header, so that the received
packets have actually a hard header matching the declared length.
To avoid changing the connected mode maximum mtu, the allocated
head buffer size is increased by the pseudo header length.
After this commit, IPoIB performances are back to pre-regression
value.
v2 -> v3: rebased
v1 -> v2: avoid changing the max mtu, increasing the head buf size
Fixes: 9207f9d45b0a ("net: preserve IP control block during GSO segmentation")
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2016-10-13 18:26:56 +02:00
|
|
|
char *data = skb_push(skb, IPOIB_PSEUDO_LEN);
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* only the ipoib header is present now, make room for a dummy
|
|
|
|
|
* pseudo header and set skb field accordingly
|
|
|
|
|
*/
|
|
|
|
|
memset(data, 0, IPOIB_PSEUDO_LEN);
|
|
|
|
|
skb_reset_mac_header(skb);
|
|
|
|
|
skb_pull(skb, IPOIB_HARD_LEN);
|
2014-09-18 20:00:27 +02:00
|
|
|
}
|
|
|
|
|
|
2017-04-10 10:22:30 +02:00
|
|
|
static inline struct ipoib_dev_priv *ipoib_priv(const struct net_device *dev)
|
|
|
|
|
{
|
|
|
|
|
struct rdma_netdev *rn = netdev_priv(dev);
|
|
|
|
|
|
|
|
|
|
return rn->clnt_priv;
|
|
|
|
|
}
|
2017-04-10 10:22:29 +02:00
|
|
|
|
2007-08-02 21:21:31 +02:00
|
|
|
/* Used for all multicast joins (broadcast, IPv4 mcast and IPv6 mcast) */
|
|
|
|
|
struct ipoib_mcast {
|
|
|
|
|
struct ib_sa_mcmember_rec mcmember;
|
|
|
|
|
struct ib_sa_multicast *mc;
|
2007-10-24 04:57:54 +02:00
|
|
|
struct ipoib_ah *ah;
|
2007-08-02 21:21:31 +02:00
|
|
|
|
|
|
|
|
struct rb_node rb_node;
|
|
|
|
|
struct list_head list;
|
|
|
|
|
|
|
|
|
|
unsigned long created;
|
|
|
|
|
unsigned long backoff;
|
IB/ipoib: fix MCAST_FLAG_BUSY usage
Commit a9c8ba5884 ("IPoIB: Fix usage of uninitialized multicast
objects") added a new flag MCAST_JOIN_STARTED, but was not very strict
in how it was used. We didn't always initialize the completion struct
before we set the flag, and we didn't always call complete on the
completion struct from all paths that complete it. And when we did
complete it, sometimes we continued to touch the mcast entry after
the completion, opening us up to possible use after free issues.
This made it less than totally effective, and certainly made its use
confusing. And in the flush function we would use the presence of this
flag to signal that we should wait on the completion struct, but we never
cleared this flag, ever.
In order to make things clearer and aid in resolving the rtnl deadlock
bug I've been chasing, I cleaned this up a bit.
1) Remove the MCAST_JOIN_STARTED flag entirely
2) Change MCAST_FLAG_BUSY so it now only means a join is in-flight
3) Test mcast->mc directly to see if we have completed
ib_sa_join_multicast (using IS_ERR_OR_NULL)
4) Make sure that before setting MCAST_FLAG_BUSY we always initialize
the mcast->done completion struct
5) Make sure that before calling complete(&mcast->done), we always clear
the MCAST_FLAG_BUSY bit
6) Take the mcast_mutex before we call ib_sa_multicast_join and also
take the mutex in our join callback. This forces
ib_sa_multicast_join to return and set mcast->mc before we process
the callback. This way, our callback can safely clear mcast->mc
if there is an error on the join and we will do the right thing as
a result in mcast_dev_flush.
7) Because we need the mutex to synchronize mcast->mc, we can no
longer call mcast_sendonly_join directly from mcast_send and
instead must add sendonly join processing to the mcast_join_task
8) Make MCAST_RUN mean that we have a working mcast subsystem, not that
we have a running task. We know when we need to reschedule our
join task thread and don't need a flag to tell us.
9) Add a helper for rescheduling the join task thread
A number of different races are resolved with these changes. These
races existed with the old MCAST_FLAG_BUSY usage, the
MCAST_JOIN_STARTED flag was an attempt to address them, and while it
helped, a determined effort could still trip things up.
One race looks something like this:
Thread 1 Thread 2
ib_sa_join_multicast (as part of running restart mcast task)
alloc member
call callback
ifconfig ib0 down
wait_for_completion
callback call completes
wait_for_completion in
mcast_dev_flush completes
mcast->mc is PTR_ERR_OR_NULL
so we skip ib_sa_leave_multicast
return from callback
return from ib_sa_join_multicast
set mcast->mc = return from ib_sa_multicast
We now have a permanently unbalanced join/leave issue that trips up the
refcounting in core/multicast.c
Another like this:
Thread 1 Thread 2 Thread 3
ib_sa_multicast_join
ifconfig ib0 down
priv->broadcast = NULL
join_complete
wait_for_completion
mcast->mc is not yet set, so don't clear
return from ib_sa_join_multicast and set mcast->mc
complete
return -EAGAIN (making mcast->mc invalid)
call ib_sa_multicast_leave
on invalid mcast->mc, hang
forever
By holding the mutex around ib_sa_multicast_join and taking the mutex
early in the callback, we force mcast->mc to be valid at the time we
run the callback. This allows us to clear mcast->mc if there is an
error and the join is going to fail. We do this before we complete
the mcast. In this way, mcast_dev_flush always sees consistent state
in regards to mcast->mc membership at the time that the
wait_for_completion() returns.
Signed-off-by: Doug Ledford <dledford@redhat.com>
2015-02-22 01:27:05 +01:00
|
|
|
unsigned long delay_until;
|
2007-08-02 21:21:31 +02:00
|
|
|
|
|
|
|
|
unsigned long flags;
|
|
|
|
|
unsigned char logcount;
|
|
|
|
|
|
|
|
|
|
struct list_head neigh_list;
|
|
|
|
|
|
|
|
|
|
struct sk_buff_head pkt_queue;
|
|
|
|
|
|
|
|
|
|
struct net_device *dev;
|
2013-10-16 16:37:51 +02:00
|
|
|
struct completion done;
|
2007-08-02 21:21:31 +02:00
|
|
|
};
|
2005-04-17 00:20:36 +02:00
|
|
|
|
2005-10-29 00:30:34 +02:00
|
|
|
struct ipoib_rx_buf {
|
|
|
|
|
struct sk_buff *skb;
|
2008-04-23 20:55:45 +02:00
|
|
|
u64 mapping[IPOIB_UD_RX_SG];
|
2005-10-29 00:30:34 +02:00
|
|
|
};
|
|
|
|
|
|
|
|
|
|
struct ipoib_tx_buf {
|
2005-04-17 00:20:36 +02:00
|
|
|
struct sk_buff *skb;
|
2008-01-30 17:30:53 +01:00
|
|
|
u64 mapping[MAX_SKB_FRAGS + 1];
|
2005-04-17 00:20:36 +02:00
|
|
|
};
|
|
|
|
|
|
2008-07-15 08:48:52 +02:00
|
|
|
struct ipoib_cm_tx_buf {
|
|
|
|
|
struct sk_buff *skb;
|
|
|
|
|
u64 mapping;
|
|
|
|
|
};
|
|
|
|
|
|
2007-02-05 21:12:23 +01:00
|
|
|
struct ib_cm_id;
|
|
|
|
|
|
|
|
|
|
struct ipoib_cm_data {
|
|
|
|
|
__be32 qpn; /* High byte MUST be ignored on receive */
|
|
|
|
|
__be32 mtu;
|
|
|
|
|
};
|
|
|
|
|
|
2007-05-21 14:04:59 +02:00
|
|
|
/*
|
|
|
|
|
* Quoting 10.3.1 Queue Pair and EE Context States:
|
|
|
|
|
*
|
|
|
|
|
* Note, for QPs that are associated with an SRQ, the Consumer should take the
|
|
|
|
|
* QP through the Error State before invoking a Destroy QP or a Modify QP to the
|
|
|
|
|
* Reset State. The Consumer may invoke the Destroy QP without first performing
|
|
|
|
|
* a Modify QP to the Error State and waiting for the Affiliated Asynchronous
|
|
|
|
|
* Last WQE Reached Event. However, if the Consumer does not wait for the
|
|
|
|
|
* Affiliated Asynchronous Last WQE Reached Event, then WQE and Data Segment
|
|
|
|
|
* leakage may occur. Therefore, it is good programming practice to tear down a
|
|
|
|
|
* QP that is associated with an SRQ by using the following process:
|
|
|
|
|
*
|
|
|
|
|
* - Put the QP in the Error State
|
|
|
|
|
* - Wait for the Affiliated Asynchronous Last WQE Reached Event;
|
|
|
|
|
* - either:
|
|
|
|
|
* drain the CQ by invoking the Poll CQ verb and either wait for CQ
|
|
|
|
|
* to be empty or the number of Poll CQ operations has exceeded
|
|
|
|
|
* CQ capacity size;
|
|
|
|
|
* - or
|
|
|
|
|
* post another WR that completes on the same CQ and wait for this
|
|
|
|
|
* WR to return as a WC;
|
|
|
|
|
* - and then invoke a Destroy QP or Reset QP.
|
|
|
|
|
*
|
|
|
|
|
* We use the second option and wait for a completion on the
|
2007-05-28 13:37:27 +02:00
|
|
|
* same CQ before destroying QPs attached to our SRQ.
|
2007-05-21 14:04:59 +02:00
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
enum ipoib_cm_state {
|
|
|
|
|
IPOIB_CM_RX_LIVE,
|
|
|
|
|
IPOIB_CM_RX_ERROR, /* Ignored by stale task */
|
|
|
|
|
IPOIB_CM_RX_FLUSH /* Last WQE Reached event observed */
|
|
|
|
|
};
|
|
|
|
|
|
2007-02-05 21:12:23 +01:00
|
|
|
struct ipoib_cm_rx {
|
2007-10-24 04:57:54 +02:00
|
|
|
struct ib_cm_id *id;
|
|
|
|
|
struct ib_qp *qp;
|
2008-01-25 23:15:24 +01:00
|
|
|
struct ipoib_cm_rx_buf *rx_ring;
|
2007-10-24 04:57:54 +02:00
|
|
|
struct list_head list;
|
|
|
|
|
struct net_device *dev;
|
|
|
|
|
unsigned long jiffies;
|
|
|
|
|
enum ipoib_cm_state state;
|
2008-01-25 23:15:24 +01:00
|
|
|
int recv_count;
|
2007-02-05 21:12:23 +01:00
|
|
|
};
|
|
|
|
|
|
|
|
|
|
struct ipoib_cm_tx {
|
2007-10-24 04:57:54 +02:00
|
|
|
struct ib_cm_id *id;
|
|
|
|
|
struct ib_qp *qp;
|
2007-02-05 21:12:23 +01:00
|
|
|
struct list_head list;
|
|
|
|
|
struct net_device *dev;
|
|
|
|
|
struct ipoib_neigh *neigh;
|
|
|
|
|
struct ipoib_path *path;
|
2015-07-12 10:24:09 +02:00
|
|
|
struct ipoib_tx_buf *tx_ring;
|
2007-10-24 04:57:54 +02:00
|
|
|
unsigned tx_head;
|
|
|
|
|
unsigned tx_tail;
|
|
|
|
|
unsigned long flags;
|
|
|
|
|
u32 mtu;
|
2016-03-02 13:44:28 +01:00
|
|
|
unsigned max_send_sge;
|
2007-02-05 21:12:23 +01:00
|
|
|
};
|
|
|
|
|
|
|
|
|
|
struct ipoib_cm_rx_buf {
|
|
|
|
|
struct sk_buff *skb;
|
|
|
|
|
u64 mapping[IPOIB_CM_RX_SG];
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
struct ipoib_cm_dev_priv {
|
2007-10-24 04:57:54 +02:00
|
|
|
struct ib_srq *srq;
|
2007-02-05 21:12:23 +01:00
|
|
|
struct ipoib_cm_rx_buf *srq_ring;
|
2007-10-24 04:57:54 +02:00
|
|
|
struct ib_cm_id *id;
|
|
|
|
|
struct list_head passive_ids; /* state: LIVE */
|
|
|
|
|
struct list_head rx_error_list; /* state: ERROR */
|
|
|
|
|
struct list_head rx_flush_list; /* state: FLUSH, drain not started */
|
|
|
|
|
struct list_head rx_drain_list; /* state: FLUSH, drain started */
|
|
|
|
|
struct list_head rx_reap_list; /* state: FLUSH, drain done */
|
2007-02-05 21:12:23 +01:00
|
|
|
struct work_struct start_task;
|
|
|
|
|
struct work_struct reap_task;
|
|
|
|
|
struct work_struct skb_task;
|
2007-05-21 14:04:59 +02:00
|
|
|
struct work_struct rx_reap_task;
|
2007-02-05 21:12:23 +01:00
|
|
|
struct delayed_work stale_task;
|
|
|
|
|
struct sk_buff_head skb_queue;
|
2007-10-24 04:57:54 +02:00
|
|
|
struct list_head start_list;
|
|
|
|
|
struct list_head reap_list;
|
|
|
|
|
struct ib_wc ibwc[IPOIB_NUM_WC];
|
|
|
|
|
struct ib_sge rx_sge[IPOIB_CM_RX_SG];
|
2007-02-05 21:12:23 +01:00
|
|
|
struct ib_recv_wr rx_wr;
|
2008-01-25 23:15:24 +01:00
|
|
|
int nonsrq_conn_qp;
|
2007-12-21 22:08:23 +01:00
|
|
|
int max_cm_mtu;
|
|
|
|
|
int num_frags;
|
2007-02-05 21:12:23 +01:00
|
|
|
};
|
|
|
|
|
|
2008-04-17 06:09:33 +02:00
|
|
|
struct ipoib_ethtool_st {
|
|
|
|
|
u16 coalesce_usecs;
|
|
|
|
|
u16 max_coalesced_frames;
|
|
|
|
|
};
|
|
|
|
|
|
2012-08-29 17:14:33 +02:00
|
|
|
struct ipoib_neigh_table;
|
|
|
|
|
|
IPoIB: Use a private hash table for path lookup in xmit path
Dave Miller <davem@davemloft.net> provided a detailed description of
why the way IPoIB is using neighbours for its own ipoib_neigh struct
is buggy:
Any time an ipoib_neigh is changed, a sequence like the following is made:
spin_lock_irqsave(&priv->lock, flags);
/*
* It's safe to call ipoib_put_ah() inside
* priv->lock here, because we know that
* path->ah will always hold one more reference,
* so ipoib_put_ah() will never do more than
* decrement the ref count.
*/
if (neigh->ah)
ipoib_put_ah(neigh->ah);
list_del(&neigh->list);
ipoib_neigh_free(dev, neigh);
spin_unlock_irqrestore(&priv->lock, flags);
ipoib_path_lookup(skb, n, dev);
This doesn't work, because you're leaving a stale pointer to the freed up
ipoib_neigh in the special neigh->ha pointer cookie. Yes, it even fails
with all the locking done to protect _changes_ to *ipoib_neigh(n), and
with the code in ipoib_neigh_free() that NULLs out the pointer.
The core issue is that read side calls to *to_ipoib_neigh(n) are not
being synchronized at all, they are performed without any locking. So
whether we hold the lock or not when making changes to *ipoib_neigh(n)
you still can have threads see references to freed up ipoib_neigh
objects.
cpu 1 cpu 2
n = *ipoib_neigh()
*ipoib_neigh() = NULL
kfree(n)
n->foo == OOPS
[..]
Perhaps the ipoib code can have a private path database it manages
entirely itself, which holds all the necessary information and is
looked up by some generic key which is available easily at transmit
time and does not involve generic neighbour entries.
See <http://marc.info/?l=linux-rdma&m=132812793105624&w=2> and
<http://marc.info/?l=linux-rdma&w=2&r=1&s=allows+references+to+freed+memory&q=b>
for the full discussion.
This patch aims to solve the race conditions found in the IPoIB driver.
The patch removes the connection between the core networking neighbour
structure and the ipoib_neigh structure. In addition to avoiding the
race described above, it allows us to handle SKBs carrying IP packets
that don't have any associated neighbour.
We add an ipoib_neigh hash table with N buckets where the key is the
destination hardware address. The ipoib_neigh is fetched from the
hash table and instead of the stashed location in the neighbour
structure. The hash table uses both RCU and reference counting to
guarantee that no ipoib_neigh instance is ever deleted while in use.
Fetching the ipoib_neigh structure instance from the hash also makes
the special code in ipoib_start_xmit that handles remote and local
bonding failover redundant.
Aged ipoib_neigh instances are deleted by a garbage collection task
that runs every M seconds and deletes every ipoib_neigh instance that
was idle for at least 2*M seconds. The deletion is safe since the
ipoib_neigh instances are protected using RCU and reference count
mechanisms.
The number of buckets (N) and frequency of running the GC thread (M),
are taken from the exported arb_tbl.
Signed-off-by: Shlomo Pongratz <shlomop@mellanox.com>
Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com>
Signed-off-by: Roland Dreier <roland@purestorage.com>
2012-07-24 19:05:22 +02:00
|
|
|
struct ipoib_neigh_hash {
|
2012-08-29 17:14:33 +02:00
|
|
|
struct ipoib_neigh_table *ntbl;
|
IPoIB: Use a private hash table for path lookup in xmit path
Dave Miller <davem@davemloft.net> provided a detailed description of
why the way IPoIB is using neighbours for its own ipoib_neigh struct
is buggy:
Any time an ipoib_neigh is changed, a sequence like the following is made:
spin_lock_irqsave(&priv->lock, flags);
/*
* It's safe to call ipoib_put_ah() inside
* priv->lock here, because we know that
* path->ah will always hold one more reference,
* so ipoib_put_ah() will never do more than
* decrement the ref count.
*/
if (neigh->ah)
ipoib_put_ah(neigh->ah);
list_del(&neigh->list);
ipoib_neigh_free(dev, neigh);
spin_unlock_irqrestore(&priv->lock, flags);
ipoib_path_lookup(skb, n, dev);
This doesn't work, because you're leaving a stale pointer to the freed up
ipoib_neigh in the special neigh->ha pointer cookie. Yes, it even fails
with all the locking done to protect _changes_ to *ipoib_neigh(n), and
with the code in ipoib_neigh_free() that NULLs out the pointer.
The core issue is that read side calls to *to_ipoib_neigh(n) are not
being synchronized at all, they are performed without any locking. So
whether we hold the lock or not when making changes to *ipoib_neigh(n)
you still can have threads see references to freed up ipoib_neigh
objects.
cpu 1 cpu 2
n = *ipoib_neigh()
*ipoib_neigh() = NULL
kfree(n)
n->foo == OOPS
[..]
Perhaps the ipoib code can have a private path database it manages
entirely itself, which holds all the necessary information and is
looked up by some generic key which is available easily at transmit
time and does not involve generic neighbour entries.
See <http://marc.info/?l=linux-rdma&m=132812793105624&w=2> and
<http://marc.info/?l=linux-rdma&w=2&r=1&s=allows+references+to+freed+memory&q=b>
for the full discussion.
This patch aims to solve the race conditions found in the IPoIB driver.
The patch removes the connection between the core networking neighbour
structure and the ipoib_neigh structure. In addition to avoiding the
race described above, it allows us to handle SKBs carrying IP packets
that don't have any associated neighbour.
We add an ipoib_neigh hash table with N buckets where the key is the
destination hardware address. The ipoib_neigh is fetched from the
hash table and instead of the stashed location in the neighbour
structure. The hash table uses both RCU and reference counting to
guarantee that no ipoib_neigh instance is ever deleted while in use.
Fetching the ipoib_neigh structure instance from the hash also makes
the special code in ipoib_start_xmit that handles remote and local
bonding failover redundant.
Aged ipoib_neigh instances are deleted by a garbage collection task
that runs every M seconds and deletes every ipoib_neigh instance that
was idle for at least 2*M seconds. The deletion is safe since the
ipoib_neigh instances are protected using RCU and reference count
mechanisms.
The number of buckets (N) and frequency of running the GC thread (M),
are taken from the exported arb_tbl.
Signed-off-by: Shlomo Pongratz <shlomop@mellanox.com>
Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com>
Signed-off-by: Roland Dreier <roland@purestorage.com>
2012-07-24 19:05:22 +02:00
|
|
|
struct ipoib_neigh __rcu **buckets;
|
|
|
|
|
struct rcu_head rcu;
|
|
|
|
|
u32 mask;
|
|
|
|
|
u32 size;
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
struct ipoib_neigh_table {
|
|
|
|
|
struct ipoib_neigh_hash __rcu *htbl;
|
|
|
|
|
atomic_t entries;
|
|
|
|
|
struct completion flushed;
|
2012-08-29 17:14:33 +02:00
|
|
|
struct completion deleted;
|
IPoIB: Use a private hash table for path lookup in xmit path
Dave Miller <davem@davemloft.net> provided a detailed description of
why the way IPoIB is using neighbours for its own ipoib_neigh struct
is buggy:
Any time an ipoib_neigh is changed, a sequence like the following is made:
spin_lock_irqsave(&priv->lock, flags);
/*
* It's safe to call ipoib_put_ah() inside
* priv->lock here, because we know that
* path->ah will always hold one more reference,
* so ipoib_put_ah() will never do more than
* decrement the ref count.
*/
if (neigh->ah)
ipoib_put_ah(neigh->ah);
list_del(&neigh->list);
ipoib_neigh_free(dev, neigh);
spin_unlock_irqrestore(&priv->lock, flags);
ipoib_path_lookup(skb, n, dev);
This doesn't work, because you're leaving a stale pointer to the freed up
ipoib_neigh in the special neigh->ha pointer cookie. Yes, it even fails
with all the locking done to protect _changes_ to *ipoib_neigh(n), and
with the code in ipoib_neigh_free() that NULLs out the pointer.
The core issue is that read side calls to *to_ipoib_neigh(n) are not
being synchronized at all, they are performed without any locking. So
whether we hold the lock or not when making changes to *ipoib_neigh(n)
you still can have threads see references to freed up ipoib_neigh
objects.
cpu 1 cpu 2
n = *ipoib_neigh()
*ipoib_neigh() = NULL
kfree(n)
n->foo == OOPS
[..]
Perhaps the ipoib code can have a private path database it manages
entirely itself, which holds all the necessary information and is
looked up by some generic key which is available easily at transmit
time and does not involve generic neighbour entries.
See <http://marc.info/?l=linux-rdma&m=132812793105624&w=2> and
<http://marc.info/?l=linux-rdma&w=2&r=1&s=allows+references+to+freed+memory&q=b>
for the full discussion.
This patch aims to solve the race conditions found in the IPoIB driver.
The patch removes the connection between the core networking neighbour
structure and the ipoib_neigh structure. In addition to avoiding the
race described above, it allows us to handle SKBs carrying IP packets
that don't have any associated neighbour.
We add an ipoib_neigh hash table with N buckets where the key is the
destination hardware address. The ipoib_neigh is fetched from the
hash table and instead of the stashed location in the neighbour
structure. The hash table uses both RCU and reference counting to
guarantee that no ipoib_neigh instance is ever deleted while in use.
Fetching the ipoib_neigh structure instance from the hash also makes
the special code in ipoib_start_xmit that handles remote and local
bonding failover redundant.
Aged ipoib_neigh instances are deleted by a garbage collection task
that runs every M seconds and deletes every ipoib_neigh instance that
was idle for at least 2*M seconds. The deletion is safe since the
ipoib_neigh instances are protected using RCU and reference count
mechanisms.
The number of buckets (N) and frequency of running the GC thread (M),
are taken from the exported arb_tbl.
Signed-off-by: Shlomo Pongratz <shlomop@mellanox.com>
Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com>
Signed-off-by: Roland Dreier <roland@purestorage.com>
2012-07-24 19:05:22 +02:00
|
|
|
};
|
|
|
|
|
|
2015-04-02 12:39:02 +02:00
|
|
|
struct ipoib_qp_state_validate {
|
|
|
|
|
struct work_struct work;
|
|
|
|
|
struct ipoib_dev_priv *priv;
|
|
|
|
|
};
|
|
|
|
|
|
2005-04-17 00:20:36 +02:00
|
|
|
/*
|
2008-09-30 19:36:21 +02:00
|
|
|
* Device private locking: network stack tx_lock protects members used
|
|
|
|
|
* in TX fast path, lock protects everything else. lock nests inside
|
|
|
|
|
* of tx_lock (ie tx_lock must be acquired first if needed).
|
2005-04-17 00:20:36 +02:00
|
|
|
*/
|
|
|
|
|
struct ipoib_dev_priv {
|
|
|
|
|
spinlock_t lock;
|
|
|
|
|
|
|
|
|
|
struct net_device *dev;
|
|
|
|
|
|
2017-10-19 06:56:43 +02:00
|
|
|
struct napi_struct send_napi;
|
|
|
|
|
struct napi_struct recv_napi;
|
[NET]: Make NAPI polling independent of struct net_device objects.
Several devices have multiple independant RX queues per net
device, and some have a single interrupt doorbell for several
queues.
In either case, it's easier to support layouts like that if the
structure representing the poll is independant from the net
device itself.
The signature of the ->poll() call back goes from:
int foo_poll(struct net_device *dev, int *budget)
to
int foo_poll(struct napi_struct *napi, int budget)
The caller is returned the number of RX packets processed (or
the number of "NAPI credits" consumed if you want to get
abstract). The callee no longer messes around bumping
dev->quota, *budget, etc. because that is all handled in the
caller upon return.
The napi_struct is to be embedded in the device driver private data
structures.
Furthermore, it is the driver's responsibility to disable all NAPI
instances in it's ->stop() device close handler. Since the
napi_struct is privatized into the driver's private data structures,
only the driver knows how to get at all of the napi_struct instances
it may have per-device.
With lots of help and suggestions from Rusty Russell, Roland Dreier,
Michael Chan, Jeff Garzik, and Jamal Hadi Salim.
Bug fixes from Thomas Graf, Roland Dreier, Peter Zijlstra,
Joseph Fannin, Scott Wood, Hans J. Koch, and Michael Chan.
[ Ported to current tree and all drivers converted. Integrated
Stephen's follow-on kerneldoc additions, and restored poll_list
handling to the old style to fix mutual exclusion issues. -DaveM ]
Signed-off-by: Stephen Hemminger <shemminger@linux-foundation.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2007-10-04 01:41:36 +02:00
|
|
|
|
2005-04-17 00:20:36 +02:00
|
|
|
unsigned long flags;
|
|
|
|
|
|
2013-10-16 16:37:49 +02:00
|
|
|
struct rw_semaphore vlan_rwsem;
|
2017-07-10 17:45:41 +02:00
|
|
|
struct mutex mcast_mutex;
|
2017-08-17 14:50:50 +02:00
|
|
|
struct mutex sysfs_mutex;
|
2005-04-17 00:20:36 +02:00
|
|
|
|
|
|
|
|
struct rb_root path_tree;
|
|
|
|
|
struct list_head path_list;
|
|
|
|
|
|
IPoIB: Use a private hash table for path lookup in xmit path
Dave Miller <davem@davemloft.net> provided a detailed description of
why the way IPoIB is using neighbours for its own ipoib_neigh struct
is buggy:
Any time an ipoib_neigh is changed, a sequence like the following is made:
spin_lock_irqsave(&priv->lock, flags);
/*
* It's safe to call ipoib_put_ah() inside
* priv->lock here, because we know that
* path->ah will always hold one more reference,
* so ipoib_put_ah() will never do more than
* decrement the ref count.
*/
if (neigh->ah)
ipoib_put_ah(neigh->ah);
list_del(&neigh->list);
ipoib_neigh_free(dev, neigh);
spin_unlock_irqrestore(&priv->lock, flags);
ipoib_path_lookup(skb, n, dev);
This doesn't work, because you're leaving a stale pointer to the freed up
ipoib_neigh in the special neigh->ha pointer cookie. Yes, it even fails
with all the locking done to protect _changes_ to *ipoib_neigh(n), and
with the code in ipoib_neigh_free() that NULLs out the pointer.
The core issue is that read side calls to *to_ipoib_neigh(n) are not
being synchronized at all, they are performed without any locking. So
whether we hold the lock or not when making changes to *ipoib_neigh(n)
you still can have threads see references to freed up ipoib_neigh
objects.
cpu 1 cpu 2
n = *ipoib_neigh()
*ipoib_neigh() = NULL
kfree(n)
n->foo == OOPS
[..]
Perhaps the ipoib code can have a private path database it manages
entirely itself, which holds all the necessary information and is
looked up by some generic key which is available easily at transmit
time and does not involve generic neighbour entries.
See <http://marc.info/?l=linux-rdma&m=132812793105624&w=2> and
<http://marc.info/?l=linux-rdma&w=2&r=1&s=allows+references+to+freed+memory&q=b>
for the full discussion.
This patch aims to solve the race conditions found in the IPoIB driver.
The patch removes the connection between the core networking neighbour
structure and the ipoib_neigh structure. In addition to avoiding the
race described above, it allows us to handle SKBs carrying IP packets
that don't have any associated neighbour.
We add an ipoib_neigh hash table with N buckets where the key is the
destination hardware address. The ipoib_neigh is fetched from the
hash table and instead of the stashed location in the neighbour
structure. The hash table uses both RCU and reference counting to
guarantee that no ipoib_neigh instance is ever deleted while in use.
Fetching the ipoib_neigh structure instance from the hash also makes
the special code in ipoib_start_xmit that handles remote and local
bonding failover redundant.
Aged ipoib_neigh instances are deleted by a garbage collection task
that runs every M seconds and deletes every ipoib_neigh instance that
was idle for at least 2*M seconds. The deletion is safe since the
ipoib_neigh instances are protected using RCU and reference count
mechanisms.
The number of buckets (N) and frequency of running the GC thread (M),
are taken from the exported arb_tbl.
Signed-off-by: Shlomo Pongratz <shlomop@mellanox.com>
Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com>
Signed-off-by: Roland Dreier <roland@purestorage.com>
2012-07-24 19:05:22 +02:00
|
|
|
struct ipoib_neigh_table ntbl;
|
|
|
|
|
|
2005-04-17 00:20:36 +02:00
|
|
|
struct ipoib_mcast *broadcast;
|
|
|
|
|
struct list_head multicast_list;
|
|
|
|
|
struct rb_root multicast_tree;
|
|
|
|
|
|
IB/ipoib: Use dedicated workqueues per interface
During my recent work on the rtnl lock deadlock in the IPoIB driver, I
saw that even once I fixed the apparent races for a single device, as
soon as that device had any children, new races popped up. It turns
out that this is because no matter how well we protect against races
on a single device, the fact that all devices use the same workqueue,
and flush_workqueue() flushes *everything* from that workqueue means
that we would also have to prevent all races between different devices
(for instance, ipoib_mcast_restart_task on interface ib0 can race with
ipoib_mcast_flush_dev on interface ib0.8002, resulting in a deadlock on
the rtnl_lock).
There are several possible solutions to this problem:
Make carrier_on_task and mcast_restart_task try to take the rtnl for
some set period of time and if they fail, then bail. This runs the
real risk of dropping work on the floor, which can end up being its
own separate kind of deadlock.
Set some global flag in the driver that says some device is in the
middle of going down, letting all tasks know to bail. Again, this can
drop work on the floor.
Or the method this patch attempts to use, which is when we bring an
interface up, create a workqueue specifically for that interface, so
that when we take it back down, we are flushing only those tasks
associated with our interface. In addition, keep the global
workqueue, but now limit it to only flush tasks. In this way, the
flush tasks can always flush the device specific work queues without
having deadlock issues.
Signed-off-by: Doug Ledford <dledford@redhat.com>
2015-02-22 01:27:03 +01:00
|
|
|
struct workqueue_struct *wq;
|
2006-11-22 15:57:56 +01:00
|
|
|
struct delayed_work mcast_task;
|
2008-09-16 20:57:45 +02:00
|
|
|
struct work_struct carrier_on_task;
|
2008-07-15 08:48:49 +02:00
|
|
|
struct work_struct flush_light;
|
|
|
|
|
struct work_struct flush_normal;
|
|
|
|
|
struct work_struct flush_heavy;
|
2005-04-17 00:20:36 +02:00
|
|
|
struct work_struct restart_task;
|
2006-11-22 15:57:56 +01:00
|
|
|
struct delayed_work ah_reap_task;
|
IPoIB: Use a private hash table for path lookup in xmit path
Dave Miller <davem@davemloft.net> provided a detailed description of
why the way IPoIB is using neighbours for its own ipoib_neigh struct
is buggy:
Any time an ipoib_neigh is changed, a sequence like the following is made:
spin_lock_irqsave(&priv->lock, flags);
/*
* It's safe to call ipoib_put_ah() inside
* priv->lock here, because we know that
* path->ah will always hold one more reference,
* so ipoib_put_ah() will never do more than
* decrement the ref count.
*/
if (neigh->ah)
ipoib_put_ah(neigh->ah);
list_del(&neigh->list);
ipoib_neigh_free(dev, neigh);
spin_unlock_irqrestore(&priv->lock, flags);
ipoib_path_lookup(skb, n, dev);
This doesn't work, because you're leaving a stale pointer to the freed up
ipoib_neigh in the special neigh->ha pointer cookie. Yes, it even fails
with all the locking done to protect _changes_ to *ipoib_neigh(n), and
with the code in ipoib_neigh_free() that NULLs out the pointer.
The core issue is that read side calls to *to_ipoib_neigh(n) are not
being synchronized at all, they are performed without any locking. So
whether we hold the lock or not when making changes to *ipoib_neigh(n)
you still can have threads see references to freed up ipoib_neigh
objects.
cpu 1 cpu 2
n = *ipoib_neigh()
*ipoib_neigh() = NULL
kfree(n)
n->foo == OOPS
[..]
Perhaps the ipoib code can have a private path database it manages
entirely itself, which holds all the necessary information and is
looked up by some generic key which is available easily at transmit
time and does not involve generic neighbour entries.
See <http://marc.info/?l=linux-rdma&m=132812793105624&w=2> and
<http://marc.info/?l=linux-rdma&w=2&r=1&s=allows+references+to+freed+memory&q=b>
for the full discussion.
This patch aims to solve the race conditions found in the IPoIB driver.
The patch removes the connection between the core networking neighbour
structure and the ipoib_neigh structure. In addition to avoiding the
race described above, it allows us to handle SKBs carrying IP packets
that don't have any associated neighbour.
We add an ipoib_neigh hash table with N buckets where the key is the
destination hardware address. The ipoib_neigh is fetched from the
hash table and instead of the stashed location in the neighbour
structure. The hash table uses both RCU and reference counting to
guarantee that no ipoib_neigh instance is ever deleted while in use.
Fetching the ipoib_neigh structure instance from the hash also makes
the special code in ipoib_start_xmit that handles remote and local
bonding failover redundant.
Aged ipoib_neigh instances are deleted by a garbage collection task
that runs every M seconds and deletes every ipoib_neigh instance that
was idle for at least 2*M seconds. The deletion is safe since the
ipoib_neigh instances are protected using RCU and reference count
mechanisms.
The number of buckets (N) and frequency of running the GC thread (M),
are taken from the exported arb_tbl.
Signed-off-by: Shlomo Pongratz <shlomop@mellanox.com>
Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com>
Signed-off-by: Roland Dreier <roland@purestorage.com>
2012-07-24 19:05:22 +02:00
|
|
|
struct delayed_work neigh_reap_task;
|
2005-04-17 00:20:36 +02:00
|
|
|
struct ib_device *ca;
|
2007-10-24 04:57:54 +02:00
|
|
|
u8 port;
|
|
|
|
|
u16 pkey;
|
|
|
|
|
u16 pkey_index;
|
|
|
|
|
struct ib_pd *pd;
|
2008-04-29 22:46:53 +02:00
|
|
|
struct ib_cq *recv_cq;
|
|
|
|
|
struct ib_cq *send_cq;
|
2007-10-24 04:57:54 +02:00
|
|
|
struct ib_qp *qp;
|
|
|
|
|
u32 qkey;
|
2005-04-17 00:20:36 +02:00
|
|
|
|
|
|
|
|
union ib_gid local_gid;
|
2017-06-08 19:37:45 +02:00
|
|
|
u32 local_lid;
|
2005-04-17 00:20:36 +02:00
|
|
|
|
|
|
|
|
unsigned int admin_mtu;
|
|
|
|
|
unsigned int mcast_mtu;
|
2008-04-23 20:55:45 +02:00
|
|
|
unsigned int max_ib_mtu;
|
2005-04-17 00:20:36 +02:00
|
|
|
|
2005-10-29 00:30:34 +02:00
|
|
|
struct ipoib_rx_buf *rx_ring;
|
2005-04-17 00:20:36 +02:00
|
|
|
|
2005-10-29 00:30:34 +02:00
|
|
|
struct ipoib_tx_buf *tx_ring;
|
2007-10-24 04:57:54 +02:00
|
|
|
unsigned tx_head;
|
|
|
|
|
unsigned tx_tail;
|
2008-01-30 17:30:53 +01:00
|
|
|
struct ib_sge tx_sge[MAX_SKB_FRAGS + 1];
|
2015-10-08 10:16:33 +02:00
|
|
|
struct ib_ud_wr tx_wr;
|
2008-04-29 22:46:53 +02:00
|
|
|
struct ib_wc send_wc[MAX_SEND_CQE];
|
2005-04-17 00:20:36 +02:00
|
|
|
|
2008-04-23 20:55:45 +02:00
|
|
|
struct ib_recv_wr rx_wr;
|
|
|
|
|
struct ib_sge rx_sge[IPOIB_UD_RX_SG];
|
|
|
|
|
|
2005-04-17 00:20:36 +02:00
|
|
|
struct ib_wc ibwc[IPOIB_NUM_WC];
|
|
|
|
|
|
|
|
|
|
struct list_head dead_ahs;
|
|
|
|
|
|
|
|
|
|
struct ib_event_handler event_handler;
|
|
|
|
|
|
|
|
|
|
struct net_device *parent;
|
|
|
|
|
struct list_head child_intfs;
|
|
|
|
|
struct list_head list;
|
2012-09-13 07:56:36 +02:00
|
|
|
int child_type;
|
2005-04-17 00:20:36 +02:00
|
|
|
|
2007-02-05 21:12:23 +01:00
|
|
|
#ifdef CONFIG_INFINIBAND_IPOIB_CM
|
|
|
|
|
struct ipoib_cm_dev_priv cm;
|
|
|
|
|
#endif
|
|
|
|
|
|
2005-04-17 00:20:36 +02:00
|
|
|
#ifdef CONFIG_INFINIBAND_IPOIB_DEBUG
|
|
|
|
|
struct list_head fs_list;
|
|
|
|
|
struct dentry *mcg_dentry;
|
2005-11-07 19:33:11 +01:00
|
|
|
struct dentry *path_dentry;
|
2005-04-17 00:20:36 +02:00
|
|
|
#endif
|
2016-02-23 09:25:25 +01:00
|
|
|
u64 hca_caps;
|
2008-04-17 06:09:33 +02:00
|
|
|
struct ipoib_ethtool_st ethtool;
|
2016-03-02 13:44:28 +01:00
|
|
|
unsigned max_send_sge;
|
2016-05-25 21:02:07 +02:00
|
|
|
bool sm_fullmember_sendonly_support;
|
2017-04-10 10:22:30 +02:00
|
|
|
const struct net_device_ops *rn_ops;
|
2005-04-17 00:20:36 +02:00
|
|
|
};
|
|
|
|
|
|
|
|
|
|
struct ipoib_ah {
|
|
|
|
|
struct net_device *dev;
|
2007-10-24 04:57:54 +02:00
|
|
|
struct ib_ah *ah;
|
2005-04-17 00:20:36 +02:00
|
|
|
struct list_head list;
|
2007-10-24 04:57:54 +02:00
|
|
|
struct kref ref;
|
|
|
|
|
unsigned last_send;
|
2005-04-17 00:20:36 +02:00
|
|
|
};
|
|
|
|
|
|
|
|
|
|
struct ipoib_path {
|
|
|
|
|
struct net_device *dev;
|
2017-04-28 01:05:58 +02:00
|
|
|
struct sa_path_rec pathrec;
|
2005-04-17 00:20:36 +02:00
|
|
|
struct ipoib_ah *ah;
|
|
|
|
|
struct sk_buff_head queue;
|
|
|
|
|
|
|
|
|
|
struct list_head neigh_list;
|
|
|
|
|
|
2007-10-24 04:57:54 +02:00
|
|
|
int query_id;
|
2005-04-17 00:20:36 +02:00
|
|
|
struct ib_sa_query *query;
|
|
|
|
|
struct completion done;
|
|
|
|
|
|
2007-10-24 04:57:54 +02:00
|
|
|
struct rb_node rb_node;
|
2005-04-17 00:20:36 +02:00
|
|
|
struct list_head list;
|
2008-07-15 08:48:49 +02:00
|
|
|
int valid;
|
2005-04-17 00:20:36 +02:00
|
|
|
};
|
|
|
|
|
|
|
|
|
|
struct ipoib_neigh {
|
|
|
|
|
struct ipoib_ah *ah;
|
2007-02-05 21:12:23 +01:00
|
|
|
#ifdef CONFIG_INFINIBAND_IPOIB_CM
|
|
|
|
|
struct ipoib_cm_tx *cm;
|
|
|
|
|
#endif
|
IPoIB: Use a private hash table for path lookup in xmit path
Dave Miller <davem@davemloft.net> provided a detailed description of
why the way IPoIB is using neighbours for its own ipoib_neigh struct
is buggy:
Any time an ipoib_neigh is changed, a sequence like the following is made:
spin_lock_irqsave(&priv->lock, flags);
/*
* It's safe to call ipoib_put_ah() inside
* priv->lock here, because we know that
* path->ah will always hold one more reference,
* so ipoib_put_ah() will never do more than
* decrement the ref count.
*/
if (neigh->ah)
ipoib_put_ah(neigh->ah);
list_del(&neigh->list);
ipoib_neigh_free(dev, neigh);
spin_unlock_irqrestore(&priv->lock, flags);
ipoib_path_lookup(skb, n, dev);
This doesn't work, because you're leaving a stale pointer to the freed up
ipoib_neigh in the special neigh->ha pointer cookie. Yes, it even fails
with all the locking done to protect _changes_ to *ipoib_neigh(n), and
with the code in ipoib_neigh_free() that NULLs out the pointer.
The core issue is that read side calls to *to_ipoib_neigh(n) are not
being synchronized at all, they are performed without any locking. So
whether we hold the lock or not when making changes to *ipoib_neigh(n)
you still can have threads see references to freed up ipoib_neigh
objects.
cpu 1 cpu 2
n = *ipoib_neigh()
*ipoib_neigh() = NULL
kfree(n)
n->foo == OOPS
[..]
Perhaps the ipoib code can have a private path database it manages
entirely itself, which holds all the necessary information and is
looked up by some generic key which is available easily at transmit
time and does not involve generic neighbour entries.
See <http://marc.info/?l=linux-rdma&m=132812793105624&w=2> and
<http://marc.info/?l=linux-rdma&w=2&r=1&s=allows+references+to+freed+memory&q=b>
for the full discussion.
This patch aims to solve the race conditions found in the IPoIB driver.
The patch removes the connection between the core networking neighbour
structure and the ipoib_neigh structure. In addition to avoiding the
race described above, it allows us to handle SKBs carrying IP packets
that don't have any associated neighbour.
We add an ipoib_neigh hash table with N buckets where the key is the
destination hardware address. The ipoib_neigh is fetched from the
hash table and instead of the stashed location in the neighbour
structure. The hash table uses both RCU and reference counting to
guarantee that no ipoib_neigh instance is ever deleted while in use.
Fetching the ipoib_neigh structure instance from the hash also makes
the special code in ipoib_start_xmit that handles remote and local
bonding failover redundant.
Aged ipoib_neigh instances are deleted by a garbage collection task
that runs every M seconds and deletes every ipoib_neigh instance that
was idle for at least 2*M seconds. The deletion is safe since the
ipoib_neigh instances are protected using RCU and reference count
mechanisms.
The number of buckets (N) and frequency of running the GC thread (M),
are taken from the exported arb_tbl.
Signed-off-by: Shlomo Pongratz <shlomop@mellanox.com>
Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com>
Signed-off-by: Roland Dreier <roland@purestorage.com>
2012-07-24 19:05:22 +02:00
|
|
|
u8 daddr[INFINIBAND_ALEN];
|
2005-04-17 00:20:36 +02:00
|
|
|
struct sk_buff_head queue;
|
|
|
|
|
|
2007-10-10 04:43:36 +02:00
|
|
|
struct net_device *dev;
|
2005-04-17 00:20:36 +02:00
|
|
|
|
|
|
|
|
struct list_head list;
|
IPoIB: Use a private hash table for path lookup in xmit path
Dave Miller <davem@davemloft.net> provided a detailed description of
why the way IPoIB is using neighbours for its own ipoib_neigh struct
is buggy:
Any time an ipoib_neigh is changed, a sequence like the following is made:
spin_lock_irqsave(&priv->lock, flags);
/*
* It's safe to call ipoib_put_ah() inside
* priv->lock here, because we know that
* path->ah will always hold one more reference,
* so ipoib_put_ah() will never do more than
* decrement the ref count.
*/
if (neigh->ah)
ipoib_put_ah(neigh->ah);
list_del(&neigh->list);
ipoib_neigh_free(dev, neigh);
spin_unlock_irqrestore(&priv->lock, flags);
ipoib_path_lookup(skb, n, dev);
This doesn't work, because you're leaving a stale pointer to the freed up
ipoib_neigh in the special neigh->ha pointer cookie. Yes, it even fails
with all the locking done to protect _changes_ to *ipoib_neigh(n), and
with the code in ipoib_neigh_free() that NULLs out the pointer.
The core issue is that read side calls to *to_ipoib_neigh(n) are not
being synchronized at all, they are performed without any locking. So
whether we hold the lock or not when making changes to *ipoib_neigh(n)
you still can have threads see references to freed up ipoib_neigh
objects.
cpu 1 cpu 2
n = *ipoib_neigh()
*ipoib_neigh() = NULL
kfree(n)
n->foo == OOPS
[..]
Perhaps the ipoib code can have a private path database it manages
entirely itself, which holds all the necessary information and is
looked up by some generic key which is available easily at transmit
time and does not involve generic neighbour entries.
See <http://marc.info/?l=linux-rdma&m=132812793105624&w=2> and
<http://marc.info/?l=linux-rdma&w=2&r=1&s=allows+references+to+freed+memory&q=b>
for the full discussion.
This patch aims to solve the race conditions found in the IPoIB driver.
The patch removes the connection between the core networking neighbour
structure and the ipoib_neigh structure. In addition to avoiding the
race described above, it allows us to handle SKBs carrying IP packets
that don't have any associated neighbour.
We add an ipoib_neigh hash table with N buckets where the key is the
destination hardware address. The ipoib_neigh is fetched from the
hash table and instead of the stashed location in the neighbour
structure. The hash table uses both RCU and reference counting to
guarantee that no ipoib_neigh instance is ever deleted while in use.
Fetching the ipoib_neigh structure instance from the hash also makes
the special code in ipoib_start_xmit that handles remote and local
bonding failover redundant.
Aged ipoib_neigh instances are deleted by a garbage collection task
that runs every M seconds and deletes every ipoib_neigh instance that
was idle for at least 2*M seconds. The deletion is safe since the
ipoib_neigh instances are protected using RCU and reference count
mechanisms.
The number of buckets (N) and frequency of running the GC thread (M),
are taken from the exported arb_tbl.
Signed-off-by: Shlomo Pongratz <shlomop@mellanox.com>
Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com>
Signed-off-by: Roland Dreier <roland@purestorage.com>
2012-07-24 19:05:22 +02:00
|
|
|
struct ipoib_neigh __rcu *hnext;
|
|
|
|
|
struct rcu_head rcu;
|
|
|
|
|
atomic_t refcnt;
|
|
|
|
|
unsigned long alive;
|
2005-04-17 00:20:36 +02:00
|
|
|
};
|
|
|
|
|
|
2008-04-23 20:55:45 +02:00
|
|
|
#define IPOIB_UD_MTU(ib_mtu) (ib_mtu - IPOIB_ENCAP_LEN)
|
|
|
|
|
#define IPOIB_UD_BUF_SIZE(ib_mtu) (ib_mtu + IB_GRH_BYTES)
|
|
|
|
|
|
IPoIB: Use a private hash table for path lookup in xmit path
Dave Miller <davem@davemloft.net> provided a detailed description of
why the way IPoIB is using neighbours for its own ipoib_neigh struct
is buggy:
Any time an ipoib_neigh is changed, a sequence like the following is made:
spin_lock_irqsave(&priv->lock, flags);
/*
* It's safe to call ipoib_put_ah() inside
* priv->lock here, because we know that
* path->ah will always hold one more reference,
* so ipoib_put_ah() will never do more than
* decrement the ref count.
*/
if (neigh->ah)
ipoib_put_ah(neigh->ah);
list_del(&neigh->list);
ipoib_neigh_free(dev, neigh);
spin_unlock_irqrestore(&priv->lock, flags);
ipoib_path_lookup(skb, n, dev);
This doesn't work, because you're leaving a stale pointer to the freed up
ipoib_neigh in the special neigh->ha pointer cookie. Yes, it even fails
with all the locking done to protect _changes_ to *ipoib_neigh(n), and
with the code in ipoib_neigh_free() that NULLs out the pointer.
The core issue is that read side calls to *to_ipoib_neigh(n) are not
being synchronized at all, they are performed without any locking. So
whether we hold the lock or not when making changes to *ipoib_neigh(n)
you still can have threads see references to freed up ipoib_neigh
objects.
cpu 1 cpu 2
n = *ipoib_neigh()
*ipoib_neigh() = NULL
kfree(n)
n->foo == OOPS
[..]
Perhaps the ipoib code can have a private path database it manages
entirely itself, which holds all the necessary information and is
looked up by some generic key which is available easily at transmit
time and does not involve generic neighbour entries.
See <http://marc.info/?l=linux-rdma&m=132812793105624&w=2> and
<http://marc.info/?l=linux-rdma&w=2&r=1&s=allows+references+to+freed+memory&q=b>
for the full discussion.
This patch aims to solve the race conditions found in the IPoIB driver.
The patch removes the connection between the core networking neighbour
structure and the ipoib_neigh structure. In addition to avoiding the
race described above, it allows us to handle SKBs carrying IP packets
that don't have any associated neighbour.
We add an ipoib_neigh hash table with N buckets where the key is the
destination hardware address. The ipoib_neigh is fetched from the
hash table and instead of the stashed location in the neighbour
structure. The hash table uses both RCU and reference counting to
guarantee that no ipoib_neigh instance is ever deleted while in use.
Fetching the ipoib_neigh structure instance from the hash also makes
the special code in ipoib_start_xmit that handles remote and local
bonding failover redundant.
Aged ipoib_neigh instances are deleted by a garbage collection task
that runs every M seconds and deletes every ipoib_neigh instance that
was idle for at least 2*M seconds. The deletion is safe since the
ipoib_neigh instances are protected using RCU and reference count
mechanisms.
The number of buckets (N) and frequency of running the GC thread (M),
are taken from the exported arb_tbl.
Signed-off-by: Shlomo Pongratz <shlomop@mellanox.com>
Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com>
Signed-off-by: Roland Dreier <roland@purestorage.com>
2012-07-24 19:05:22 +02:00
|
|
|
void ipoib_neigh_dtor(struct ipoib_neigh *neigh);
|
|
|
|
|
static inline void ipoib_neigh_put(struct ipoib_neigh *neigh)
|
2005-04-17 00:20:36 +02:00
|
|
|
{
|
IPoIB: Use a private hash table for path lookup in xmit path
Dave Miller <davem@davemloft.net> provided a detailed description of
why the way IPoIB is using neighbours for its own ipoib_neigh struct
is buggy:
Any time an ipoib_neigh is changed, a sequence like the following is made:
spin_lock_irqsave(&priv->lock, flags);
/*
* It's safe to call ipoib_put_ah() inside
* priv->lock here, because we know that
* path->ah will always hold one more reference,
* so ipoib_put_ah() will never do more than
* decrement the ref count.
*/
if (neigh->ah)
ipoib_put_ah(neigh->ah);
list_del(&neigh->list);
ipoib_neigh_free(dev, neigh);
spin_unlock_irqrestore(&priv->lock, flags);
ipoib_path_lookup(skb, n, dev);
This doesn't work, because you're leaving a stale pointer to the freed up
ipoib_neigh in the special neigh->ha pointer cookie. Yes, it even fails
with all the locking done to protect _changes_ to *ipoib_neigh(n), and
with the code in ipoib_neigh_free() that NULLs out the pointer.
The core issue is that read side calls to *to_ipoib_neigh(n) are not
being synchronized at all, they are performed without any locking. So
whether we hold the lock or not when making changes to *ipoib_neigh(n)
you still can have threads see references to freed up ipoib_neigh
objects.
cpu 1 cpu 2
n = *ipoib_neigh()
*ipoib_neigh() = NULL
kfree(n)
n->foo == OOPS
[..]
Perhaps the ipoib code can have a private path database it manages
entirely itself, which holds all the necessary information and is
looked up by some generic key which is available easily at transmit
time and does not involve generic neighbour entries.
See <http://marc.info/?l=linux-rdma&m=132812793105624&w=2> and
<http://marc.info/?l=linux-rdma&w=2&r=1&s=allows+references+to+freed+memory&q=b>
for the full discussion.
This patch aims to solve the race conditions found in the IPoIB driver.
The patch removes the connection between the core networking neighbour
structure and the ipoib_neigh structure. In addition to avoiding the
race described above, it allows us to handle SKBs carrying IP packets
that don't have any associated neighbour.
We add an ipoib_neigh hash table with N buckets where the key is the
destination hardware address. The ipoib_neigh is fetched from the
hash table and instead of the stashed location in the neighbour
structure. The hash table uses both RCU and reference counting to
guarantee that no ipoib_neigh instance is ever deleted while in use.
Fetching the ipoib_neigh structure instance from the hash also makes
the special code in ipoib_start_xmit that handles remote and local
bonding failover redundant.
Aged ipoib_neigh instances are deleted by a garbage collection task
that runs every M seconds and deletes every ipoib_neigh instance that
was idle for at least 2*M seconds. The deletion is safe since the
ipoib_neigh instances are protected using RCU and reference count
mechanisms.
The number of buckets (N) and frequency of running the GC thread (M),
are taken from the exported arb_tbl.
Signed-off-by: Shlomo Pongratz <shlomop@mellanox.com>
Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com>
Signed-off-by: Roland Dreier <roland@purestorage.com>
2012-07-24 19:05:22 +02:00
|
|
|
if (atomic_dec_and_test(&neigh->refcnt))
|
|
|
|
|
ipoib_neigh_dtor(neigh);
|
2005-04-17 00:20:36 +02:00
|
|
|
}
|
IPoIB: Use a private hash table for path lookup in xmit path
Dave Miller <davem@davemloft.net> provided a detailed description of
why the way IPoIB is using neighbours for its own ipoib_neigh struct
is buggy:
Any time an ipoib_neigh is changed, a sequence like the following is made:
spin_lock_irqsave(&priv->lock, flags);
/*
* It's safe to call ipoib_put_ah() inside
* priv->lock here, because we know that
* path->ah will always hold one more reference,
* so ipoib_put_ah() will never do more than
* decrement the ref count.
*/
if (neigh->ah)
ipoib_put_ah(neigh->ah);
list_del(&neigh->list);
ipoib_neigh_free(dev, neigh);
spin_unlock_irqrestore(&priv->lock, flags);
ipoib_path_lookup(skb, n, dev);
This doesn't work, because you're leaving a stale pointer to the freed up
ipoib_neigh in the special neigh->ha pointer cookie. Yes, it even fails
with all the locking done to protect _changes_ to *ipoib_neigh(n), and
with the code in ipoib_neigh_free() that NULLs out the pointer.
The core issue is that read side calls to *to_ipoib_neigh(n) are not
being synchronized at all, they are performed without any locking. So
whether we hold the lock or not when making changes to *ipoib_neigh(n)
you still can have threads see references to freed up ipoib_neigh
objects.
cpu 1 cpu 2
n = *ipoib_neigh()
*ipoib_neigh() = NULL
kfree(n)
n->foo == OOPS
[..]
Perhaps the ipoib code can have a private path database it manages
entirely itself, which holds all the necessary information and is
looked up by some generic key which is available easily at transmit
time and does not involve generic neighbour entries.
See <http://marc.info/?l=linux-rdma&m=132812793105624&w=2> and
<http://marc.info/?l=linux-rdma&w=2&r=1&s=allows+references+to+freed+memory&q=b>
for the full discussion.
This patch aims to solve the race conditions found in the IPoIB driver.
The patch removes the connection between the core networking neighbour
structure and the ipoib_neigh structure. In addition to avoiding the
race described above, it allows us to handle SKBs carrying IP packets
that don't have any associated neighbour.
We add an ipoib_neigh hash table with N buckets where the key is the
destination hardware address. The ipoib_neigh is fetched from the
hash table and instead of the stashed location in the neighbour
structure. The hash table uses both RCU and reference counting to
guarantee that no ipoib_neigh instance is ever deleted while in use.
Fetching the ipoib_neigh structure instance from the hash also makes
the special code in ipoib_start_xmit that handles remote and local
bonding failover redundant.
Aged ipoib_neigh instances are deleted by a garbage collection task
that runs every M seconds and deletes every ipoib_neigh instance that
was idle for at least 2*M seconds. The deletion is safe since the
ipoib_neigh instances are protected using RCU and reference count
mechanisms.
The number of buckets (N) and frequency of running the GC thread (M),
are taken from the exported arb_tbl.
Signed-off-by: Shlomo Pongratz <shlomop@mellanox.com>
Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com>
Signed-off-by: Roland Dreier <roland@purestorage.com>
2012-07-24 19:05:22 +02:00
|
|
|
struct ipoib_neigh *ipoib_neigh_get(struct net_device *dev, u8 *daddr);
|
|
|
|
|
struct ipoib_neigh *ipoib_neigh_alloc(u8 *daddr,
|
2007-10-10 04:43:36 +02:00
|
|
|
struct net_device *dev);
|
IPoIB: Use a private hash table for path lookup in xmit path
Dave Miller <davem@davemloft.net> provided a detailed description of
why the way IPoIB is using neighbours for its own ipoib_neigh struct
is buggy:
Any time an ipoib_neigh is changed, a sequence like the following is made:
spin_lock_irqsave(&priv->lock, flags);
/*
* It's safe to call ipoib_put_ah() inside
* priv->lock here, because we know that
* path->ah will always hold one more reference,
* so ipoib_put_ah() will never do more than
* decrement the ref count.
*/
if (neigh->ah)
ipoib_put_ah(neigh->ah);
list_del(&neigh->list);
ipoib_neigh_free(dev, neigh);
spin_unlock_irqrestore(&priv->lock, flags);
ipoib_path_lookup(skb, n, dev);
This doesn't work, because you're leaving a stale pointer to the freed up
ipoib_neigh in the special neigh->ha pointer cookie. Yes, it even fails
with all the locking done to protect _changes_ to *ipoib_neigh(n), and
with the code in ipoib_neigh_free() that NULLs out the pointer.
The core issue is that read side calls to *to_ipoib_neigh(n) are not
being synchronized at all, they are performed without any locking. So
whether we hold the lock or not when making changes to *ipoib_neigh(n)
you still can have threads see references to freed up ipoib_neigh
objects.
cpu 1 cpu 2
n = *ipoib_neigh()
*ipoib_neigh() = NULL
kfree(n)
n->foo == OOPS
[..]
Perhaps the ipoib code can have a private path database it manages
entirely itself, which holds all the necessary information and is
looked up by some generic key which is available easily at transmit
time and does not involve generic neighbour entries.
See <http://marc.info/?l=linux-rdma&m=132812793105624&w=2> and
<http://marc.info/?l=linux-rdma&w=2&r=1&s=allows+references+to+freed+memory&q=b>
for the full discussion.
This patch aims to solve the race conditions found in the IPoIB driver.
The patch removes the connection between the core networking neighbour
structure and the ipoib_neigh structure. In addition to avoiding the
race described above, it allows us to handle SKBs carrying IP packets
that don't have any associated neighbour.
We add an ipoib_neigh hash table with N buckets where the key is the
destination hardware address. The ipoib_neigh is fetched from the
hash table and instead of the stashed location in the neighbour
structure. The hash table uses both RCU and reference counting to
guarantee that no ipoib_neigh instance is ever deleted while in use.
Fetching the ipoib_neigh structure instance from the hash also makes
the special code in ipoib_start_xmit that handles remote and local
bonding failover redundant.
Aged ipoib_neigh instances are deleted by a garbage collection task
that runs every M seconds and deletes every ipoib_neigh instance that
was idle for at least 2*M seconds. The deletion is safe since the
ipoib_neigh instances are protected using RCU and reference count
mechanisms.
The number of buckets (N) and frequency of running the GC thread (M),
are taken from the exported arb_tbl.
Signed-off-by: Shlomo Pongratz <shlomop@mellanox.com>
Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com>
Signed-off-by: Roland Dreier <roland@purestorage.com>
2012-07-24 19:05:22 +02:00
|
|
|
void ipoib_neigh_free(struct ipoib_neigh *neigh);
|
|
|
|
|
void ipoib_del_neighs_by_gid(struct net_device *dev, u8 *gid);
|
2006-04-04 18:59:40 +02:00
|
|
|
|
2005-04-17 00:20:36 +02:00
|
|
|
extern struct workqueue_struct *ipoib_workqueue;
|
|
|
|
|
|
|
|
|
|
/* functions */
|
|
|
|
|
|
2017-10-19 06:56:43 +02:00
|
|
|
int ipoib_rx_poll(struct napi_struct *napi, int budget);
|
|
|
|
|
int ipoib_tx_poll(struct napi_struct *napi, int budget);
|
|
|
|
|
void ipoib_ib_rx_completion(struct ib_cq *cq, void *ctx_ptr);
|
|
|
|
|
void ipoib_ib_tx_completion(struct ib_cq *cq, void *ctx_ptr);
|
2005-04-17 00:20:36 +02:00
|
|
|
|
|
|
|
|
struct ipoib_ah *ipoib_create_ah(struct net_device *dev,
|
2017-04-29 20:41:18 +02:00
|
|
|
struct ib_pd *pd, struct rdma_ah_attr *attr);
|
2005-04-17 00:20:36 +02:00
|
|
|
void ipoib_free_ah(struct kref *kref);
|
|
|
|
|
static inline void ipoib_put_ah(struct ipoib_ah *ah)
|
|
|
|
|
{
|
|
|
|
|
kref_put(&ah->ref, ipoib_free_ah);
|
|
|
|
|
}
|
2005-11-03 05:51:01 +01:00
|
|
|
int ipoib_open(struct net_device *dev);
|
2005-04-17 00:20:36 +02:00
|
|
|
int ipoib_add_pkey_attr(struct net_device *dev);
|
IPoIB: Allow setting policy to ignore multicast groups
The kernel IB stack allows (through the RDMA CM) userspace
applications to join and use multicast groups from the IPoIB MGID
range. This allows multicast traffic to be handled directly from
userspace QPs, without going through the kernel stack, which gives
better performance for some applications.
However, to fully interoperate with IP multicast, such userspace
applications need to participate in IGMP reports and queries, or else
routers may not forward the multicast traffic to the system where the
application is running. The simplest way to do this is to share the
kernel IGMP implementation by using the IP_ADD_MEMBERSHIP option to
join multicast groups that are being handled directly in userspace.
However, in such cases, the actual multicast traffic should not also
be handled by the IPoIB interface, because that would burn resources
handling multicast packets that will just be discarded in the kernel.
To handle this, this patch adds lookup on the database used for IB
multicast group reference counting when IPoIB is joining multicast
groups, and if a multicast group is already handled by user space,
then the IPoIB kernel driver ignores the group. This is controlled by
a per-interface policy flag. When the flag is set, IPoIB will not
join and attach its QP to a multicast group which already has an entry
in the database; when the flag is cleared, IPoIB will behave as before
this change.
For each IPoIB interface, the /sys/class/net/$intf/umcast attribute
controls the policy flag. The default value is off/0.
Signed-off-by: Or Gerlitz <ogerlitz@voltaire.com>
Signed-off-by: Roland Dreier <rolandd@cisco.com>
2007-10-08 10:13:00 +02:00
|
|
|
int ipoib_add_umcast_attr(struct net_device *dev);
|
2005-04-17 00:20:36 +02:00
|
|
|
|
2017-04-10 10:22:30 +02:00
|
|
|
int ipoib_send(struct net_device *dev, struct sk_buff *skb,
|
|
|
|
|
struct ib_ah *address, u32 dqpn);
|
2006-11-22 15:57:56 +01:00
|
|
|
void ipoib_reap_ah(struct work_struct *work);
|
2005-04-17 00:20:36 +02:00
|
|
|
|
2016-08-28 09:58:31 +02:00
|
|
|
struct ipoib_path *__path_find(struct net_device *dev, void *gid);
|
2008-07-15 08:48:49 +02:00
|
|
|
void ipoib_mark_paths_invalid(struct net_device *dev);
|
2005-04-17 00:20:36 +02:00
|
|
|
void ipoib_flush_paths(struct net_device *dev);
|
2017-04-10 10:22:30 +02:00
|
|
|
struct ipoib_dev_priv *ipoib_intf_alloc(struct ib_device *hca, u8 port,
|
|
|
|
|
const char *format);
|
2017-10-05 02:45:54 +02:00
|
|
|
void ipoib_ib_tx_timer_func(struct timer_list *t);
|
2008-07-15 08:48:49 +02:00
|
|
|
void ipoib_ib_dev_flush_light(struct work_struct *work);
|
|
|
|
|
void ipoib_ib_dev_flush_normal(struct work_struct *work);
|
|
|
|
|
void ipoib_ib_dev_flush_heavy(struct work_struct *work);
|
2007-05-19 17:51:54 +02:00
|
|
|
void ipoib_pkey_event(struct work_struct *work);
|
2005-04-17 00:20:36 +02:00
|
|
|
void ipoib_ib_dev_cleanup(struct net_device *dev);
|
|
|
|
|
|
2017-04-10 10:22:30 +02:00
|
|
|
int ipoib_ib_dev_open_default(struct net_device *dev);
|
2015-02-22 01:27:04 +01:00
|
|
|
int ipoib_ib_dev_open(struct net_device *dev);
|
2017-04-10 10:22:30 +02:00
|
|
|
int ipoib_ib_dev_stop(struct net_device *dev);
|
2017-01-19 05:16:06 +01:00
|
|
|
void ipoib_ib_dev_up(struct net_device *dev);
|
2017-01-12 08:39:01 +01:00
|
|
|
void ipoib_ib_dev_down(struct net_device *dev);
|
2017-04-10 10:22:27 +02:00
|
|
|
int ipoib_ib_dev_stop_default(struct net_device *dev);
|
2014-07-08 11:45:11 +02:00
|
|
|
void ipoib_pkey_dev_check_presence(struct net_device *dev);
|
2005-04-17 00:20:36 +02:00
|
|
|
|
|
|
|
|
int ipoib_dev_init(struct net_device *dev, struct ib_device *ca, int port);
|
|
|
|
|
void ipoib_dev_cleanup(struct net_device *dev);
|
|
|
|
|
|
2006-11-22 15:57:56 +01:00
|
|
|
void ipoib_mcast_join_task(struct work_struct *work);
|
2008-09-16 20:57:45 +02:00
|
|
|
void ipoib_mcast_carrier_on_task(struct work_struct *work);
|
IPoIB: Use a private hash table for path lookup in xmit path
Dave Miller <davem@davemloft.net> provided a detailed description of
why the way IPoIB is using neighbours for its own ipoib_neigh struct
is buggy:
Any time an ipoib_neigh is changed, a sequence like the following is made:
spin_lock_irqsave(&priv->lock, flags);
/*
* It's safe to call ipoib_put_ah() inside
* priv->lock here, because we know that
* path->ah will always hold one more reference,
* so ipoib_put_ah() will never do more than
* decrement the ref count.
*/
if (neigh->ah)
ipoib_put_ah(neigh->ah);
list_del(&neigh->list);
ipoib_neigh_free(dev, neigh);
spin_unlock_irqrestore(&priv->lock, flags);
ipoib_path_lookup(skb, n, dev);
This doesn't work, because you're leaving a stale pointer to the freed up
ipoib_neigh in the special neigh->ha pointer cookie. Yes, it even fails
with all the locking done to protect _changes_ to *ipoib_neigh(n), and
with the code in ipoib_neigh_free() that NULLs out the pointer.
The core issue is that read side calls to *to_ipoib_neigh(n) are not
being synchronized at all, they are performed without any locking. So
whether we hold the lock or not when making changes to *ipoib_neigh(n)
you still can have threads see references to freed up ipoib_neigh
objects.
cpu 1 cpu 2
n = *ipoib_neigh()
*ipoib_neigh() = NULL
kfree(n)
n->foo == OOPS
[..]
Perhaps the ipoib code can have a private path database it manages
entirely itself, which holds all the necessary information and is
looked up by some generic key which is available easily at transmit
time and does not involve generic neighbour entries.
See <http://marc.info/?l=linux-rdma&m=132812793105624&w=2> and
<http://marc.info/?l=linux-rdma&w=2&r=1&s=allows+references+to+freed+memory&q=b>
for the full discussion.
This patch aims to solve the race conditions found in the IPoIB driver.
The patch removes the connection between the core networking neighbour
structure and the ipoib_neigh structure. In addition to avoiding the
race described above, it allows us to handle SKBs carrying IP packets
that don't have any associated neighbour.
We add an ipoib_neigh hash table with N buckets where the key is the
destination hardware address. The ipoib_neigh is fetched from the
hash table and instead of the stashed location in the neighbour
structure. The hash table uses both RCU and reference counting to
guarantee that no ipoib_neigh instance is ever deleted while in use.
Fetching the ipoib_neigh structure instance from the hash also makes
the special code in ipoib_start_xmit that handles remote and local
bonding failover redundant.
Aged ipoib_neigh instances are deleted by a garbage collection task
that runs every M seconds and deletes every ipoib_neigh instance that
was idle for at least 2*M seconds. The deletion is safe since the
ipoib_neigh instances are protected using RCU and reference count
mechanisms.
The number of buckets (N) and frequency of running the GC thread (M),
are taken from the exported arb_tbl.
Signed-off-by: Shlomo Pongratz <shlomop@mellanox.com>
Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com>
Signed-off-by: Roland Dreier <roland@purestorage.com>
2012-07-24 19:05:22 +02:00
|
|
|
void ipoib_mcast_send(struct net_device *dev, u8 *daddr, struct sk_buff *skb);
|
2005-04-17 00:20:36 +02:00
|
|
|
|
2006-11-22 15:57:56 +01:00
|
|
|
void ipoib_mcast_restart_task(struct work_struct *work);
|
2017-01-19 05:16:06 +01:00
|
|
|
void ipoib_mcast_start_thread(struct net_device *dev);
|
2015-02-22 01:27:04 +01:00
|
|
|
int ipoib_mcast_stop_thread(struct net_device *dev);
|
2005-04-17 00:20:36 +02:00
|
|
|
|
|
|
|
|
void ipoib_mcast_dev_down(struct net_device *dev);
|
|
|
|
|
void ipoib_mcast_dev_flush(struct net_device *dev);
|
|
|
|
|
|
2015-07-12 10:24:09 +02:00
|
|
|
int ipoib_dma_map_tx(struct ib_device *ca, struct ipoib_tx_buf *tx_req);
|
|
|
|
|
void ipoib_dma_unmap_tx(struct ipoib_dev_priv *priv,
|
|
|
|
|
struct ipoib_tx_buf *tx_req);
|
|
|
|
|
|
|
|
|
|
static inline void ipoib_build_sge(struct ipoib_dev_priv *priv,
|
|
|
|
|
struct ipoib_tx_buf *tx_req)
|
|
|
|
|
{
|
|
|
|
|
int i, off;
|
|
|
|
|
struct sk_buff *skb = tx_req->skb;
|
|
|
|
|
skb_frag_t *frags = skb_shinfo(skb)->frags;
|
|
|
|
|
int nr_frags = skb_shinfo(skb)->nr_frags;
|
|
|
|
|
u64 *mapping = tx_req->mapping;
|
|
|
|
|
|
|
|
|
|
if (skb_headlen(skb)) {
|
|
|
|
|
priv->tx_sge[0].addr = mapping[0];
|
|
|
|
|
priv->tx_sge[0].length = skb_headlen(skb);
|
|
|
|
|
off = 1;
|
|
|
|
|
} else
|
|
|
|
|
off = 0;
|
|
|
|
|
|
|
|
|
|
for (i = 0; i < nr_frags; ++i) {
|
|
|
|
|
priv->tx_sge[i + off].addr = mapping[i + off];
|
|
|
|
|
priv->tx_sge[i + off].length = skb_frag_size(&frags[i]);
|
|
|
|
|
}
|
2015-10-08 10:16:33 +02:00
|
|
|
priv->tx_wr.wr.num_sge = nr_frags + off;
|
2015-07-12 10:24:09 +02:00
|
|
|
}
|
|
|
|
|
|
2005-11-03 05:51:01 +01:00
|
|
|
#ifdef CONFIG_INFINIBAND_IPOIB_DEBUG
|
2005-04-17 00:20:36 +02:00
|
|
|
struct ipoib_mcast_iter *ipoib_mcast_iter_init(struct net_device *dev);
|
|
|
|
|
int ipoib_mcast_iter_next(struct ipoib_mcast_iter *iter);
|
|
|
|
|
void ipoib_mcast_iter_read(struct ipoib_mcast_iter *iter,
|
|
|
|
|
union ib_gid *gid,
|
|
|
|
|
unsigned long *created,
|
|
|
|
|
unsigned int *queuelen,
|
|
|
|
|
unsigned int *complete,
|
|
|
|
|
unsigned int *send_only);
|
2005-11-07 19:33:11 +01:00
|
|
|
|
|
|
|
|
struct ipoib_path_iter *ipoib_path_iter_init(struct net_device *dev);
|
|
|
|
|
int ipoib_path_iter_next(struct ipoib_path_iter *iter);
|
|
|
|
|
void ipoib_path_iter_read(struct ipoib_path_iter *iter,
|
|
|
|
|
struct ipoib_path *path);
|
2005-11-03 05:51:01 +01:00
|
|
|
#endif
|
2005-04-17 00:20:36 +02:00
|
|
|
|
2017-04-10 10:22:30 +02:00
|
|
|
int ipoib_mcast_attach(struct net_device *dev, struct ib_device *hca,
|
|
|
|
|
union ib_gid *mgid, u16 mlid, int set_qkey, u32 qkey);
|
|
|
|
|
int ipoib_mcast_detach(struct net_device *dev, struct ib_device *hca,
|
|
|
|
|
union ib_gid *mgid, u16 mlid);
|
2016-01-07 08:28:08 +01:00
|
|
|
void ipoib_mcast_remove_list(struct list_head *remove_list);
|
2015-12-21 15:42:54 +01:00
|
|
|
void ipoib_check_and_add_mcast_sendonly(struct ipoib_dev_priv *priv, u8 *mgid,
|
|
|
|
|
struct list_head *remove_list);
|
2005-04-17 00:20:36 +02:00
|
|
|
|
2005-10-11 20:08:24 +02:00
|
|
|
int ipoib_init_qp(struct net_device *dev);
|
2005-04-17 00:20:36 +02:00
|
|
|
int ipoib_transport_dev_init(struct net_device *dev, struct ib_device *ca);
|
|
|
|
|
void ipoib_transport_dev_cleanup(struct net_device *dev);
|
|
|
|
|
|
|
|
|
|
void ipoib_event(struct ib_event_handler *handler,
|
|
|
|
|
struct ib_event *record);
|
|
|
|
|
|
|
|
|
|
int ipoib_vlan_add(struct net_device *pdev, unsigned short pkey);
|
|
|
|
|
int ipoib_vlan_delete(struct net_device *pdev, unsigned short pkey);
|
|
|
|
|
|
2012-09-13 07:56:36 +02:00
|
|
|
int __ipoib_vlan_add(struct ipoib_dev_priv *ppriv, struct ipoib_dev_priv *priv,
|
|
|
|
|
u16 pkey, int child_type);
|
|
|
|
|
|
|
|
|
|
int __init ipoib_netlink_init(void);
|
|
|
|
|
void __exit ipoib_netlink_fini(void);
|
|
|
|
|
|
2012-09-27 14:06:02 +02:00
|
|
|
void ipoib_set_umcast(struct net_device *ndev, int umcast_val);
|
|
|
|
|
int ipoib_set_mode(struct net_device *dev, const char *buf);
|
|
|
|
|
|
2017-04-10 10:22:30 +02:00
|
|
|
void ipoib_setup_common(struct net_device *dev);
|
2012-09-13 07:56:36 +02:00
|
|
|
|
2014-07-08 11:45:11 +02:00
|
|
|
void ipoib_pkey_open(struct ipoib_dev_priv *priv);
|
2007-05-24 17:32:46 +02:00
|
|
|
void ipoib_drain_cq(struct net_device *dev);
|
2005-04-17 00:20:36 +02:00
|
|
|
|
2008-04-17 06:09:32 +02:00
|
|
|
void ipoib_set_ethtool_ops(struct net_device *dev);
|
2017-01-05 09:56:08 +01:00
|
|
|
void ipoib_set_dev_features(struct ipoib_dev_priv *priv, struct ib_device *hca);
|
2008-04-17 06:09:32 +02:00
|
|
|
|
2007-10-24 04:57:54 +02:00
|
|
|
#define IPOIB_FLAGS_RC 0x80
|
|
|
|
|
#define IPOIB_FLAGS_UC 0x40
|
2007-02-05 21:12:23 +01:00
|
|
|
|
|
|
|
|
/* We don't support UC connections at the moment */
|
|
|
|
|
#define IPOIB_CM_SUPPORTED(ha) (ha[0] & (IPOIB_FLAGS_RC))
|
|
|
|
|
|
2012-10-03 06:23:43 +02:00
|
|
|
#ifdef CONFIG_INFINIBAND_IPOIB_CM
|
|
|
|
|
|
2008-01-25 23:15:24 +01:00
|
|
|
extern int ipoib_max_conn_qp;
|
|
|
|
|
|
2007-02-05 21:12:23 +01:00
|
|
|
static inline int ipoib_cm_admin_enabled(struct net_device *dev)
|
|
|
|
|
{
|
2017-04-10 10:22:29 +02:00
|
|
|
struct ipoib_dev_priv *priv = ipoib_priv(dev);
|
2007-02-05 21:12:23 +01:00
|
|
|
return IPOIB_CM_SUPPORTED(dev->dev_addr) &&
|
|
|
|
|
test_bit(IPOIB_FLAG_ADMIN_CM, &priv->flags);
|
|
|
|
|
}
|
|
|
|
|
|
IPoIB: Use a private hash table for path lookup in xmit path
Dave Miller <davem@davemloft.net> provided a detailed description of
why the way IPoIB is using neighbours for its own ipoib_neigh struct
is buggy:
Any time an ipoib_neigh is changed, a sequence like the following is made:
spin_lock_irqsave(&priv->lock, flags);
/*
* It's safe to call ipoib_put_ah() inside
* priv->lock here, because we know that
* path->ah will always hold one more reference,
* so ipoib_put_ah() will never do more than
* decrement the ref count.
*/
if (neigh->ah)
ipoib_put_ah(neigh->ah);
list_del(&neigh->list);
ipoib_neigh_free(dev, neigh);
spin_unlock_irqrestore(&priv->lock, flags);
ipoib_path_lookup(skb, n, dev);
This doesn't work, because you're leaving a stale pointer to the freed up
ipoib_neigh in the special neigh->ha pointer cookie. Yes, it even fails
with all the locking done to protect _changes_ to *ipoib_neigh(n), and
with the code in ipoib_neigh_free() that NULLs out the pointer.
The core issue is that read side calls to *to_ipoib_neigh(n) are not
being synchronized at all, they are performed without any locking. So
whether we hold the lock or not when making changes to *ipoib_neigh(n)
you still can have threads see references to freed up ipoib_neigh
objects.
cpu 1 cpu 2
n = *ipoib_neigh()
*ipoib_neigh() = NULL
kfree(n)
n->foo == OOPS
[..]
Perhaps the ipoib code can have a private path database it manages
entirely itself, which holds all the necessary information and is
looked up by some generic key which is available easily at transmit
time and does not involve generic neighbour entries.
See <http://marc.info/?l=linux-rdma&m=132812793105624&w=2> and
<http://marc.info/?l=linux-rdma&w=2&r=1&s=allows+references+to+freed+memory&q=b>
for the full discussion.
This patch aims to solve the race conditions found in the IPoIB driver.
The patch removes the connection between the core networking neighbour
structure and the ipoib_neigh structure. In addition to avoiding the
race described above, it allows us to handle SKBs carrying IP packets
that don't have any associated neighbour.
We add an ipoib_neigh hash table with N buckets where the key is the
destination hardware address. The ipoib_neigh is fetched from the
hash table and instead of the stashed location in the neighbour
structure. The hash table uses both RCU and reference counting to
guarantee that no ipoib_neigh instance is ever deleted while in use.
Fetching the ipoib_neigh structure instance from the hash also makes
the special code in ipoib_start_xmit that handles remote and local
bonding failover redundant.
Aged ipoib_neigh instances are deleted by a garbage collection task
that runs every M seconds and deletes every ipoib_neigh instance that
was idle for at least 2*M seconds. The deletion is safe since the
ipoib_neigh instances are protected using RCU and reference count
mechanisms.
The number of buckets (N) and frequency of running the GC thread (M),
are taken from the exported arb_tbl.
Signed-off-by: Shlomo Pongratz <shlomop@mellanox.com>
Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com>
Signed-off-by: Roland Dreier <roland@purestorage.com>
2012-07-24 19:05:22 +02:00
|
|
|
static inline int ipoib_cm_enabled(struct net_device *dev, u8 *hwaddr)
|
2007-02-05 21:12:23 +01:00
|
|
|
{
|
2017-04-10 10:22:29 +02:00
|
|
|
struct ipoib_dev_priv *priv = ipoib_priv(dev);
|
IPoIB: Use a private hash table for path lookup in xmit path
Dave Miller <davem@davemloft.net> provided a detailed description of
why the way IPoIB is using neighbours for its own ipoib_neigh struct
is buggy:
Any time an ipoib_neigh is changed, a sequence like the following is made:
spin_lock_irqsave(&priv->lock, flags);
/*
* It's safe to call ipoib_put_ah() inside
* priv->lock here, because we know that
* path->ah will always hold one more reference,
* so ipoib_put_ah() will never do more than
* decrement the ref count.
*/
if (neigh->ah)
ipoib_put_ah(neigh->ah);
list_del(&neigh->list);
ipoib_neigh_free(dev, neigh);
spin_unlock_irqrestore(&priv->lock, flags);
ipoib_path_lookup(skb, n, dev);
This doesn't work, because you're leaving a stale pointer to the freed up
ipoib_neigh in the special neigh->ha pointer cookie. Yes, it even fails
with all the locking done to protect _changes_ to *ipoib_neigh(n), and
with the code in ipoib_neigh_free() that NULLs out the pointer.
The core issue is that read side calls to *to_ipoib_neigh(n) are not
being synchronized at all, they are performed without any locking. So
whether we hold the lock or not when making changes to *ipoib_neigh(n)
you still can have threads see references to freed up ipoib_neigh
objects.
cpu 1 cpu 2
n = *ipoib_neigh()
*ipoib_neigh() = NULL
kfree(n)
n->foo == OOPS
[..]
Perhaps the ipoib code can have a private path database it manages
entirely itself, which holds all the necessary information and is
looked up by some generic key which is available easily at transmit
time and does not involve generic neighbour entries.
See <http://marc.info/?l=linux-rdma&m=132812793105624&w=2> and
<http://marc.info/?l=linux-rdma&w=2&r=1&s=allows+references+to+freed+memory&q=b>
for the full discussion.
This patch aims to solve the race conditions found in the IPoIB driver.
The patch removes the connection between the core networking neighbour
structure and the ipoib_neigh structure. In addition to avoiding the
race described above, it allows us to handle SKBs carrying IP packets
that don't have any associated neighbour.
We add an ipoib_neigh hash table with N buckets where the key is the
destination hardware address. The ipoib_neigh is fetched from the
hash table and instead of the stashed location in the neighbour
structure. The hash table uses both RCU and reference counting to
guarantee that no ipoib_neigh instance is ever deleted while in use.
Fetching the ipoib_neigh structure instance from the hash also makes
the special code in ipoib_start_xmit that handles remote and local
bonding failover redundant.
Aged ipoib_neigh instances are deleted by a garbage collection task
that runs every M seconds and deletes every ipoib_neigh instance that
was idle for at least 2*M seconds. The deletion is safe since the
ipoib_neigh instances are protected using RCU and reference count
mechanisms.
The number of buckets (N) and frequency of running the GC thread (M),
are taken from the exported arb_tbl.
Signed-off-by: Shlomo Pongratz <shlomop@mellanox.com>
Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com>
Signed-off-by: Roland Dreier <roland@purestorage.com>
2012-07-24 19:05:22 +02:00
|
|
|
return IPOIB_CM_SUPPORTED(hwaddr) &&
|
2007-02-05 21:12:23 +01:00
|
|
|
test_bit(IPOIB_FLAG_ADMIN_CM, &priv->flags);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static inline int ipoib_cm_up(struct ipoib_neigh *neigh)
|
|
|
|
|
|
|
|
|
|
{
|
|
|
|
|
return test_bit(IPOIB_FLAG_OPER_UP, &neigh->cm->flags);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static inline struct ipoib_cm_tx *ipoib_cm_get(struct ipoib_neigh *neigh)
|
|
|
|
|
{
|
|
|
|
|
return neigh->cm;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static inline void ipoib_cm_set(struct ipoib_neigh *neigh, struct ipoib_cm_tx *tx)
|
|
|
|
|
{
|
|
|
|
|
neigh->cm = tx;
|
|
|
|
|
}
|
|
|
|
|
|
2008-01-25 23:15:24 +01:00
|
|
|
static inline int ipoib_cm_has_srq(struct net_device *dev)
|
|
|
|
|
{
|
2017-04-10 10:22:29 +02:00
|
|
|
struct ipoib_dev_priv *priv = ipoib_priv(dev);
|
2008-01-25 23:15:24 +01:00
|
|
|
return !!priv->cm.srq;
|
|
|
|
|
}
|
|
|
|
|
|
2007-12-21 22:08:23 +01:00
|
|
|
static inline unsigned int ipoib_cm_max_mtu(struct net_device *dev)
|
|
|
|
|
{
|
2017-04-10 10:22:29 +02:00
|
|
|
struct ipoib_dev_priv *priv = ipoib_priv(dev);
|
2007-12-21 22:08:23 +01:00
|
|
|
return priv->cm.max_cm_mtu;
|
|
|
|
|
}
|
|
|
|
|
|
2007-02-05 21:12:23 +01:00
|
|
|
void ipoib_cm_send(struct net_device *dev, struct sk_buff *skb, struct ipoib_cm_tx *tx);
|
|
|
|
|
int ipoib_cm_dev_open(struct net_device *dev);
|
|
|
|
|
void ipoib_cm_dev_stop(struct net_device *dev);
|
|
|
|
|
int ipoib_cm_dev_init(struct net_device *dev);
|
|
|
|
|
int ipoib_cm_add_mode_attr(struct net_device *dev);
|
|
|
|
|
void ipoib_cm_dev_cleanup(struct net_device *dev);
|
|
|
|
|
struct ipoib_cm_tx *ipoib_cm_create_tx(struct net_device *dev, struct ipoib_path *path,
|
|
|
|
|
struct ipoib_neigh *neigh);
|
|
|
|
|
void ipoib_cm_destroy_tx(struct ipoib_cm_tx *tx);
|
2007-10-24 04:57:54 +02:00
|
|
|
void ipoib_cm_skb_too_long(struct net_device *dev, struct sk_buff *skb,
|
2007-02-05 21:12:23 +01:00
|
|
|
unsigned int mtu);
|
|
|
|
|
void ipoib_cm_handle_rx_wc(struct net_device *dev, struct ib_wc *wc);
|
2007-08-16 14:36:16 +02:00
|
|
|
void ipoib_cm_handle_tx_wc(struct net_device *dev, struct ib_wc *wc);
|
2007-02-05 21:12:23 +01:00
|
|
|
#else
|
|
|
|
|
|
|
|
|
|
struct ipoib_cm_tx;
|
|
|
|
|
|
2008-01-25 23:15:24 +01:00
|
|
|
#define ipoib_max_conn_qp 0
|
|
|
|
|
|
2007-02-05 21:12:23 +01:00
|
|
|
static inline int ipoib_cm_admin_enabled(struct net_device *dev)
|
|
|
|
|
{
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
IPoIB: Use a private hash table for path lookup in xmit path
Dave Miller <davem@davemloft.net> provided a detailed description of
why the way IPoIB is using neighbours for its own ipoib_neigh struct
is buggy:
Any time an ipoib_neigh is changed, a sequence like the following is made:
spin_lock_irqsave(&priv->lock, flags);
/*
* It's safe to call ipoib_put_ah() inside
* priv->lock here, because we know that
* path->ah will always hold one more reference,
* so ipoib_put_ah() will never do more than
* decrement the ref count.
*/
if (neigh->ah)
ipoib_put_ah(neigh->ah);
list_del(&neigh->list);
ipoib_neigh_free(dev, neigh);
spin_unlock_irqrestore(&priv->lock, flags);
ipoib_path_lookup(skb, n, dev);
This doesn't work, because you're leaving a stale pointer to the freed up
ipoib_neigh in the special neigh->ha pointer cookie. Yes, it even fails
with all the locking done to protect _changes_ to *ipoib_neigh(n), and
with the code in ipoib_neigh_free() that NULLs out the pointer.
The core issue is that read side calls to *to_ipoib_neigh(n) are not
being synchronized at all, they are performed without any locking. So
whether we hold the lock or not when making changes to *ipoib_neigh(n)
you still can have threads see references to freed up ipoib_neigh
objects.
cpu 1 cpu 2
n = *ipoib_neigh()
*ipoib_neigh() = NULL
kfree(n)
n->foo == OOPS
[..]
Perhaps the ipoib code can have a private path database it manages
entirely itself, which holds all the necessary information and is
looked up by some generic key which is available easily at transmit
time and does not involve generic neighbour entries.
See <http://marc.info/?l=linux-rdma&m=132812793105624&w=2> and
<http://marc.info/?l=linux-rdma&w=2&r=1&s=allows+references+to+freed+memory&q=b>
for the full discussion.
This patch aims to solve the race conditions found in the IPoIB driver.
The patch removes the connection between the core networking neighbour
structure and the ipoib_neigh structure. In addition to avoiding the
race described above, it allows us to handle SKBs carrying IP packets
that don't have any associated neighbour.
We add an ipoib_neigh hash table with N buckets where the key is the
destination hardware address. The ipoib_neigh is fetched from the
hash table and instead of the stashed location in the neighbour
structure. The hash table uses both RCU and reference counting to
guarantee that no ipoib_neigh instance is ever deleted while in use.
Fetching the ipoib_neigh structure instance from the hash also makes
the special code in ipoib_start_xmit that handles remote and local
bonding failover redundant.
Aged ipoib_neigh instances are deleted by a garbage collection task
that runs every M seconds and deletes every ipoib_neigh instance that
was idle for at least 2*M seconds. The deletion is safe since the
ipoib_neigh instances are protected using RCU and reference count
mechanisms.
The number of buckets (N) and frequency of running the GC thread (M),
are taken from the exported arb_tbl.
Signed-off-by: Shlomo Pongratz <shlomop@mellanox.com>
Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com>
Signed-off-by: Roland Dreier <roland@purestorage.com>
2012-07-24 19:05:22 +02:00
|
|
|
static inline int ipoib_cm_enabled(struct net_device *dev, u8 *hwaddr)
|
2007-02-05 21:12:23 +01:00
|
|
|
|
|
|
|
|
{
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static inline int ipoib_cm_up(struct ipoib_neigh *neigh)
|
|
|
|
|
|
|
|
|
|
{
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static inline struct ipoib_cm_tx *ipoib_cm_get(struct ipoib_neigh *neigh)
|
|
|
|
|
{
|
|
|
|
|
return NULL;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static inline void ipoib_cm_set(struct ipoib_neigh *neigh, struct ipoib_cm_tx *tx)
|
|
|
|
|
{
|
|
|
|
|
}
|
|
|
|
|
|
2008-01-25 23:15:24 +01:00
|
|
|
static inline int ipoib_cm_has_srq(struct net_device *dev)
|
|
|
|
|
{
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
2007-12-21 22:08:23 +01:00
|
|
|
static inline unsigned int ipoib_cm_max_mtu(struct net_device *dev)
|
|
|
|
|
{
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
2007-02-05 21:12:23 +01:00
|
|
|
static inline
|
|
|
|
|
void ipoib_cm_send(struct net_device *dev, struct sk_buff *skb, struct ipoib_cm_tx *tx)
|
|
|
|
|
{
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static inline
|
|
|
|
|
int ipoib_cm_dev_open(struct net_device *dev)
|
|
|
|
|
{
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static inline
|
|
|
|
|
void ipoib_cm_dev_stop(struct net_device *dev)
|
|
|
|
|
{
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static inline
|
|
|
|
|
int ipoib_cm_dev_init(struct net_device *dev)
|
|
|
|
|
{
|
|
|
|
|
return -ENOSYS;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static inline
|
|
|
|
|
void ipoib_cm_dev_cleanup(struct net_device *dev)
|
|
|
|
|
{
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static inline
|
|
|
|
|
struct ipoib_cm_tx *ipoib_cm_create_tx(struct net_device *dev, struct ipoib_path *path,
|
|
|
|
|
struct ipoib_neigh *neigh)
|
|
|
|
|
{
|
|
|
|
|
return NULL;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static inline
|
|
|
|
|
void ipoib_cm_destroy_tx(struct ipoib_cm_tx *tx)
|
|
|
|
|
{
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static inline
|
|
|
|
|
int ipoib_cm_add_mode_attr(struct net_device *dev)
|
|
|
|
|
{
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
2007-10-24 04:57:54 +02:00
|
|
|
static inline void ipoib_cm_skb_too_long(struct net_device *dev, struct sk_buff *skb,
|
2007-02-05 21:12:23 +01:00
|
|
|
unsigned int mtu)
|
|
|
|
|
{
|
|
|
|
|
dev_kfree_skb_any(skb);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static inline void ipoib_cm_handle_rx_wc(struct net_device *dev, struct ib_wc *wc)
|
|
|
|
|
{
|
|
|
|
|
}
|
|
|
|
|
|
2007-08-16 14:36:16 +02:00
|
|
|
static inline void ipoib_cm_handle_tx_wc(struct net_device *dev, struct ib_wc *wc)
|
|
|
|
|
{
|
|
|
|
|
}
|
2007-02-05 21:12:23 +01:00
|
|
|
#endif
|
|
|
|
|
|
2005-04-17 00:20:36 +02:00
|
|
|
#ifdef CONFIG_INFINIBAND_IPOIB_DEBUG
|
2005-11-07 19:33:11 +01:00
|
|
|
void ipoib_create_debug_files(struct net_device *dev);
|
|
|
|
|
void ipoib_delete_debug_files(struct net_device *dev);
|
2005-04-17 00:20:36 +02:00
|
|
|
int ipoib_register_debugfs(void);
|
|
|
|
|
void ipoib_unregister_debugfs(void);
|
|
|
|
|
#else
|
2005-11-07 19:33:11 +01:00
|
|
|
static inline void ipoib_create_debug_files(struct net_device *dev) { }
|
|
|
|
|
static inline void ipoib_delete_debug_files(struct net_device *dev) { }
|
2005-04-17 00:20:36 +02:00
|
|
|
static inline int ipoib_register_debugfs(void) { return 0; }
|
|
|
|
|
static inline void ipoib_unregister_debugfs(void) { }
|
|
|
|
|
#endif
|
|
|
|
|
|
|
|
|
|
#define ipoib_printk(level, priv, format, arg...) \
|
|
|
|
|
printk(level "%s: " format, ((struct ipoib_dev_priv *) priv)->dev->name , ## arg)
|
|
|
|
|
#define ipoib_warn(priv, format, arg...) \
|
2016-08-08 16:14:22 +02:00
|
|
|
do { \
|
|
|
|
|
static DEFINE_RATELIMIT_STATE(_rs, \
|
|
|
|
|
10 * HZ /*10 seconds */, \
|
|
|
|
|
100); \
|
|
|
|
|
if (__ratelimit(&_rs)) \
|
|
|
|
|
ipoib_printk(KERN_WARNING, priv, format , ## arg);\
|
|
|
|
|
} while (0)
|
2005-04-17 00:20:36 +02:00
|
|
|
|
2006-04-10 18:43:58 +02:00
|
|
|
extern int ipoib_sendq_size;
|
|
|
|
|
extern int ipoib_recvq_size;
|
2005-04-17 00:20:36 +02:00
|
|
|
|
2006-08-22 01:40:12 +02:00
|
|
|
extern struct ib_sa_client ipoib_sa_client;
|
|
|
|
|
|
2005-04-17 00:20:36 +02:00
|
|
|
#ifdef CONFIG_INFINIBAND_IPOIB_DEBUG
|
|
|
|
|
extern int ipoib_debug_level;
|
|
|
|
|
|
|
|
|
|
#define ipoib_dbg(priv, format, arg...) \
|
2007-10-24 04:57:54 +02:00
|
|
|
do { \
|
2005-04-17 00:20:36 +02:00
|
|
|
if (ipoib_debug_level > 0) \
|
|
|
|
|
ipoib_printk(KERN_DEBUG, priv, format , ## arg); \
|
|
|
|
|
} while (0)
|
|
|
|
|
#define ipoib_dbg_mcast(priv, format, arg...) \
|
2007-10-24 04:57:54 +02:00
|
|
|
do { \
|
2005-04-17 00:20:36 +02:00
|
|
|
if (mcast_debug_level > 0) \
|
|
|
|
|
ipoib_printk(KERN_DEBUG, priv, format , ## arg); \
|
|
|
|
|
} while (0)
|
|
|
|
|
#else /* CONFIG_INFINIBAND_IPOIB_DEBUG */
|
|
|
|
|
#define ipoib_dbg(priv, format, arg...) \
|
|
|
|
|
do { (void) (priv); } while (0)
|
|
|
|
|
#define ipoib_dbg_mcast(priv, format, arg...) \
|
|
|
|
|
do { (void) (priv); } while (0)
|
|
|
|
|
#endif /* CONFIG_INFINIBAND_IPOIB_DEBUG */
|
|
|
|
|
|
|
|
|
|
#ifdef CONFIG_INFINIBAND_IPOIB_DEBUG_DATA
|
|
|
|
|
#define ipoib_dbg_data(priv, format, arg...) \
|
2007-10-24 04:57:54 +02:00
|
|
|
do { \
|
2005-04-17 00:20:36 +02:00
|
|
|
if (data_debug_level > 0) \
|
|
|
|
|
ipoib_printk(KERN_DEBUG, priv, format , ## arg); \
|
|
|
|
|
} while (0)
|
|
|
|
|
#else /* CONFIG_INFINIBAND_IPOIB_DEBUG_DATA */
|
|
|
|
|
#define ipoib_dbg_data(priv, format, arg...) \
|
|
|
|
|
do { (void) (priv); } while (0)
|
|
|
|
|
#endif /* CONFIG_INFINIBAND_IPOIB_DEBUG_DATA */
|
|
|
|
|
|
2007-02-05 21:12:23 +01:00
|
|
|
#define IPOIB_QPN(ha) (be32_to_cpup((__be32 *) ha) & 0xffffff)
|
|
|
|
|
|
2013-02-19 16:40:23 +01:00
|
|
|
extern const char ipoib_driver_version[];
|
|
|
|
|
|
2005-04-17 00:20:36 +02:00
|
|
|
#endif /* _IPOIB_H */
|
