2012-08-03 12:40:47 +04:00
/*
* Copyright ( c ) 2012 Mellanox Technologies . All rights reserved .
*
* 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 .
*/
# include <rdma/ib_mad.h>
# include <linux/mlx4/cmd.h>
# include <linux/rbtree.h>
# include <linux/idr.h>
# include <rdma/ib_cm.h>
# include "mlx4_ib.h"
IB/mlx4: Increase the timeout for CM cache
Using CX-3 virtual functions, either from a bare-metal machine or
pass-through from a VM, MAD packets are proxied through the PF driver.
Since the VF drivers have separate name spaces for MAD Transaction Ids
(TIDs), the PF driver has to re-map the TIDs and keep the book keeping
in a cache.
Following the RDMA Connection Manager (CM) protocol, it is clear when
an entry has to evicted form the cache. But life is not perfect,
remote peers may die or be rebooted. Hence, it's a timeout to wipe out
a cache entry, when the PF driver assumes the remote peer has gone.
During workloads where a high number of QPs are destroyed concurrently,
excessive amount of CM DREQ retries has been observed
The problem can be demonstrated in a bare-metal environment, where two
nodes have instantiated 8 VFs each. This using dual ported HCAs, so we
have 16 vPorts per physical server.
64 processes are associated with each vPort and creates and destroys
one QP for each of the remote 64 processes. That is, 1024 QPs per
vPort, all in all 16K QPs. The QPs are created/destroyed using the
CM.
When tearing down these 16K QPs, excessive CM DREQ retries (and
duplicates) are observed. With some cat/paste/awk wizardry on the
infiniband_cm sysfs, we observe as sum of the 16 vPorts on one of the
nodes:
cm_rx_duplicates:
dreq 2102
cm_rx_msgs:
drep 1989
dreq 6195
rep 3968
req 4224
rtu 4224
cm_tx_msgs:
drep 4093
dreq 27568
rep 4224
req 3968
rtu 3968
cm_tx_retries:
dreq 23469
Note that the active/passive side is equally distributed between the
two nodes.
Enabling pr_debug in cm.c gives tons of:
[171778.814239] <mlx4_ib> mlx4_ib_multiplex_cm_handler: id{slave:
1,sl_cm_id: 0xd393089f} is NULL!
By increasing the CM_CLEANUP_CACHE_TIMEOUT from 5 to 30 seconds, the
tear-down phase of the application is reduced from approximately 90 to
50 seconds. Retries/duplicates are also significantly reduced:
cm_rx_duplicates:
dreq 2460
[]
cm_tx_retries:
dreq 3010
req 47
Increasing the timeout further didn't help, as these duplicates and
retries stems from a too short CMA timeout, which was 20 (~4 seconds)
on the systems. By increasing the CMA timeout to 22 (~17 seconds), the
numbers fell down to about 10 for both of them.
Adjustment of the CMA timeout is not part of this commit.
Signed-off-by: Håkon Bugge <haakon.bugge@oracle.com>
Acked-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
2019-02-17 17:45:12 +03:00
# define CM_CLEANUP_CACHE_TIMEOUT (30 * HZ)
2012-08-03 12:40:47 +04:00
struct id_map_entry {
struct rb_node node ;
u32 sl_cm_id ;
u32 pv_cm_id ;
int slave_id ;
int scheduled_delete ;
struct mlx4_ib_dev * dev ;
struct list_head list ;
struct delayed_work timeout ;
} ;
IB/mlx4: Add support for REJ due to timeout
A CM REJ packet with its reason equal to timeout is a special beast in the
sense that it doesn't have a Remote Communication ID nor does it have a
Remote Port GID.
Using CX-3 virtual functions, either from a bare-metal machine or
pass-through from a VM, MAD packets are proxied through the PF driver.
Since the VF drivers have separate name spaces for MAD Transaction Ids
(TIDs), the PF driver has to re-map the TIDs and keep the book keeping
in a cache.
This proxying doesn't not handle said REJ packets.
If the active side abandons its connection attempt after having sent a
REQ, it will send a REJ with the reason being timeout. This example can be
provoked by a simple user-verbs program, which ends up doing:
rdma_connect(cm_id, &conn_param);
rdma_destroy_id(cm_id);
using the async librdmacm API.
Having dynamic debug prints enabled in the mlx4_ib driver, we will then
see:
mlx4_ib_demux_cm_handler: Couldn't find an entry for pv_cm_id 0x0, attr_id 0x12
The solution is to introduce a radix-tree. When a REQ packet is received
and handled in mlx4_ib_demux_cm_handler(), we know the connecting peer's
para-virtual cm_id and the destination slave. We then insert an entry into
the tree with said information. We also schedule work to remove this entry
from the tree and free it, in order to avoid memory leak.
When a REJ packet with reason timeout is received, we can look up the
slave in the tree, and deliver the packet to the correct slave.
When a duplicate REQ packet is received, the entry is in the tree. In this
case, we adjust the delayed work in order to avoid a too premature
eviction of the entry.
When cleaning up, we simply traverse the tree and modify any delayed work
to use a zero delay. A subsequent flush of the system_wq will ensure all
entries being wiped out.
Fixes: 3cf69cc8dbeb ("IB/mlx4: Add CM paravirtualization")
Link: https://lore.kernel.org/r/20200803061941.1139994-6-haakon.bugge@oracle.com
Signed-off-by: Håkon Bugge <haakon.bugge@oracle.com>
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
2020-08-03 09:19:40 +03:00
struct rej_tmout_entry {
int slave ;
u32 rem_pv_cm_id ;
struct delayed_work timeout ;
2020-10-09 17:24:42 +03:00
struct xarray * xa_rej_tmout ;
IB/mlx4: Add support for REJ due to timeout
A CM REJ packet with its reason equal to timeout is a special beast in the
sense that it doesn't have a Remote Communication ID nor does it have a
Remote Port GID.
Using CX-3 virtual functions, either from a bare-metal machine or
pass-through from a VM, MAD packets are proxied through the PF driver.
Since the VF drivers have separate name spaces for MAD Transaction Ids
(TIDs), the PF driver has to re-map the TIDs and keep the book keeping
in a cache.
This proxying doesn't not handle said REJ packets.
If the active side abandons its connection attempt after having sent a
REQ, it will send a REJ with the reason being timeout. This example can be
provoked by a simple user-verbs program, which ends up doing:
rdma_connect(cm_id, &conn_param);
rdma_destroy_id(cm_id);
using the async librdmacm API.
Having dynamic debug prints enabled in the mlx4_ib driver, we will then
see:
mlx4_ib_demux_cm_handler: Couldn't find an entry for pv_cm_id 0x0, attr_id 0x12
The solution is to introduce a radix-tree. When a REQ packet is received
and handled in mlx4_ib_demux_cm_handler(), we know the connecting peer's
para-virtual cm_id and the destination slave. We then insert an entry into
the tree with said information. We also schedule work to remove this entry
from the tree and free it, in order to avoid memory leak.
When a REJ packet with reason timeout is received, we can look up the
slave in the tree, and deliver the packet to the correct slave.
When a duplicate REQ packet is received, the entry is in the tree. In this
case, we adjust the delayed work in order to avoid a too premature
eviction of the entry.
When cleaning up, we simply traverse the tree and modify any delayed work
to use a zero delay. A subsequent flush of the system_wq will ensure all
entries being wiped out.
Fixes: 3cf69cc8dbeb ("IB/mlx4: Add CM paravirtualization")
Link: https://lore.kernel.org/r/20200803061941.1139994-6-haakon.bugge@oracle.com
Signed-off-by: Håkon Bugge <haakon.bugge@oracle.com>
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
2020-08-03 09:19:40 +03:00
} ;
2012-08-03 12:40:47 +04:00
struct cm_generic_msg {
struct ib_mad_hdr hdr ;
__be32 local_comm_id ;
__be32 remote_comm_id ;
IB/mlx4: Add support for REJ due to timeout
A CM REJ packet with its reason equal to timeout is a special beast in the
sense that it doesn't have a Remote Communication ID nor does it have a
Remote Port GID.
Using CX-3 virtual functions, either from a bare-metal machine or
pass-through from a VM, MAD packets are proxied through the PF driver.
Since the VF drivers have separate name spaces for MAD Transaction Ids
(TIDs), the PF driver has to re-map the TIDs and keep the book keeping
in a cache.
This proxying doesn't not handle said REJ packets.
If the active side abandons its connection attempt after having sent a
REQ, it will send a REJ with the reason being timeout. This example can be
provoked by a simple user-verbs program, which ends up doing:
rdma_connect(cm_id, &conn_param);
rdma_destroy_id(cm_id);
using the async librdmacm API.
Having dynamic debug prints enabled in the mlx4_ib driver, we will then
see:
mlx4_ib_demux_cm_handler: Couldn't find an entry for pv_cm_id 0x0, attr_id 0x12
The solution is to introduce a radix-tree. When a REQ packet is received
and handled in mlx4_ib_demux_cm_handler(), we know the connecting peer's
para-virtual cm_id and the destination slave. We then insert an entry into
the tree with said information. We also schedule work to remove this entry
from the tree and free it, in order to avoid memory leak.
When a REJ packet with reason timeout is received, we can look up the
slave in the tree, and deliver the packet to the correct slave.
When a duplicate REQ packet is received, the entry is in the tree. In this
case, we adjust the delayed work in order to avoid a too premature
eviction of the entry.
When cleaning up, we simply traverse the tree and modify any delayed work
to use a zero delay. A subsequent flush of the system_wq will ensure all
entries being wiped out.
Fixes: 3cf69cc8dbeb ("IB/mlx4: Add CM paravirtualization")
Link: https://lore.kernel.org/r/20200803061941.1139994-6-haakon.bugge@oracle.com
Signed-off-by: Håkon Bugge <haakon.bugge@oracle.com>
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
2020-08-03 09:19:40 +03:00
unsigned char unused [ 2 ] ;
__be16 rej_reason ;
2012-08-03 12:40:47 +04:00
} ;
2014-03-12 14:00:42 +04:00
struct cm_sidr_generic_msg {
struct ib_mad_hdr hdr ;
__be32 request_id ;
} ;
2012-08-03 12:40:47 +04:00
struct cm_req_msg {
unsigned char unused [ 0x60 ] ;
union ib_gid primary_path_sgid ;
} ;
static void set_local_comm_id ( struct ib_mad * mad , u32 cm_id )
{
2014-03-12 14:00:42 +04:00
if ( mad - > mad_hdr . attr_id = = CM_SIDR_REQ_ATTR_ID ) {
struct cm_sidr_generic_msg * msg =
( struct cm_sidr_generic_msg * ) mad ;
msg - > request_id = cpu_to_be32 ( cm_id ) ;
} else if ( mad - > mad_hdr . attr_id = = CM_SIDR_REP_ATTR_ID ) {
pr_err ( " trying to set local_comm_id in SIDR_REP \n " ) ;
return ;
} else {
struct cm_generic_msg * msg = ( struct cm_generic_msg * ) mad ;
msg - > local_comm_id = cpu_to_be32 ( cm_id ) ;
}
2012-08-03 12:40:47 +04:00
}
static u32 get_local_comm_id ( struct ib_mad * mad )
{
2014-03-12 14:00:42 +04:00
if ( mad - > mad_hdr . attr_id = = CM_SIDR_REQ_ATTR_ID ) {
struct cm_sidr_generic_msg * msg =
( struct cm_sidr_generic_msg * ) mad ;
return be32_to_cpu ( msg - > request_id ) ;
} else if ( mad - > mad_hdr . attr_id = = CM_SIDR_REP_ATTR_ID ) {
pr_err ( " trying to set local_comm_id in SIDR_REP \n " ) ;
return - 1 ;
} else {
struct cm_generic_msg * msg = ( struct cm_generic_msg * ) mad ;
return be32_to_cpu ( msg - > local_comm_id ) ;
}
2012-08-03 12:40:47 +04:00
}
static void set_remote_comm_id ( struct ib_mad * mad , u32 cm_id )
{
2014-03-12 14:00:42 +04:00
if ( mad - > mad_hdr . attr_id = = CM_SIDR_REP_ATTR_ID ) {
struct cm_sidr_generic_msg * msg =
( struct cm_sidr_generic_msg * ) mad ;
msg - > request_id = cpu_to_be32 ( cm_id ) ;
} else if ( mad - > mad_hdr . attr_id = = CM_SIDR_REQ_ATTR_ID ) {
pr_err ( " trying to set remote_comm_id in SIDR_REQ \n " ) ;
return ;
} else {
struct cm_generic_msg * msg = ( struct cm_generic_msg * ) mad ;
msg - > remote_comm_id = cpu_to_be32 ( cm_id ) ;
}
2012-08-03 12:40:47 +04:00
}
static u32 get_remote_comm_id ( struct ib_mad * mad )
{
2014-03-12 14:00:42 +04:00
if ( mad - > mad_hdr . attr_id = = CM_SIDR_REP_ATTR_ID ) {
struct cm_sidr_generic_msg * msg =
( struct cm_sidr_generic_msg * ) mad ;
return be32_to_cpu ( msg - > request_id ) ;
} else if ( mad - > mad_hdr . attr_id = = CM_SIDR_REQ_ATTR_ID ) {
pr_err ( " trying to set remote_comm_id in SIDR_REQ \n " ) ;
return - 1 ;
} else {
struct cm_generic_msg * msg = ( struct cm_generic_msg * ) mad ;
return be32_to_cpu ( msg - > remote_comm_id ) ;
}
2012-08-03 12:40:47 +04:00
}
static union ib_gid gid_from_req_msg ( struct ib_device * ibdev , struct ib_mad * mad )
{
struct cm_req_msg * msg = ( struct cm_req_msg * ) mad ;
return msg - > primary_path_sgid ;
}
/* Lock should be taken before called */
static struct id_map_entry *
id_map_find_by_sl_id ( struct ib_device * ibdev , u32 slave_id , u32 sl_cm_id )
{
struct rb_root * sl_id_map = & to_mdev ( ibdev ) - > sriov . sl_id_map ;
struct rb_node * node = sl_id_map - > rb_node ;
while ( node ) {
struct id_map_entry * id_map_entry =
rb_entry ( node , struct id_map_entry , node ) ;
if ( id_map_entry - > sl_cm_id > sl_cm_id )
node = node - > rb_left ;
else if ( id_map_entry - > sl_cm_id < sl_cm_id )
node = node - > rb_right ;
else if ( id_map_entry - > slave_id > slave_id )
node = node - > rb_left ;
else if ( id_map_entry - > slave_id < slave_id )
node = node - > rb_right ;
else
return id_map_entry ;
}
return NULL ;
}
static void id_map_ent_timeout ( struct work_struct * work )
{
struct delayed_work * delay = to_delayed_work ( work ) ;
struct id_map_entry * ent = container_of ( delay , struct id_map_entry , timeout ) ;
2019-02-21 03:20:44 +03:00
struct id_map_entry * found_ent ;
2012-08-03 12:40:47 +04:00
struct mlx4_ib_dev * dev = ent - > dev ;
struct mlx4_ib_sriov * sriov = & dev - > sriov ;
struct rb_root * sl_id_map = & sriov - > sl_id_map ;
spin_lock ( & sriov - > id_map_lock ) ;
2019-02-21 03:20:44 +03:00
if ( ! xa_erase ( & sriov - > pv_id_table , ent - > pv_cm_id ) )
2012-08-03 12:40:47 +04:00
goto out ;
found_ent = id_map_find_by_sl_id ( & dev - > ib_dev , ent - > slave_id , ent - > sl_cm_id ) ;
if ( found_ent & & found_ent = = ent )
rb_erase ( & found_ent - > node , sl_id_map ) ;
out :
list_del ( & ent - > list ) ;
spin_unlock ( & sriov - > id_map_lock ) ;
kfree ( ent ) ;
}
static void sl_id_map_add ( struct ib_device * ibdev , struct id_map_entry * new )
{
struct rb_root * sl_id_map = & to_mdev ( ibdev ) - > sriov . sl_id_map ;
struct rb_node * * link = & sl_id_map - > rb_node , * parent = NULL ;
struct id_map_entry * ent ;
int slave_id = new - > slave_id ;
int sl_cm_id = new - > sl_cm_id ;
ent = id_map_find_by_sl_id ( ibdev , slave_id , sl_cm_id ) ;
if ( ent ) {
pr_debug ( " overriding existing sl_id_map entry (cm_id = %x) \n " ,
sl_cm_id ) ;
rb_replace_node ( & ent - > node , & new - > node , sl_id_map ) ;
return ;
}
/* Go to the bottom of the tree */
while ( * link ) {
parent = * link ;
ent = rb_entry ( parent , struct id_map_entry , node ) ;
if ( ent - > sl_cm_id > sl_cm_id | | ( ent - > sl_cm_id = = sl_cm_id & & ent - > slave_id > slave_id ) )
link = & ( * link ) - > rb_left ;
else
link = & ( * link ) - > rb_right ;
}
rb_link_node ( & new - > node , parent , link ) ;
rb_insert_color ( & new - > node , sl_id_map ) ;
}
static struct id_map_entry *
id_map_alloc ( struct ib_device * ibdev , int slave_id , u32 sl_cm_id )
{
2013-02-28 05:04:23 +04:00
int ret ;
2012-08-03 12:40:47 +04:00
struct id_map_entry * ent ;
struct mlx4_ib_sriov * sriov = & to_mdev ( ibdev ) - > sriov ;
ent = kmalloc ( sizeof ( struct id_map_entry ) , GFP_KERNEL ) ;
2016-11-03 17:44:12 +03:00
if ( ! ent )
2012-08-03 12:40:47 +04:00
return ERR_PTR ( - ENOMEM ) ;
ent - > sl_cm_id = sl_cm_id ;
ent - > slave_id = slave_id ;
ent - > scheduled_delete = 0 ;
ent - > dev = to_mdev ( ibdev ) ;
INIT_DELAYED_WORK ( & ent - > timeout , id_map_ent_timeout ) ;
2019-02-21 03:20:44 +03:00
ret = xa_alloc_cyclic ( & sriov - > pv_id_table , & ent - > pv_cm_id , ent ,
xa_limit_32b , & sriov - > pv_id_next , GFP_KERNEL ) ;
2013-02-28 05:04:23 +04:00
if ( ret > = 0 ) {
2019-02-21 03:20:44 +03:00
spin_lock ( & sriov - > id_map_lock ) ;
2013-02-28 05:04:23 +04:00
sl_id_map_add ( ibdev , ent ) ;
2012-08-03 12:40:47 +04:00
list_add_tail ( & ent - > list , & sriov - > cm_list ) ;
2019-02-21 03:20:44 +03:00
spin_unlock ( & sriov - > id_map_lock ) ;
2013-02-28 05:04:23 +04:00
return ent ;
2019-02-21 03:20:44 +03:00
}
2013-02-28 05:04:23 +04:00
2012-08-03 12:40:47 +04:00
/*error flow*/
kfree ( ent ) ;
2019-02-21 03:20:44 +03:00
mlx4_ib_warn ( ibdev , " Allocation failed (err:0x%x) \n " , ret ) ;
2012-08-03 12:40:47 +04:00
return ERR_PTR ( - ENOMEM ) ;
}
static struct id_map_entry *
2017-04-28 14:06:54 +03:00
id_map_get ( struct ib_device * ibdev , int * pv_cm_id , int slave_id , int sl_cm_id )
2012-08-03 12:40:47 +04:00
{
struct id_map_entry * ent ;
struct mlx4_ib_sriov * sriov = & to_mdev ( ibdev ) - > sriov ;
spin_lock ( & sriov - > id_map_lock ) ;
if ( * pv_cm_id = = - 1 ) {
2017-04-28 14:06:54 +03:00
ent = id_map_find_by_sl_id ( ibdev , slave_id , sl_cm_id ) ;
2012-08-03 12:40:47 +04:00
if ( ent )
* pv_cm_id = ( int ) ent - > pv_cm_id ;
} else
2019-02-21 03:20:44 +03:00
ent = xa_load ( & sriov - > pv_id_table , * pv_cm_id ) ;
2012-08-03 12:40:47 +04:00
spin_unlock ( & sriov - > id_map_lock ) ;
return ent ;
}
static void schedule_delayed ( struct ib_device * ibdev , struct id_map_entry * id )
{
struct mlx4_ib_sriov * sriov = & to_mdev ( ibdev ) - > sriov ;
unsigned long flags ;
spin_lock ( & sriov - > id_map_lock ) ;
2012-11-27 20:24:29 +04:00
spin_lock_irqsave ( & sriov - > going_down_lock , flags ) ;
2012-08-03 12:40:47 +04:00
/*make sure that there is no schedule inside the scheduled work.*/
IB/mlx4: Fix leak in id_map_find_del
Using CX-3 virtual functions, either from a bare-metal machine or
pass-through from a VM, MAD packets are proxied through the PF driver.
Since the VF drivers have separate name spaces for MAD Transaction Ids
(TIDs), the PF driver has to re-map the TIDs and keep the book keeping in
a cache.
Following the RDMA Connection Manager (CM) protocol, it is clear when an
entry has to evicted from the cache. When a DREP is sent from
mlx4_ib_multiplex_cm_handler(), id_map_find_del() is called. Similar when
a REJ is received by the mlx4_ib_demux_cm_handler(), id_map_find_del() is
called.
This function wipes out the TID in use from the IDR or XArray and removes
the id_map_entry from the table.
In short, it does everything except the topping of the cake, which is to
remove the entry from the list and free it. In other words, for the REJ
case enumerated above, one id_map_entry will be leaked.
For the other case above, a DREQ has been received first. The reception of
the DREQ will trigger queuing of a delayed work to delete the
id_map_entry, for the case where the VM doesn't send back a DREP.
In the normal case, the VM _will_ send back a DREP, and id_map_find_del()
will be called.
But this scenario introduces a secondary leak. First, when the DREQ is
received, a delayed work is queued. The VM will then return a DREP, which
will call id_map_find_del(). As stated above, this will free the TID used
from the XArray or IDR. Now, there is window where that particular TID can
be re-allocated, lets say by an outgoing REQ. This TID will later be wiped
out by the delayed work, when the function id_map_ent_timeout() is
called. But the id_map_entry allocated by the outgoing REQ will not be
de-allocated, and we have a leak.
Both leaks are fixed by removing the id_map_find_del() function and only
using schedule_delayed(). Of course, a check in schedule_delayed() to see
if the work already has been queued, has been added.
Another benefit of always using the delayed version for deleting entries,
is that we do get a TimeWait effect; a TID no longer in use, will occupy
the XArray or IDR for CM_CLEANUP_CACHE_TIMEOUT time, without any ability
of being re-used for that time period.
Fixes: 3cf69cc8dbeb ("IB/mlx4: Add CM paravirtualization")
Link: https://lore.kernel.org/r/20200123155521.1212288-1-haakon.bugge@oracle.com
Signed-off-by: Håkon Bugge <haakon.bugge@oracle.com>
Signed-off-by: Manjunath Patil <manjunath.b.patil@oracle.com>
Reviewed-by: Rama Nichanamatlu <rama.nichanamatlu@oracle.com>
Reviewed-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
2020-01-23 18:55:21 +03:00
if ( ! sriov - > is_going_down & & ! id - > scheduled_delete ) {
2012-08-03 12:40:47 +04:00
id - > scheduled_delete = 1 ;
schedule_delayed_work ( & id - > timeout , CM_CLEANUP_CACHE_TIMEOUT ) ;
2020-08-03 09:19:41 +03:00
} else if ( id - > scheduled_delete ) {
/* Adjust timeout if already scheduled */
mod_delayed_work ( system_wq , & id - > timeout , CM_CLEANUP_CACHE_TIMEOUT ) ;
2012-08-03 12:40:47 +04:00
}
spin_unlock_irqrestore ( & sriov - > going_down_lock , flags ) ;
2012-11-27 20:24:29 +04:00
spin_unlock ( & sriov - > id_map_lock ) ;
2012-08-03 12:40:47 +04:00
}
IB/mlx4: Add support for REJ due to timeout
A CM REJ packet with its reason equal to timeout is a special beast in the
sense that it doesn't have a Remote Communication ID nor does it have a
Remote Port GID.
Using CX-3 virtual functions, either from a bare-metal machine or
pass-through from a VM, MAD packets are proxied through the PF driver.
Since the VF drivers have separate name spaces for MAD Transaction Ids
(TIDs), the PF driver has to re-map the TIDs and keep the book keeping
in a cache.
This proxying doesn't not handle said REJ packets.
If the active side abandons its connection attempt after having sent a
REQ, it will send a REJ with the reason being timeout. This example can be
provoked by a simple user-verbs program, which ends up doing:
rdma_connect(cm_id, &conn_param);
rdma_destroy_id(cm_id);
using the async librdmacm API.
Having dynamic debug prints enabled in the mlx4_ib driver, we will then
see:
mlx4_ib_demux_cm_handler: Couldn't find an entry for pv_cm_id 0x0, attr_id 0x12
The solution is to introduce a radix-tree. When a REQ packet is received
and handled in mlx4_ib_demux_cm_handler(), we know the connecting peer's
para-virtual cm_id and the destination slave. We then insert an entry into
the tree with said information. We also schedule work to remove this entry
from the tree and free it, in order to avoid memory leak.
When a REJ packet with reason timeout is received, we can look up the
slave in the tree, and deliver the packet to the correct slave.
When a duplicate REQ packet is received, the entry is in the tree. In this
case, we adjust the delayed work in order to avoid a too premature
eviction of the entry.
When cleaning up, we simply traverse the tree and modify any delayed work
to use a zero delay. A subsequent flush of the system_wq will ensure all
entries being wiped out.
Fixes: 3cf69cc8dbeb ("IB/mlx4: Add CM paravirtualization")
Link: https://lore.kernel.org/r/20200803061941.1139994-6-haakon.bugge@oracle.com
Signed-off-by: Håkon Bugge <haakon.bugge@oracle.com>
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
2020-08-03 09:19:40 +03:00
# define REJ_REASON(m) be16_to_cpu(((struct cm_generic_msg *)(m))->rej_reason)
2012-08-03 12:40:47 +04:00
int mlx4_ib_multiplex_cm_handler ( struct ib_device * ibdev , int port , int slave_id ,
struct ib_mad * mad )
{
struct id_map_entry * id ;
u32 sl_cm_id ;
int pv_cm_id = - 1 ;
if ( mad - > mad_hdr . attr_id = = CM_REQ_ATTR_ID | |
2020-08-03 09:19:37 +03:00
mad - > mad_hdr . attr_id = = CM_REP_ATTR_ID | |
mad - > mad_hdr . attr_id = = CM_MRA_ATTR_ID | |
IB/mlx4: Add support for REJ due to timeout
A CM REJ packet with its reason equal to timeout is a special beast in the
sense that it doesn't have a Remote Communication ID nor does it have a
Remote Port GID.
Using CX-3 virtual functions, either from a bare-metal machine or
pass-through from a VM, MAD packets are proxied through the PF driver.
Since the VF drivers have separate name spaces for MAD Transaction Ids
(TIDs), the PF driver has to re-map the TIDs and keep the book keeping
in a cache.
This proxying doesn't not handle said REJ packets.
If the active side abandons its connection attempt after having sent a
REQ, it will send a REJ with the reason being timeout. This example can be
provoked by a simple user-verbs program, which ends up doing:
rdma_connect(cm_id, &conn_param);
rdma_destroy_id(cm_id);
using the async librdmacm API.
Having dynamic debug prints enabled in the mlx4_ib driver, we will then
see:
mlx4_ib_demux_cm_handler: Couldn't find an entry for pv_cm_id 0x0, attr_id 0x12
The solution is to introduce a radix-tree. When a REQ packet is received
and handled in mlx4_ib_demux_cm_handler(), we know the connecting peer's
para-virtual cm_id and the destination slave. We then insert an entry into
the tree with said information. We also schedule work to remove this entry
from the tree and free it, in order to avoid memory leak.
When a REJ packet with reason timeout is received, we can look up the
slave in the tree, and deliver the packet to the correct slave.
When a duplicate REQ packet is received, the entry is in the tree. In this
case, we adjust the delayed work in order to avoid a too premature
eviction of the entry.
When cleaning up, we simply traverse the tree and modify any delayed work
to use a zero delay. A subsequent flush of the system_wq will ensure all
entries being wiped out.
Fixes: 3cf69cc8dbeb ("IB/mlx4: Add CM paravirtualization")
Link: https://lore.kernel.org/r/20200803061941.1139994-6-haakon.bugge@oracle.com
Signed-off-by: Håkon Bugge <haakon.bugge@oracle.com>
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
2020-08-03 09:19:40 +03:00
mad - > mad_hdr . attr_id = = CM_SIDR_REQ_ATTR_ID | |
( mad - > mad_hdr . attr_id = = CM_REJ_ATTR_ID & & REJ_REASON ( mad ) = = IB_CM_REJ_TIMEOUT ) ) {
2014-03-12 14:00:42 +04:00
sl_cm_id = get_local_comm_id ( mad ) ;
2017-06-20 15:07:50 +03:00
id = id_map_get ( ibdev , & pv_cm_id , slave_id , sl_cm_id ) ;
if ( id )
goto cont ;
2012-08-03 12:40:47 +04:00
id = id_map_alloc ( ibdev , slave_id , sl_cm_id ) ;
if ( IS_ERR ( id ) ) {
mlx4_ib_warn ( ibdev , " %s: id{slave: %d, sl_cm_id: 0x%x} Failed to id_map_alloc \n " ,
__func__ , slave_id , sl_cm_id ) ;
return PTR_ERR ( id ) ;
}
2014-03-12 14:00:42 +04:00
} else if ( mad - > mad_hdr . attr_id = = CM_REJ_ATTR_ID | |
mad - > mad_hdr . attr_id = = CM_SIDR_REP_ATTR_ID ) {
2012-08-03 12:40:47 +04:00
return 0 ;
} else {
2014-03-12 14:00:42 +04:00
sl_cm_id = get_local_comm_id ( mad ) ;
2012-08-03 12:40:47 +04:00
id = id_map_get ( ibdev , & pv_cm_id , slave_id , sl_cm_id ) ;
}
if ( ! id ) {
2020-08-03 09:19:36 +03:00
pr_debug ( " id{slave: %d, sl_cm_id: 0x%x} is NULL! attr_id: 0x%x \n " ,
slave_id , sl_cm_id , be16_to_cpu ( mad - > mad_hdr . attr_id ) ) ;
2012-08-03 12:40:47 +04:00
return - EINVAL ;
}
2017-06-20 15:07:50 +03:00
cont :
2012-08-03 12:40:47 +04:00
set_local_comm_id ( mad , id - > pv_cm_id ) ;
if ( mad - > mad_hdr . attr_id = = CM_DREQ_ATTR_ID )
schedule_delayed ( ibdev , id ) ;
return 0 ;
}
IB/mlx4: Add support for REJ due to timeout
A CM REJ packet with its reason equal to timeout is a special beast in the
sense that it doesn't have a Remote Communication ID nor does it have a
Remote Port GID.
Using CX-3 virtual functions, either from a bare-metal machine or
pass-through from a VM, MAD packets are proxied through the PF driver.
Since the VF drivers have separate name spaces for MAD Transaction Ids
(TIDs), the PF driver has to re-map the TIDs and keep the book keeping
in a cache.
This proxying doesn't not handle said REJ packets.
If the active side abandons its connection attempt after having sent a
REQ, it will send a REJ with the reason being timeout. This example can be
provoked by a simple user-verbs program, which ends up doing:
rdma_connect(cm_id, &conn_param);
rdma_destroy_id(cm_id);
using the async librdmacm API.
Having dynamic debug prints enabled in the mlx4_ib driver, we will then
see:
mlx4_ib_demux_cm_handler: Couldn't find an entry for pv_cm_id 0x0, attr_id 0x12
The solution is to introduce a radix-tree. When a REQ packet is received
and handled in mlx4_ib_demux_cm_handler(), we know the connecting peer's
para-virtual cm_id and the destination slave. We then insert an entry into
the tree with said information. We also schedule work to remove this entry
from the tree and free it, in order to avoid memory leak.
When a REJ packet with reason timeout is received, we can look up the
slave in the tree, and deliver the packet to the correct slave.
When a duplicate REQ packet is received, the entry is in the tree. In this
case, we adjust the delayed work in order to avoid a too premature
eviction of the entry.
When cleaning up, we simply traverse the tree and modify any delayed work
to use a zero delay. A subsequent flush of the system_wq will ensure all
entries being wiped out.
Fixes: 3cf69cc8dbeb ("IB/mlx4: Add CM paravirtualization")
Link: https://lore.kernel.org/r/20200803061941.1139994-6-haakon.bugge@oracle.com
Signed-off-by: Håkon Bugge <haakon.bugge@oracle.com>
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
2020-08-03 09:19:40 +03:00
static void rej_tmout_timeout ( struct work_struct * work )
{
struct delayed_work * delay = to_delayed_work ( work ) ;
struct rej_tmout_entry * item = container_of ( delay , struct rej_tmout_entry , timeout ) ;
struct rej_tmout_entry * deleted ;
2020-10-09 17:24:42 +03:00
deleted = xa_cmpxchg ( item - > xa_rej_tmout , item - > rem_pv_cm_id , item , NULL , 0 ) ;
IB/mlx4: Add support for REJ due to timeout
A CM REJ packet with its reason equal to timeout is a special beast in the
sense that it doesn't have a Remote Communication ID nor does it have a
Remote Port GID.
Using CX-3 virtual functions, either from a bare-metal machine or
pass-through from a VM, MAD packets are proxied through the PF driver.
Since the VF drivers have separate name spaces for MAD Transaction Ids
(TIDs), the PF driver has to re-map the TIDs and keep the book keeping
in a cache.
This proxying doesn't not handle said REJ packets.
If the active side abandons its connection attempt after having sent a
REQ, it will send a REJ with the reason being timeout. This example can be
provoked by a simple user-verbs program, which ends up doing:
rdma_connect(cm_id, &conn_param);
rdma_destroy_id(cm_id);
using the async librdmacm API.
Having dynamic debug prints enabled in the mlx4_ib driver, we will then
see:
mlx4_ib_demux_cm_handler: Couldn't find an entry for pv_cm_id 0x0, attr_id 0x12
The solution is to introduce a radix-tree. When a REQ packet is received
and handled in mlx4_ib_demux_cm_handler(), we know the connecting peer's
para-virtual cm_id and the destination slave. We then insert an entry into
the tree with said information. We also schedule work to remove this entry
from the tree and free it, in order to avoid memory leak.
When a REJ packet with reason timeout is received, we can look up the
slave in the tree, and deliver the packet to the correct slave.
When a duplicate REQ packet is received, the entry is in the tree. In this
case, we adjust the delayed work in order to avoid a too premature
eviction of the entry.
When cleaning up, we simply traverse the tree and modify any delayed work
to use a zero delay. A subsequent flush of the system_wq will ensure all
entries being wiped out.
Fixes: 3cf69cc8dbeb ("IB/mlx4: Add CM paravirtualization")
Link: https://lore.kernel.org/r/20200803061941.1139994-6-haakon.bugge@oracle.com
Signed-off-by: Håkon Bugge <haakon.bugge@oracle.com>
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
2020-08-03 09:19:40 +03:00
if ( deleted ! = item )
pr_debug ( " deleted(%p) != item(%p) \n " , deleted , item ) ;
kfree ( item ) ;
}
static int alloc_rej_tmout ( struct mlx4_ib_sriov * sriov , u32 rem_pv_cm_id , int slave )
{
struct rej_tmout_entry * item ;
2020-10-09 17:24:42 +03:00
struct rej_tmout_entry * old ;
int ret = 0 ;
xa_lock ( & sriov - > xa_rej_tmout ) ;
item = xa_load ( & sriov - > xa_rej_tmout , ( unsigned long ) rem_pv_cm_id ) ;
IB/mlx4: Add support for REJ due to timeout
A CM REJ packet with its reason equal to timeout is a special beast in the
sense that it doesn't have a Remote Communication ID nor does it have a
Remote Port GID.
Using CX-3 virtual functions, either from a bare-metal machine or
pass-through from a VM, MAD packets are proxied through the PF driver.
Since the VF drivers have separate name spaces for MAD Transaction Ids
(TIDs), the PF driver has to re-map the TIDs and keep the book keeping
in a cache.
This proxying doesn't not handle said REJ packets.
If the active side abandons its connection attempt after having sent a
REQ, it will send a REJ with the reason being timeout. This example can be
provoked by a simple user-verbs program, which ends up doing:
rdma_connect(cm_id, &conn_param);
rdma_destroy_id(cm_id);
using the async librdmacm API.
Having dynamic debug prints enabled in the mlx4_ib driver, we will then
see:
mlx4_ib_demux_cm_handler: Couldn't find an entry for pv_cm_id 0x0, attr_id 0x12
The solution is to introduce a radix-tree. When a REQ packet is received
and handled in mlx4_ib_demux_cm_handler(), we know the connecting peer's
para-virtual cm_id and the destination slave. We then insert an entry into
the tree with said information. We also schedule work to remove this entry
from the tree and free it, in order to avoid memory leak.
When a REJ packet with reason timeout is received, we can look up the
slave in the tree, and deliver the packet to the correct slave.
When a duplicate REQ packet is received, the entry is in the tree. In this
case, we adjust the delayed work in order to avoid a too premature
eviction of the entry.
When cleaning up, we simply traverse the tree and modify any delayed work
to use a zero delay. A subsequent flush of the system_wq will ensure all
entries being wiped out.
Fixes: 3cf69cc8dbeb ("IB/mlx4: Add CM paravirtualization")
Link: https://lore.kernel.org/r/20200803061941.1139994-6-haakon.bugge@oracle.com
Signed-off-by: Håkon Bugge <haakon.bugge@oracle.com>
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
2020-08-03 09:19:40 +03:00
if ( item ) {
2020-10-09 17:24:42 +03:00
if ( xa_err ( item ) )
ret = xa_err ( item ) ;
else
/* If a retry, adjust delayed work */
mod_delayed_work ( system_wq , & item - > timeout , CM_CLEANUP_CACHE_TIMEOUT ) ;
goto err_or_exists ;
IB/mlx4: Add support for REJ due to timeout
A CM REJ packet with its reason equal to timeout is a special beast in the
sense that it doesn't have a Remote Communication ID nor does it have a
Remote Port GID.
Using CX-3 virtual functions, either from a bare-metal machine or
pass-through from a VM, MAD packets are proxied through the PF driver.
Since the VF drivers have separate name spaces for MAD Transaction Ids
(TIDs), the PF driver has to re-map the TIDs and keep the book keeping
in a cache.
This proxying doesn't not handle said REJ packets.
If the active side abandons its connection attempt after having sent a
REQ, it will send a REJ with the reason being timeout. This example can be
provoked by a simple user-verbs program, which ends up doing:
rdma_connect(cm_id, &conn_param);
rdma_destroy_id(cm_id);
using the async librdmacm API.
Having dynamic debug prints enabled in the mlx4_ib driver, we will then
see:
mlx4_ib_demux_cm_handler: Couldn't find an entry for pv_cm_id 0x0, attr_id 0x12
The solution is to introduce a radix-tree. When a REQ packet is received
and handled in mlx4_ib_demux_cm_handler(), we know the connecting peer's
para-virtual cm_id and the destination slave. We then insert an entry into
the tree with said information. We also schedule work to remove this entry
from the tree and free it, in order to avoid memory leak.
When a REJ packet with reason timeout is received, we can look up the
slave in the tree, and deliver the packet to the correct slave.
When a duplicate REQ packet is received, the entry is in the tree. In this
case, we adjust the delayed work in order to avoid a too premature
eviction of the entry.
When cleaning up, we simply traverse the tree and modify any delayed work
to use a zero delay. A subsequent flush of the system_wq will ensure all
entries being wiped out.
Fixes: 3cf69cc8dbeb ("IB/mlx4: Add CM paravirtualization")
Link: https://lore.kernel.org/r/20200803061941.1139994-6-haakon.bugge@oracle.com
Signed-off-by: Håkon Bugge <haakon.bugge@oracle.com>
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
2020-08-03 09:19:40 +03:00
}
2020-10-09 17:24:42 +03:00
xa_unlock ( & sriov - > xa_rej_tmout ) ;
IB/mlx4: Add support for REJ due to timeout
A CM REJ packet with its reason equal to timeout is a special beast in the
sense that it doesn't have a Remote Communication ID nor does it have a
Remote Port GID.
Using CX-3 virtual functions, either from a bare-metal machine or
pass-through from a VM, MAD packets are proxied through the PF driver.
Since the VF drivers have separate name spaces for MAD Transaction Ids
(TIDs), the PF driver has to re-map the TIDs and keep the book keeping
in a cache.
This proxying doesn't not handle said REJ packets.
If the active side abandons its connection attempt after having sent a
REQ, it will send a REJ with the reason being timeout. This example can be
provoked by a simple user-verbs program, which ends up doing:
rdma_connect(cm_id, &conn_param);
rdma_destroy_id(cm_id);
using the async librdmacm API.
Having dynamic debug prints enabled in the mlx4_ib driver, we will then
see:
mlx4_ib_demux_cm_handler: Couldn't find an entry for pv_cm_id 0x0, attr_id 0x12
The solution is to introduce a radix-tree. When a REQ packet is received
and handled in mlx4_ib_demux_cm_handler(), we know the connecting peer's
para-virtual cm_id and the destination slave. We then insert an entry into
the tree with said information. We also schedule work to remove this entry
from the tree and free it, in order to avoid memory leak.
When a REJ packet with reason timeout is received, we can look up the
slave in the tree, and deliver the packet to the correct slave.
When a duplicate REQ packet is received, the entry is in the tree. In this
case, we adjust the delayed work in order to avoid a too premature
eviction of the entry.
When cleaning up, we simply traverse the tree and modify any delayed work
to use a zero delay. A subsequent flush of the system_wq will ensure all
entries being wiped out.
Fixes: 3cf69cc8dbeb ("IB/mlx4: Add CM paravirtualization")
Link: https://lore.kernel.org/r/20200803061941.1139994-6-haakon.bugge@oracle.com
Signed-off-by: Håkon Bugge <haakon.bugge@oracle.com>
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
2020-08-03 09:19:40 +03:00
item = kmalloc ( sizeof ( * item ) , GFP_KERNEL ) ;
if ( ! item )
return - ENOMEM ;
INIT_DELAYED_WORK ( & item - > timeout , rej_tmout_timeout ) ;
item - > slave = slave ;
item - > rem_pv_cm_id = rem_pv_cm_id ;
2020-10-09 17:24:42 +03:00
item - > xa_rej_tmout = & sriov - > xa_rej_tmout ;
old = xa_cmpxchg ( & sriov - > xa_rej_tmout , ( unsigned long ) rem_pv_cm_id , NULL , item , GFP_KERNEL ) ;
if ( old ) {
pr_debug (
" Non-null old entry (%p) or error (%d) when inserting \n " ,
old , xa_err ( old ) ) ;
kfree ( item ) ;
return xa_err ( old ) ;
}
IB/mlx4: Add support for REJ due to timeout
A CM REJ packet with its reason equal to timeout is a special beast in the
sense that it doesn't have a Remote Communication ID nor does it have a
Remote Port GID.
Using CX-3 virtual functions, either from a bare-metal machine or
pass-through from a VM, MAD packets are proxied through the PF driver.
Since the VF drivers have separate name spaces for MAD Transaction Ids
(TIDs), the PF driver has to re-map the TIDs and keep the book keeping
in a cache.
This proxying doesn't not handle said REJ packets.
If the active side abandons its connection attempt after having sent a
REQ, it will send a REJ with the reason being timeout. This example can be
provoked by a simple user-verbs program, which ends up doing:
rdma_connect(cm_id, &conn_param);
rdma_destroy_id(cm_id);
using the async librdmacm API.
Having dynamic debug prints enabled in the mlx4_ib driver, we will then
see:
mlx4_ib_demux_cm_handler: Couldn't find an entry for pv_cm_id 0x0, attr_id 0x12
The solution is to introduce a radix-tree. When a REQ packet is received
and handled in mlx4_ib_demux_cm_handler(), we know the connecting peer's
para-virtual cm_id and the destination slave. We then insert an entry into
the tree with said information. We also schedule work to remove this entry
from the tree and free it, in order to avoid memory leak.
When a REJ packet with reason timeout is received, we can look up the
slave in the tree, and deliver the packet to the correct slave.
When a duplicate REQ packet is received, the entry is in the tree. In this
case, we adjust the delayed work in order to avoid a too premature
eviction of the entry.
When cleaning up, we simply traverse the tree and modify any delayed work
to use a zero delay. A subsequent flush of the system_wq will ensure all
entries being wiped out.
Fixes: 3cf69cc8dbeb ("IB/mlx4: Add CM paravirtualization")
Link: https://lore.kernel.org/r/20200803061941.1139994-6-haakon.bugge@oracle.com
Signed-off-by: Håkon Bugge <haakon.bugge@oracle.com>
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
2020-08-03 09:19:40 +03:00
schedule_delayed_work ( & item - > timeout , CM_CLEANUP_CACHE_TIMEOUT ) ;
return 0 ;
2020-10-09 17:24:42 +03:00
err_or_exists :
xa_unlock ( & sriov - > xa_rej_tmout ) ;
return ret ;
IB/mlx4: Add support for REJ due to timeout
A CM REJ packet with its reason equal to timeout is a special beast in the
sense that it doesn't have a Remote Communication ID nor does it have a
Remote Port GID.
Using CX-3 virtual functions, either from a bare-metal machine or
pass-through from a VM, MAD packets are proxied through the PF driver.
Since the VF drivers have separate name spaces for MAD Transaction Ids
(TIDs), the PF driver has to re-map the TIDs and keep the book keeping
in a cache.
This proxying doesn't not handle said REJ packets.
If the active side abandons its connection attempt after having sent a
REQ, it will send a REJ with the reason being timeout. This example can be
provoked by a simple user-verbs program, which ends up doing:
rdma_connect(cm_id, &conn_param);
rdma_destroy_id(cm_id);
using the async librdmacm API.
Having dynamic debug prints enabled in the mlx4_ib driver, we will then
see:
mlx4_ib_demux_cm_handler: Couldn't find an entry for pv_cm_id 0x0, attr_id 0x12
The solution is to introduce a radix-tree. When a REQ packet is received
and handled in mlx4_ib_demux_cm_handler(), we know the connecting peer's
para-virtual cm_id and the destination slave. We then insert an entry into
the tree with said information. We also schedule work to remove this entry
from the tree and free it, in order to avoid memory leak.
When a REJ packet with reason timeout is received, we can look up the
slave in the tree, and deliver the packet to the correct slave.
When a duplicate REQ packet is received, the entry is in the tree. In this
case, we adjust the delayed work in order to avoid a too premature
eviction of the entry.
When cleaning up, we simply traverse the tree and modify any delayed work
to use a zero delay. A subsequent flush of the system_wq will ensure all
entries being wiped out.
Fixes: 3cf69cc8dbeb ("IB/mlx4: Add CM paravirtualization")
Link: https://lore.kernel.org/r/20200803061941.1139994-6-haakon.bugge@oracle.com
Signed-off-by: Håkon Bugge <haakon.bugge@oracle.com>
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
2020-08-03 09:19:40 +03:00
}
static int lookup_rej_tmout_slave ( struct mlx4_ib_sriov * sriov , u32 rem_pv_cm_id )
{
struct rej_tmout_entry * item ;
2020-10-09 17:24:42 +03:00
int slave ;
IB/mlx4: Add support for REJ due to timeout
A CM REJ packet with its reason equal to timeout is a special beast in the
sense that it doesn't have a Remote Communication ID nor does it have a
Remote Port GID.
Using CX-3 virtual functions, either from a bare-metal machine or
pass-through from a VM, MAD packets are proxied through the PF driver.
Since the VF drivers have separate name spaces for MAD Transaction Ids
(TIDs), the PF driver has to re-map the TIDs and keep the book keeping
in a cache.
This proxying doesn't not handle said REJ packets.
If the active side abandons its connection attempt after having sent a
REQ, it will send a REJ with the reason being timeout. This example can be
provoked by a simple user-verbs program, which ends up doing:
rdma_connect(cm_id, &conn_param);
rdma_destroy_id(cm_id);
using the async librdmacm API.
Having dynamic debug prints enabled in the mlx4_ib driver, we will then
see:
mlx4_ib_demux_cm_handler: Couldn't find an entry for pv_cm_id 0x0, attr_id 0x12
The solution is to introduce a radix-tree. When a REQ packet is received
and handled in mlx4_ib_demux_cm_handler(), we know the connecting peer's
para-virtual cm_id and the destination slave. We then insert an entry into
the tree with said information. We also schedule work to remove this entry
from the tree and free it, in order to avoid memory leak.
When a REJ packet with reason timeout is received, we can look up the
slave in the tree, and deliver the packet to the correct slave.
When a duplicate REQ packet is received, the entry is in the tree. In this
case, we adjust the delayed work in order to avoid a too premature
eviction of the entry.
When cleaning up, we simply traverse the tree and modify any delayed work
to use a zero delay. A subsequent flush of the system_wq will ensure all
entries being wiped out.
Fixes: 3cf69cc8dbeb ("IB/mlx4: Add CM paravirtualization")
Link: https://lore.kernel.org/r/20200803061941.1139994-6-haakon.bugge@oracle.com
Signed-off-by: Håkon Bugge <haakon.bugge@oracle.com>
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
2020-08-03 09:19:40 +03:00
2020-10-09 17:24:42 +03:00
xa_lock ( & sriov - > xa_rej_tmout ) ;
item = xa_load ( & sriov - > xa_rej_tmout , ( unsigned long ) rem_pv_cm_id ) ;
IB/mlx4: Add support for REJ due to timeout
A CM REJ packet with its reason equal to timeout is a special beast in the
sense that it doesn't have a Remote Communication ID nor does it have a
Remote Port GID.
Using CX-3 virtual functions, either from a bare-metal machine or
pass-through from a VM, MAD packets are proxied through the PF driver.
Since the VF drivers have separate name spaces for MAD Transaction Ids
(TIDs), the PF driver has to re-map the TIDs and keep the book keeping
in a cache.
This proxying doesn't not handle said REJ packets.
If the active side abandons its connection attempt after having sent a
REQ, it will send a REJ with the reason being timeout. This example can be
provoked by a simple user-verbs program, which ends up doing:
rdma_connect(cm_id, &conn_param);
rdma_destroy_id(cm_id);
using the async librdmacm API.
Having dynamic debug prints enabled in the mlx4_ib driver, we will then
see:
mlx4_ib_demux_cm_handler: Couldn't find an entry for pv_cm_id 0x0, attr_id 0x12
The solution is to introduce a radix-tree. When a REQ packet is received
and handled in mlx4_ib_demux_cm_handler(), we know the connecting peer's
para-virtual cm_id and the destination slave. We then insert an entry into
the tree with said information. We also schedule work to remove this entry
from the tree and free it, in order to avoid memory leak.
When a REJ packet with reason timeout is received, we can look up the
slave in the tree, and deliver the packet to the correct slave.
When a duplicate REQ packet is received, the entry is in the tree. In this
case, we adjust the delayed work in order to avoid a too premature
eviction of the entry.
When cleaning up, we simply traverse the tree and modify any delayed work
to use a zero delay. A subsequent flush of the system_wq will ensure all
entries being wiped out.
Fixes: 3cf69cc8dbeb ("IB/mlx4: Add CM paravirtualization")
Link: https://lore.kernel.org/r/20200803061941.1139994-6-haakon.bugge@oracle.com
Signed-off-by: Håkon Bugge <haakon.bugge@oracle.com>
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
2020-08-03 09:19:40 +03:00
2020-10-09 17:24:42 +03:00
if ( ! item | | xa_err ( item ) ) {
IB/mlx4: Add support for REJ due to timeout
A CM REJ packet with its reason equal to timeout is a special beast in the
sense that it doesn't have a Remote Communication ID nor does it have a
Remote Port GID.
Using CX-3 virtual functions, either from a bare-metal machine or
pass-through from a VM, MAD packets are proxied through the PF driver.
Since the VF drivers have separate name spaces for MAD Transaction Ids
(TIDs), the PF driver has to re-map the TIDs and keep the book keeping
in a cache.
This proxying doesn't not handle said REJ packets.
If the active side abandons its connection attempt after having sent a
REQ, it will send a REJ with the reason being timeout. This example can be
provoked by a simple user-verbs program, which ends up doing:
rdma_connect(cm_id, &conn_param);
rdma_destroy_id(cm_id);
using the async librdmacm API.
Having dynamic debug prints enabled in the mlx4_ib driver, we will then
see:
mlx4_ib_demux_cm_handler: Couldn't find an entry for pv_cm_id 0x0, attr_id 0x12
The solution is to introduce a radix-tree. When a REQ packet is received
and handled in mlx4_ib_demux_cm_handler(), we know the connecting peer's
para-virtual cm_id and the destination slave. We then insert an entry into
the tree with said information. We also schedule work to remove this entry
from the tree and free it, in order to avoid memory leak.
When a REJ packet with reason timeout is received, we can look up the
slave in the tree, and deliver the packet to the correct slave.
When a duplicate REQ packet is received, the entry is in the tree. In this
case, we adjust the delayed work in order to avoid a too premature
eviction of the entry.
When cleaning up, we simply traverse the tree and modify any delayed work
to use a zero delay. A subsequent flush of the system_wq will ensure all
entries being wiped out.
Fixes: 3cf69cc8dbeb ("IB/mlx4: Add CM paravirtualization")
Link: https://lore.kernel.org/r/20200803061941.1139994-6-haakon.bugge@oracle.com
Signed-off-by: Håkon Bugge <haakon.bugge@oracle.com>
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
2020-08-03 09:19:40 +03:00
pr_debug ( " Could not find slave. rem_pv_cm_id 0x%x error: %d \n " ,
2020-10-09 17:24:42 +03:00
rem_pv_cm_id , xa_err ( item ) ) ;
slave = ! item ? - ENOENT : xa_err ( item ) ;
} else {
slave = item - > slave ;
IB/mlx4: Add support for REJ due to timeout
A CM REJ packet with its reason equal to timeout is a special beast in the
sense that it doesn't have a Remote Communication ID nor does it have a
Remote Port GID.
Using CX-3 virtual functions, either from a bare-metal machine or
pass-through from a VM, MAD packets are proxied through the PF driver.
Since the VF drivers have separate name spaces for MAD Transaction Ids
(TIDs), the PF driver has to re-map the TIDs and keep the book keeping
in a cache.
This proxying doesn't not handle said REJ packets.
If the active side abandons its connection attempt after having sent a
REQ, it will send a REJ with the reason being timeout. This example can be
provoked by a simple user-verbs program, which ends up doing:
rdma_connect(cm_id, &conn_param);
rdma_destroy_id(cm_id);
using the async librdmacm API.
Having dynamic debug prints enabled in the mlx4_ib driver, we will then
see:
mlx4_ib_demux_cm_handler: Couldn't find an entry for pv_cm_id 0x0, attr_id 0x12
The solution is to introduce a radix-tree. When a REQ packet is received
and handled in mlx4_ib_demux_cm_handler(), we know the connecting peer's
para-virtual cm_id and the destination slave. We then insert an entry into
the tree with said information. We also schedule work to remove this entry
from the tree and free it, in order to avoid memory leak.
When a REJ packet with reason timeout is received, we can look up the
slave in the tree, and deliver the packet to the correct slave.
When a duplicate REQ packet is received, the entry is in the tree. In this
case, we adjust the delayed work in order to avoid a too premature
eviction of the entry.
When cleaning up, we simply traverse the tree and modify any delayed work
to use a zero delay. A subsequent flush of the system_wq will ensure all
entries being wiped out.
Fixes: 3cf69cc8dbeb ("IB/mlx4: Add CM paravirtualization")
Link: https://lore.kernel.org/r/20200803061941.1139994-6-haakon.bugge@oracle.com
Signed-off-by: Håkon Bugge <haakon.bugge@oracle.com>
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
2020-08-03 09:19:40 +03:00
}
2020-10-09 17:24:42 +03:00
xa_unlock ( & sriov - > xa_rej_tmout ) ;
IB/mlx4: Add support for REJ due to timeout
A CM REJ packet with its reason equal to timeout is a special beast in the
sense that it doesn't have a Remote Communication ID nor does it have a
Remote Port GID.
Using CX-3 virtual functions, either from a bare-metal machine or
pass-through from a VM, MAD packets are proxied through the PF driver.
Since the VF drivers have separate name spaces for MAD Transaction Ids
(TIDs), the PF driver has to re-map the TIDs and keep the book keeping
in a cache.
This proxying doesn't not handle said REJ packets.
If the active side abandons its connection attempt after having sent a
REQ, it will send a REJ with the reason being timeout. This example can be
provoked by a simple user-verbs program, which ends up doing:
rdma_connect(cm_id, &conn_param);
rdma_destroy_id(cm_id);
using the async librdmacm API.
Having dynamic debug prints enabled in the mlx4_ib driver, we will then
see:
mlx4_ib_demux_cm_handler: Couldn't find an entry for pv_cm_id 0x0, attr_id 0x12
The solution is to introduce a radix-tree. When a REQ packet is received
and handled in mlx4_ib_demux_cm_handler(), we know the connecting peer's
para-virtual cm_id and the destination slave. We then insert an entry into
the tree with said information. We also schedule work to remove this entry
from the tree and free it, in order to avoid memory leak.
When a REJ packet with reason timeout is received, we can look up the
slave in the tree, and deliver the packet to the correct slave.
When a duplicate REQ packet is received, the entry is in the tree. In this
case, we adjust the delayed work in order to avoid a too premature
eviction of the entry.
When cleaning up, we simply traverse the tree and modify any delayed work
to use a zero delay. A subsequent flush of the system_wq will ensure all
entries being wiped out.
Fixes: 3cf69cc8dbeb ("IB/mlx4: Add CM paravirtualization")
Link: https://lore.kernel.org/r/20200803061941.1139994-6-haakon.bugge@oracle.com
Signed-off-by: Håkon Bugge <haakon.bugge@oracle.com>
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
2020-08-03 09:19:40 +03:00
2020-10-09 17:24:42 +03:00
return slave ;
IB/mlx4: Add support for REJ due to timeout
A CM REJ packet with its reason equal to timeout is a special beast in the
sense that it doesn't have a Remote Communication ID nor does it have a
Remote Port GID.
Using CX-3 virtual functions, either from a bare-metal machine or
pass-through from a VM, MAD packets are proxied through the PF driver.
Since the VF drivers have separate name spaces for MAD Transaction Ids
(TIDs), the PF driver has to re-map the TIDs and keep the book keeping
in a cache.
This proxying doesn't not handle said REJ packets.
If the active side abandons its connection attempt after having sent a
REQ, it will send a REJ with the reason being timeout. This example can be
provoked by a simple user-verbs program, which ends up doing:
rdma_connect(cm_id, &conn_param);
rdma_destroy_id(cm_id);
using the async librdmacm API.
Having dynamic debug prints enabled in the mlx4_ib driver, we will then
see:
mlx4_ib_demux_cm_handler: Couldn't find an entry for pv_cm_id 0x0, attr_id 0x12
The solution is to introduce a radix-tree. When a REQ packet is received
and handled in mlx4_ib_demux_cm_handler(), we know the connecting peer's
para-virtual cm_id and the destination slave. We then insert an entry into
the tree with said information. We also schedule work to remove this entry
from the tree and free it, in order to avoid memory leak.
When a REJ packet with reason timeout is received, we can look up the
slave in the tree, and deliver the packet to the correct slave.
When a duplicate REQ packet is received, the entry is in the tree. In this
case, we adjust the delayed work in order to avoid a too premature
eviction of the entry.
When cleaning up, we simply traverse the tree and modify any delayed work
to use a zero delay. A subsequent flush of the system_wq will ensure all
entries being wiped out.
Fixes: 3cf69cc8dbeb ("IB/mlx4: Add CM paravirtualization")
Link: https://lore.kernel.org/r/20200803061941.1139994-6-haakon.bugge@oracle.com
Signed-off-by: Håkon Bugge <haakon.bugge@oracle.com>
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
2020-08-03 09:19:40 +03:00
}
2012-08-03 12:40:47 +04:00
int mlx4_ib_demux_cm_handler ( struct ib_device * ibdev , int port , int * slave ,
2014-03-12 14:00:37 +04:00
struct ib_mad * mad )
2012-08-03 12:40:47 +04:00
{
IB/mlx4: Add support for REJ due to timeout
A CM REJ packet with its reason equal to timeout is a special beast in the
sense that it doesn't have a Remote Communication ID nor does it have a
Remote Port GID.
Using CX-3 virtual functions, either from a bare-metal machine or
pass-through from a VM, MAD packets are proxied through the PF driver.
Since the VF drivers have separate name spaces for MAD Transaction Ids
(TIDs), the PF driver has to re-map the TIDs and keep the book keeping
in a cache.
This proxying doesn't not handle said REJ packets.
If the active side abandons its connection attempt after having sent a
REQ, it will send a REJ with the reason being timeout. This example can be
provoked by a simple user-verbs program, which ends up doing:
rdma_connect(cm_id, &conn_param);
rdma_destroy_id(cm_id);
using the async librdmacm API.
Having dynamic debug prints enabled in the mlx4_ib driver, we will then
see:
mlx4_ib_demux_cm_handler: Couldn't find an entry for pv_cm_id 0x0, attr_id 0x12
The solution is to introduce a radix-tree. When a REQ packet is received
and handled in mlx4_ib_demux_cm_handler(), we know the connecting peer's
para-virtual cm_id and the destination slave. We then insert an entry into
the tree with said information. We also schedule work to remove this entry
from the tree and free it, in order to avoid memory leak.
When a REJ packet with reason timeout is received, we can look up the
slave in the tree, and deliver the packet to the correct slave.
When a duplicate REQ packet is received, the entry is in the tree. In this
case, we adjust the delayed work in order to avoid a too premature
eviction of the entry.
When cleaning up, we simply traverse the tree and modify any delayed work
to use a zero delay. A subsequent flush of the system_wq will ensure all
entries being wiped out.
Fixes: 3cf69cc8dbeb ("IB/mlx4: Add CM paravirtualization")
Link: https://lore.kernel.org/r/20200803061941.1139994-6-haakon.bugge@oracle.com
Signed-off-by: Håkon Bugge <haakon.bugge@oracle.com>
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
2020-08-03 09:19:40 +03:00
struct mlx4_ib_sriov * sriov = & to_mdev ( ibdev ) - > sriov ;
u32 rem_pv_cm_id = get_local_comm_id ( mad ) ;
2012-08-03 12:40:47 +04:00
u32 pv_cm_id ;
struct id_map_entry * id ;
IB/mlx4: Add support for REJ due to timeout
A CM REJ packet with its reason equal to timeout is a special beast in the
sense that it doesn't have a Remote Communication ID nor does it have a
Remote Port GID.
Using CX-3 virtual functions, either from a bare-metal machine or
pass-through from a VM, MAD packets are proxied through the PF driver.
Since the VF drivers have separate name spaces for MAD Transaction Ids
(TIDs), the PF driver has to re-map the TIDs and keep the book keeping
in a cache.
This proxying doesn't not handle said REJ packets.
If the active side abandons its connection attempt after having sent a
REQ, it will send a REJ with the reason being timeout. This example can be
provoked by a simple user-verbs program, which ends up doing:
rdma_connect(cm_id, &conn_param);
rdma_destroy_id(cm_id);
using the async librdmacm API.
Having dynamic debug prints enabled in the mlx4_ib driver, we will then
see:
mlx4_ib_demux_cm_handler: Couldn't find an entry for pv_cm_id 0x0, attr_id 0x12
The solution is to introduce a radix-tree. When a REQ packet is received
and handled in mlx4_ib_demux_cm_handler(), we know the connecting peer's
para-virtual cm_id and the destination slave. We then insert an entry into
the tree with said information. We also schedule work to remove this entry
from the tree and free it, in order to avoid memory leak.
When a REJ packet with reason timeout is received, we can look up the
slave in the tree, and deliver the packet to the correct slave.
When a duplicate REQ packet is received, the entry is in the tree. In this
case, we adjust the delayed work in order to avoid a too premature
eviction of the entry.
When cleaning up, we simply traverse the tree and modify any delayed work
to use a zero delay. A subsequent flush of the system_wq will ensure all
entries being wiped out.
Fixes: 3cf69cc8dbeb ("IB/mlx4: Add CM paravirtualization")
Link: https://lore.kernel.org/r/20200803061941.1139994-6-haakon.bugge@oracle.com
Signed-off-by: Håkon Bugge <haakon.bugge@oracle.com>
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
2020-08-03 09:19:40 +03:00
int sts ;
2012-08-03 12:40:47 +04:00
2014-03-12 14:00:42 +04:00
if ( mad - > mad_hdr . attr_id = = CM_REQ_ATTR_ID | |
mad - > mad_hdr . attr_id = = CM_SIDR_REQ_ATTR_ID ) {
2012-08-03 12:40:47 +04:00
union ib_gid gid ;
2014-03-12 14:00:37 +04:00
if ( ! slave )
return 0 ;
2012-08-03 12:40:47 +04:00
gid = gid_from_req_msg ( ibdev , mad ) ;
* slave = mlx4_ib_find_real_gid ( ibdev , port , gid . global . interface_id ) ;
if ( * slave < 0 ) {
mlx4_ib_warn ( ibdev , " failed matching slave_id by gid (0x%llx) \n " ,
2015-01-29 11:41:43 +03:00
be64_to_cpu ( gid . global . interface_id ) ) ;
2012-08-03 12:40:47 +04:00
return - ENOENT ;
}
IB/mlx4: Add support for REJ due to timeout
A CM REJ packet with its reason equal to timeout is a special beast in the
sense that it doesn't have a Remote Communication ID nor does it have a
Remote Port GID.
Using CX-3 virtual functions, either from a bare-metal machine or
pass-through from a VM, MAD packets are proxied through the PF driver.
Since the VF drivers have separate name spaces for MAD Transaction Ids
(TIDs), the PF driver has to re-map the TIDs and keep the book keeping
in a cache.
This proxying doesn't not handle said REJ packets.
If the active side abandons its connection attempt after having sent a
REQ, it will send a REJ with the reason being timeout. This example can be
provoked by a simple user-verbs program, which ends up doing:
rdma_connect(cm_id, &conn_param);
rdma_destroy_id(cm_id);
using the async librdmacm API.
Having dynamic debug prints enabled in the mlx4_ib driver, we will then
see:
mlx4_ib_demux_cm_handler: Couldn't find an entry for pv_cm_id 0x0, attr_id 0x12
The solution is to introduce a radix-tree. When a REQ packet is received
and handled in mlx4_ib_demux_cm_handler(), we know the connecting peer's
para-virtual cm_id and the destination slave. We then insert an entry into
the tree with said information. We also schedule work to remove this entry
from the tree and free it, in order to avoid memory leak.
When a REJ packet with reason timeout is received, we can look up the
slave in the tree, and deliver the packet to the correct slave.
When a duplicate REQ packet is received, the entry is in the tree. In this
case, we adjust the delayed work in order to avoid a too premature
eviction of the entry.
When cleaning up, we simply traverse the tree and modify any delayed work
to use a zero delay. A subsequent flush of the system_wq will ensure all
entries being wiped out.
Fixes: 3cf69cc8dbeb ("IB/mlx4: Add CM paravirtualization")
Link: https://lore.kernel.org/r/20200803061941.1139994-6-haakon.bugge@oracle.com
Signed-off-by: Håkon Bugge <haakon.bugge@oracle.com>
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
2020-08-03 09:19:40 +03:00
sts = alloc_rej_tmout ( sriov , rem_pv_cm_id , * slave ) ;
if ( sts )
/* Even if this fails, we pass on the REQ to the slave */
pr_debug ( " Could not allocate rej_tmout entry. rem_pv_cm_id 0x%x slave %d status %d \n " ,
rem_pv_cm_id , * slave , sts ) ;
2012-08-03 12:40:47 +04:00
return 0 ;
}
pv_cm_id = get_remote_comm_id ( mad ) ;
id = id_map_get ( ibdev , ( int * ) & pv_cm_id , - 1 , - 1 ) ;
if ( ! id ) {
IB/mlx4: Add support for REJ due to timeout
A CM REJ packet with its reason equal to timeout is a special beast in the
sense that it doesn't have a Remote Communication ID nor does it have a
Remote Port GID.
Using CX-3 virtual functions, either from a bare-metal machine or
pass-through from a VM, MAD packets are proxied through the PF driver.
Since the VF drivers have separate name spaces for MAD Transaction Ids
(TIDs), the PF driver has to re-map the TIDs and keep the book keeping
in a cache.
This proxying doesn't not handle said REJ packets.
If the active side abandons its connection attempt after having sent a
REQ, it will send a REJ with the reason being timeout. This example can be
provoked by a simple user-verbs program, which ends up doing:
rdma_connect(cm_id, &conn_param);
rdma_destroy_id(cm_id);
using the async librdmacm API.
Having dynamic debug prints enabled in the mlx4_ib driver, we will then
see:
mlx4_ib_demux_cm_handler: Couldn't find an entry for pv_cm_id 0x0, attr_id 0x12
The solution is to introduce a radix-tree. When a REQ packet is received
and handled in mlx4_ib_demux_cm_handler(), we know the connecting peer's
para-virtual cm_id and the destination slave. We then insert an entry into
the tree with said information. We also schedule work to remove this entry
from the tree and free it, in order to avoid memory leak.
When a REJ packet with reason timeout is received, we can look up the
slave in the tree, and deliver the packet to the correct slave.
When a duplicate REQ packet is received, the entry is in the tree. In this
case, we adjust the delayed work in order to avoid a too premature
eviction of the entry.
When cleaning up, we simply traverse the tree and modify any delayed work
to use a zero delay. A subsequent flush of the system_wq will ensure all
entries being wiped out.
Fixes: 3cf69cc8dbeb ("IB/mlx4: Add CM paravirtualization")
Link: https://lore.kernel.org/r/20200803061941.1139994-6-haakon.bugge@oracle.com
Signed-off-by: Håkon Bugge <haakon.bugge@oracle.com>
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
2020-08-03 09:19:40 +03:00
if ( mad - > mad_hdr . attr_id = = CM_REJ_ATTR_ID & &
REJ_REASON ( mad ) = = IB_CM_REJ_TIMEOUT & & slave ) {
* slave = lookup_rej_tmout_slave ( sriov , rem_pv_cm_id ) ;
return ( * slave < 0 ) ? * slave : 0 ;
}
2020-08-03 09:19:36 +03:00
pr_debug ( " Couldn't find an entry for pv_cm_id 0x%x, attr_id 0x%x \n " ,
pv_cm_id , be16_to_cpu ( mad - > mad_hdr . attr_id ) ) ;
2012-08-03 12:40:47 +04:00
return - ENOENT ;
}
2014-03-12 14:00:37 +04:00
if ( slave )
* slave = id - > slave_id ;
2012-08-03 12:40:47 +04:00
set_remote_comm_id ( mad , id - > sl_cm_id ) ;
IB/mlx4: Fix leak in id_map_find_del
Using CX-3 virtual functions, either from a bare-metal machine or
pass-through from a VM, MAD packets are proxied through the PF driver.
Since the VF drivers have separate name spaces for MAD Transaction Ids
(TIDs), the PF driver has to re-map the TIDs and keep the book keeping in
a cache.
Following the RDMA Connection Manager (CM) protocol, it is clear when an
entry has to evicted from the cache. When a DREP is sent from
mlx4_ib_multiplex_cm_handler(), id_map_find_del() is called. Similar when
a REJ is received by the mlx4_ib_demux_cm_handler(), id_map_find_del() is
called.
This function wipes out the TID in use from the IDR or XArray and removes
the id_map_entry from the table.
In short, it does everything except the topping of the cake, which is to
remove the entry from the list and free it. In other words, for the REJ
case enumerated above, one id_map_entry will be leaked.
For the other case above, a DREQ has been received first. The reception of
the DREQ will trigger queuing of a delayed work to delete the
id_map_entry, for the case where the VM doesn't send back a DREP.
In the normal case, the VM _will_ send back a DREP, and id_map_find_del()
will be called.
But this scenario introduces a secondary leak. First, when the DREQ is
received, a delayed work is queued. The VM will then return a DREP, which
will call id_map_find_del(). As stated above, this will free the TID used
from the XArray or IDR. Now, there is window where that particular TID can
be re-allocated, lets say by an outgoing REQ. This TID will later be wiped
out by the delayed work, when the function id_map_ent_timeout() is
called. But the id_map_entry allocated by the outgoing REQ will not be
de-allocated, and we have a leak.
Both leaks are fixed by removing the id_map_find_del() function and only
using schedule_delayed(). Of course, a check in schedule_delayed() to see
if the work already has been queued, has been added.
Another benefit of always using the delayed version for deleting entries,
is that we do get a TimeWait effect; a TID no longer in use, will occupy
the XArray or IDR for CM_CLEANUP_CACHE_TIMEOUT time, without any ability
of being re-used for that time period.
Fixes: 3cf69cc8dbeb ("IB/mlx4: Add CM paravirtualization")
Link: https://lore.kernel.org/r/20200123155521.1212288-1-haakon.bugge@oracle.com
Signed-off-by: Håkon Bugge <haakon.bugge@oracle.com>
Signed-off-by: Manjunath Patil <manjunath.b.patil@oracle.com>
Reviewed-by: Rama Nichanamatlu <rama.nichanamatlu@oracle.com>
Reviewed-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
2020-01-23 18:55:21 +03:00
if ( mad - > mad_hdr . attr_id = = CM_DREQ_ATTR_ID | |
mad - > mad_hdr . attr_id = = CM_REJ_ATTR_ID )
2012-08-03 12:40:47 +04:00
schedule_delayed ( ibdev , id ) ;
return 0 ;
}
void mlx4_ib_cm_paravirt_init ( struct mlx4_ib_dev * dev )
{
spin_lock_init ( & dev - > sriov . id_map_lock ) ;
INIT_LIST_HEAD ( & dev - > sriov . cm_list ) ;
dev - > sriov . sl_id_map = RB_ROOT ;
2019-02-21 03:20:44 +03:00
xa_init_flags ( & dev - > sriov . pv_id_table , XA_FLAGS_ALLOC ) ;
2020-10-09 17:24:42 +03:00
xa_init ( & dev - > sriov . xa_rej_tmout ) ;
IB/mlx4: Add support for REJ due to timeout
A CM REJ packet with its reason equal to timeout is a special beast in the
sense that it doesn't have a Remote Communication ID nor does it have a
Remote Port GID.
Using CX-3 virtual functions, either from a bare-metal machine or
pass-through from a VM, MAD packets are proxied through the PF driver.
Since the VF drivers have separate name spaces for MAD Transaction Ids
(TIDs), the PF driver has to re-map the TIDs and keep the book keeping
in a cache.
This proxying doesn't not handle said REJ packets.
If the active side abandons its connection attempt after having sent a
REQ, it will send a REJ with the reason being timeout. This example can be
provoked by a simple user-verbs program, which ends up doing:
rdma_connect(cm_id, &conn_param);
rdma_destroy_id(cm_id);
using the async librdmacm API.
Having dynamic debug prints enabled in the mlx4_ib driver, we will then
see:
mlx4_ib_demux_cm_handler: Couldn't find an entry for pv_cm_id 0x0, attr_id 0x12
The solution is to introduce a radix-tree. When a REQ packet is received
and handled in mlx4_ib_demux_cm_handler(), we know the connecting peer's
para-virtual cm_id and the destination slave. We then insert an entry into
the tree with said information. We also schedule work to remove this entry
from the tree and free it, in order to avoid memory leak.
When a REJ packet with reason timeout is received, we can look up the
slave in the tree, and deliver the packet to the correct slave.
When a duplicate REQ packet is received, the entry is in the tree. In this
case, we adjust the delayed work in order to avoid a too premature
eviction of the entry.
When cleaning up, we simply traverse the tree and modify any delayed work
to use a zero delay. A subsequent flush of the system_wq will ensure all
entries being wiped out.
Fixes: 3cf69cc8dbeb ("IB/mlx4: Add CM paravirtualization")
Link: https://lore.kernel.org/r/20200803061941.1139994-6-haakon.bugge@oracle.com
Signed-off-by: Håkon Bugge <haakon.bugge@oracle.com>
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
2020-08-03 09:19:40 +03:00
}
2020-10-09 17:24:42 +03:00
static void rej_tmout_xa_cleanup ( struct mlx4_ib_sriov * sriov , int slave )
IB/mlx4: Add support for REJ due to timeout
A CM REJ packet with its reason equal to timeout is a special beast in the
sense that it doesn't have a Remote Communication ID nor does it have a
Remote Port GID.
Using CX-3 virtual functions, either from a bare-metal machine or
pass-through from a VM, MAD packets are proxied through the PF driver.
Since the VF drivers have separate name spaces for MAD Transaction Ids
(TIDs), the PF driver has to re-map the TIDs and keep the book keeping
in a cache.
This proxying doesn't not handle said REJ packets.
If the active side abandons its connection attempt after having sent a
REQ, it will send a REJ with the reason being timeout. This example can be
provoked by a simple user-verbs program, which ends up doing:
rdma_connect(cm_id, &conn_param);
rdma_destroy_id(cm_id);
using the async librdmacm API.
Having dynamic debug prints enabled in the mlx4_ib driver, we will then
see:
mlx4_ib_demux_cm_handler: Couldn't find an entry for pv_cm_id 0x0, attr_id 0x12
The solution is to introduce a radix-tree. When a REQ packet is received
and handled in mlx4_ib_demux_cm_handler(), we know the connecting peer's
para-virtual cm_id and the destination slave. We then insert an entry into
the tree with said information. We also schedule work to remove this entry
from the tree and free it, in order to avoid memory leak.
When a REJ packet with reason timeout is received, we can look up the
slave in the tree, and deliver the packet to the correct slave.
When a duplicate REQ packet is received, the entry is in the tree. In this
case, we adjust the delayed work in order to avoid a too premature
eviction of the entry.
When cleaning up, we simply traverse the tree and modify any delayed work
to use a zero delay. A subsequent flush of the system_wq will ensure all
entries being wiped out.
Fixes: 3cf69cc8dbeb ("IB/mlx4: Add CM paravirtualization")
Link: https://lore.kernel.org/r/20200803061941.1139994-6-haakon.bugge@oracle.com
Signed-off-by: Håkon Bugge <haakon.bugge@oracle.com>
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
2020-08-03 09:19:40 +03:00
{
2020-10-09 17:24:42 +03:00
struct rej_tmout_entry * item ;
IB/mlx4: Add support for REJ due to timeout
A CM REJ packet with its reason equal to timeout is a special beast in the
sense that it doesn't have a Remote Communication ID nor does it have a
Remote Port GID.
Using CX-3 virtual functions, either from a bare-metal machine or
pass-through from a VM, MAD packets are proxied through the PF driver.
Since the VF drivers have separate name spaces for MAD Transaction Ids
(TIDs), the PF driver has to re-map the TIDs and keep the book keeping
in a cache.
This proxying doesn't not handle said REJ packets.
If the active side abandons its connection attempt after having sent a
REQ, it will send a REJ with the reason being timeout. This example can be
provoked by a simple user-verbs program, which ends up doing:
rdma_connect(cm_id, &conn_param);
rdma_destroy_id(cm_id);
using the async librdmacm API.
Having dynamic debug prints enabled in the mlx4_ib driver, we will then
see:
mlx4_ib_demux_cm_handler: Couldn't find an entry for pv_cm_id 0x0, attr_id 0x12
The solution is to introduce a radix-tree. When a REQ packet is received
and handled in mlx4_ib_demux_cm_handler(), we know the connecting peer's
para-virtual cm_id and the destination slave. We then insert an entry into
the tree with said information. We also schedule work to remove this entry
from the tree and free it, in order to avoid memory leak.
When a REJ packet with reason timeout is received, we can look up the
slave in the tree, and deliver the packet to the correct slave.
When a duplicate REQ packet is received, the entry is in the tree. In this
case, we adjust the delayed work in order to avoid a too premature
eviction of the entry.
When cleaning up, we simply traverse the tree and modify any delayed work
to use a zero delay. A subsequent flush of the system_wq will ensure all
entries being wiped out.
Fixes: 3cf69cc8dbeb ("IB/mlx4: Add CM paravirtualization")
Link: https://lore.kernel.org/r/20200803061941.1139994-6-haakon.bugge@oracle.com
Signed-off-by: Håkon Bugge <haakon.bugge@oracle.com>
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
2020-08-03 09:19:40 +03:00
bool flush_needed = false ;
2020-10-09 17:24:42 +03:00
unsigned long id ;
IB/mlx4: Add support for REJ due to timeout
A CM REJ packet with its reason equal to timeout is a special beast in the
sense that it doesn't have a Remote Communication ID nor does it have a
Remote Port GID.
Using CX-3 virtual functions, either from a bare-metal machine or
pass-through from a VM, MAD packets are proxied through the PF driver.
Since the VF drivers have separate name spaces for MAD Transaction Ids
(TIDs), the PF driver has to re-map the TIDs and keep the book keeping
in a cache.
This proxying doesn't not handle said REJ packets.
If the active side abandons its connection attempt after having sent a
REQ, it will send a REJ with the reason being timeout. This example can be
provoked by a simple user-verbs program, which ends up doing:
rdma_connect(cm_id, &conn_param);
rdma_destroy_id(cm_id);
using the async librdmacm API.
Having dynamic debug prints enabled in the mlx4_ib driver, we will then
see:
mlx4_ib_demux_cm_handler: Couldn't find an entry for pv_cm_id 0x0, attr_id 0x12
The solution is to introduce a radix-tree. When a REQ packet is received
and handled in mlx4_ib_demux_cm_handler(), we know the connecting peer's
para-virtual cm_id and the destination slave. We then insert an entry into
the tree with said information. We also schedule work to remove this entry
from the tree and free it, in order to avoid memory leak.
When a REJ packet with reason timeout is received, we can look up the
slave in the tree, and deliver the packet to the correct slave.
When a duplicate REQ packet is received, the entry is in the tree. In this
case, we adjust the delayed work in order to avoid a too premature
eviction of the entry.
When cleaning up, we simply traverse the tree and modify any delayed work
to use a zero delay. A subsequent flush of the system_wq will ensure all
entries being wiped out.
Fixes: 3cf69cc8dbeb ("IB/mlx4: Add CM paravirtualization")
Link: https://lore.kernel.org/r/20200803061941.1139994-6-haakon.bugge@oracle.com
Signed-off-by: Håkon Bugge <haakon.bugge@oracle.com>
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
2020-08-03 09:19:40 +03:00
int cnt = 0 ;
2020-10-09 17:24:42 +03:00
xa_lock ( & sriov - > xa_rej_tmout ) ;
xa_for_each ( & sriov - > xa_rej_tmout , id , item ) {
IB/mlx4: Add support for REJ due to timeout
A CM REJ packet with its reason equal to timeout is a special beast in the
sense that it doesn't have a Remote Communication ID nor does it have a
Remote Port GID.
Using CX-3 virtual functions, either from a bare-metal machine or
pass-through from a VM, MAD packets are proxied through the PF driver.
Since the VF drivers have separate name spaces for MAD Transaction Ids
(TIDs), the PF driver has to re-map the TIDs and keep the book keeping
in a cache.
This proxying doesn't not handle said REJ packets.
If the active side abandons its connection attempt after having sent a
REQ, it will send a REJ with the reason being timeout. This example can be
provoked by a simple user-verbs program, which ends up doing:
rdma_connect(cm_id, &conn_param);
rdma_destroy_id(cm_id);
using the async librdmacm API.
Having dynamic debug prints enabled in the mlx4_ib driver, we will then
see:
mlx4_ib_demux_cm_handler: Couldn't find an entry for pv_cm_id 0x0, attr_id 0x12
The solution is to introduce a radix-tree. When a REQ packet is received
and handled in mlx4_ib_demux_cm_handler(), we know the connecting peer's
para-virtual cm_id and the destination slave. We then insert an entry into
the tree with said information. We also schedule work to remove this entry
from the tree and free it, in order to avoid memory leak.
When a REJ packet with reason timeout is received, we can look up the
slave in the tree, and deliver the packet to the correct slave.
When a duplicate REQ packet is received, the entry is in the tree. In this
case, we adjust the delayed work in order to avoid a too premature
eviction of the entry.
When cleaning up, we simply traverse the tree and modify any delayed work
to use a zero delay. A subsequent flush of the system_wq will ensure all
entries being wiped out.
Fixes: 3cf69cc8dbeb ("IB/mlx4: Add CM paravirtualization")
Link: https://lore.kernel.org/r/20200803061941.1139994-6-haakon.bugge@oracle.com
Signed-off-by: Håkon Bugge <haakon.bugge@oracle.com>
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
2020-08-03 09:19:40 +03:00
if ( slave < 0 | | slave = = item - > slave ) {
mod_delayed_work ( system_wq , & item - > timeout , 0 ) ;
flush_needed = true ;
+ + cnt ;
}
}
2020-10-09 17:24:42 +03:00
xa_unlock ( & sriov - > xa_rej_tmout ) ;
IB/mlx4: Add support for REJ due to timeout
A CM REJ packet with its reason equal to timeout is a special beast in the
sense that it doesn't have a Remote Communication ID nor does it have a
Remote Port GID.
Using CX-3 virtual functions, either from a bare-metal machine or
pass-through from a VM, MAD packets are proxied through the PF driver.
Since the VF drivers have separate name spaces for MAD Transaction Ids
(TIDs), the PF driver has to re-map the TIDs and keep the book keeping
in a cache.
This proxying doesn't not handle said REJ packets.
If the active side abandons its connection attempt after having sent a
REQ, it will send a REJ with the reason being timeout. This example can be
provoked by a simple user-verbs program, which ends up doing:
rdma_connect(cm_id, &conn_param);
rdma_destroy_id(cm_id);
using the async librdmacm API.
Having dynamic debug prints enabled in the mlx4_ib driver, we will then
see:
mlx4_ib_demux_cm_handler: Couldn't find an entry for pv_cm_id 0x0, attr_id 0x12
The solution is to introduce a radix-tree. When a REQ packet is received
and handled in mlx4_ib_demux_cm_handler(), we know the connecting peer's
para-virtual cm_id and the destination slave. We then insert an entry into
the tree with said information. We also schedule work to remove this entry
from the tree and free it, in order to avoid memory leak.
When a REJ packet with reason timeout is received, we can look up the
slave in the tree, and deliver the packet to the correct slave.
When a duplicate REQ packet is received, the entry is in the tree. In this
case, we adjust the delayed work in order to avoid a too premature
eviction of the entry.
When cleaning up, we simply traverse the tree and modify any delayed work
to use a zero delay. A subsequent flush of the system_wq will ensure all
entries being wiped out.
Fixes: 3cf69cc8dbeb ("IB/mlx4: Add CM paravirtualization")
Link: https://lore.kernel.org/r/20200803061941.1139994-6-haakon.bugge@oracle.com
Signed-off-by: Håkon Bugge <haakon.bugge@oracle.com>
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
2020-08-03 09:19:40 +03:00
if ( flush_needed ) {
flush_scheduled_work ( ) ;
2020-10-09 17:24:42 +03:00
pr_debug ( " Deleted %d entries in xarray for slave %d during cleanup \n " ,
cnt , slave ) ;
IB/mlx4: Add support for REJ due to timeout
A CM REJ packet with its reason equal to timeout is a special beast in the
sense that it doesn't have a Remote Communication ID nor does it have a
Remote Port GID.
Using CX-3 virtual functions, either from a bare-metal machine or
pass-through from a VM, MAD packets are proxied through the PF driver.
Since the VF drivers have separate name spaces for MAD Transaction Ids
(TIDs), the PF driver has to re-map the TIDs and keep the book keeping
in a cache.
This proxying doesn't not handle said REJ packets.
If the active side abandons its connection attempt after having sent a
REQ, it will send a REJ with the reason being timeout. This example can be
provoked by a simple user-verbs program, which ends up doing:
rdma_connect(cm_id, &conn_param);
rdma_destroy_id(cm_id);
using the async librdmacm API.
Having dynamic debug prints enabled in the mlx4_ib driver, we will then
see:
mlx4_ib_demux_cm_handler: Couldn't find an entry for pv_cm_id 0x0, attr_id 0x12
The solution is to introduce a radix-tree. When a REQ packet is received
and handled in mlx4_ib_demux_cm_handler(), we know the connecting peer's
para-virtual cm_id and the destination slave. We then insert an entry into
the tree with said information. We also schedule work to remove this entry
from the tree and free it, in order to avoid memory leak.
When a REJ packet with reason timeout is received, we can look up the
slave in the tree, and deliver the packet to the correct slave.
When a duplicate REQ packet is received, the entry is in the tree. In this
case, we adjust the delayed work in order to avoid a too premature
eviction of the entry.
When cleaning up, we simply traverse the tree and modify any delayed work
to use a zero delay. A subsequent flush of the system_wq will ensure all
entries being wiped out.
Fixes: 3cf69cc8dbeb ("IB/mlx4: Add CM paravirtualization")
Link: https://lore.kernel.org/r/20200803061941.1139994-6-haakon.bugge@oracle.com
Signed-off-by: Håkon Bugge <haakon.bugge@oracle.com>
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
2020-08-03 09:19:40 +03:00
}
2020-10-09 17:24:42 +03:00
if ( slave < 0 )
WARN_ON ( ! xa_empty ( & sriov - > xa_rej_tmout ) ) ;
2012-08-03 12:40:47 +04:00
}
/* slave = -1 ==> all slaves */
/* TBD -- call paravirt clean for single slave. Need for slave RESET event */
void mlx4_ib_cm_paravirt_clean ( struct mlx4_ib_dev * dev , int slave )
{
struct mlx4_ib_sriov * sriov = & dev - > sriov ;
struct rb_root * sl_id_map = & sriov - > sl_id_map ;
struct list_head lh ;
struct rb_node * nd ;
2017-04-28 14:06:53 +03:00
int need_flush = 0 ;
2012-08-03 12:40:47 +04:00
struct id_map_entry * map , * tmp_map ;
/* cancel all delayed work queue entries */
INIT_LIST_HEAD ( & lh ) ;
spin_lock ( & sriov - > id_map_lock ) ;
list_for_each_entry_safe ( map , tmp_map , & dev - > sriov . cm_list , list ) {
if ( slave < 0 | | slave = = map - > slave_id ) {
if ( map - > scheduled_delete )
2017-04-28 14:06:53 +03:00
need_flush | = ! cancel_delayed_work ( & map - > timeout ) ;
2012-08-03 12:40:47 +04:00
}
}
spin_unlock ( & sriov - > id_map_lock ) ;
2017-04-28 14:06:53 +03:00
if ( need_flush )
2012-08-03 12:40:47 +04:00
flush_scheduled_work ( ) ; /* make sure all timers were flushed */
/* now, remove all leftover entries from databases*/
spin_lock ( & sriov - > id_map_lock ) ;
if ( slave < 0 ) {
while ( rb_first ( sl_id_map ) ) {
struct id_map_entry * ent =
rb_entry ( rb_first ( sl_id_map ) ,
struct id_map_entry , node ) ;
rb_erase ( & ent - > node , sl_id_map ) ;
2019-02-21 03:20:44 +03:00
xa_erase ( & sriov - > pv_id_table , ent - > pv_cm_id ) ;
2012-08-03 12:40:47 +04:00
}
list_splice_init ( & dev - > sriov . cm_list , & lh ) ;
} else {
/* first, move nodes belonging to slave to db remove list */
nd = rb_first ( sl_id_map ) ;
while ( nd ) {
struct id_map_entry * ent =
rb_entry ( nd , struct id_map_entry , node ) ;
nd = rb_next ( nd ) ;
if ( ent - > slave_id = = slave )
list_move_tail ( & ent - > list , & lh ) ;
}
/* remove those nodes from databases */
list_for_each_entry_safe ( map , tmp_map , & lh , list ) {
rb_erase ( & map - > node , sl_id_map ) ;
2019-02-21 03:20:44 +03:00
xa_erase ( & sriov - > pv_id_table , map - > pv_cm_id ) ;
2012-08-03 12:40:47 +04:00
}
/* add remaining nodes from cm_list */
list_for_each_entry_safe ( map , tmp_map , & dev - > sriov . cm_list , list ) {
if ( slave = = map - > slave_id )
list_move_tail ( & map - > list , & lh ) ;
}
}
spin_unlock ( & sriov - > id_map_lock ) ;
/* free any map entries left behind due to cancel_delayed_work above */
list_for_each_entry_safe ( map , tmp_map , & lh , list ) {
list_del ( & map - > list ) ;
kfree ( map ) ;
}
IB/mlx4: Add support for REJ due to timeout
A CM REJ packet with its reason equal to timeout is a special beast in the
sense that it doesn't have a Remote Communication ID nor does it have a
Remote Port GID.
Using CX-3 virtual functions, either from a bare-metal machine or
pass-through from a VM, MAD packets are proxied through the PF driver.
Since the VF drivers have separate name spaces for MAD Transaction Ids
(TIDs), the PF driver has to re-map the TIDs and keep the book keeping
in a cache.
This proxying doesn't not handle said REJ packets.
If the active side abandons its connection attempt after having sent a
REQ, it will send a REJ with the reason being timeout. This example can be
provoked by a simple user-verbs program, which ends up doing:
rdma_connect(cm_id, &conn_param);
rdma_destroy_id(cm_id);
using the async librdmacm API.
Having dynamic debug prints enabled in the mlx4_ib driver, we will then
see:
mlx4_ib_demux_cm_handler: Couldn't find an entry for pv_cm_id 0x0, attr_id 0x12
The solution is to introduce a radix-tree. When a REQ packet is received
and handled in mlx4_ib_demux_cm_handler(), we know the connecting peer's
para-virtual cm_id and the destination slave. We then insert an entry into
the tree with said information. We also schedule work to remove this entry
from the tree and free it, in order to avoid memory leak.
When a REJ packet with reason timeout is received, we can look up the
slave in the tree, and deliver the packet to the correct slave.
When a duplicate REQ packet is received, the entry is in the tree. In this
case, we adjust the delayed work in order to avoid a too premature
eviction of the entry.
When cleaning up, we simply traverse the tree and modify any delayed work
to use a zero delay. A subsequent flush of the system_wq will ensure all
entries being wiped out.
Fixes: 3cf69cc8dbeb ("IB/mlx4: Add CM paravirtualization")
Link: https://lore.kernel.org/r/20200803061941.1139994-6-haakon.bugge@oracle.com
Signed-off-by: Håkon Bugge <haakon.bugge@oracle.com>
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
2020-08-03 09:19:40 +03:00
2020-10-09 17:24:42 +03:00
rej_tmout_xa_cleanup ( sriov , slave ) ;
2012-08-03 12:40:47 +04:00
}