diff options
author | Wen Gu <guwen@linux.alibaba.com> | 2022-01-16 15:43:42 +0800 |
---|---|---|
committer | David S. Miller <davem@davemloft.net> | 2022-01-16 12:30:28 +0000 |
commit | 56d99e81ecbc997a5f984684d0eeb583992b2072 (patch) | |
tree | 4284ef0b3b561af97ab5bd2dd8a6686fe86f7420 /drivers/net/bonding | |
parent | 0a6e6b3c7db6c34e3d149f09cd714972f8753e3f (diff) | |
download | linux-stable-56d99e81ecbc997a5f984684d0eeb583992b2072.tar.gz linux-stable-56d99e81ecbc997a5f984684d0eeb583992b2072.tar.bz2 linux-stable-56d99e81ecbc997a5f984684d0eeb583992b2072.zip |
net/smc: Fix hung_task when removing SMC-R devices
A hung_task is observed when removing SMC-R devices. Suppose that
a link group has two active links(lnk_A, lnk_B) associated with two
different SMC-R devices(dev_A, dev_B). When dev_A is removed, the
link group will be removed from smc_lgr_list and added into
lgr_linkdown_list. lnk_A will be cleared and smcibdev(A)->lnk_cnt
will reach to zero. However, when dev_B is removed then, the link
group can't be found in smc_lgr_list and lnk_B won't be cleared,
making smcibdev->lnk_cnt never reaches zero, which causes a hung_task.
This patch fixes this issue by restoring the implementation of
smc_smcr_terminate_all() to what it was before commit 349d43127dac
("net/smc: fix kernel panic caused by race of smc_sock"). The original
implementation also satisfies the intention that make sure QP destroy
earlier than CQ destroy because we will always wait for smcibdev->lnk_cnt
reaches zero, which guarantees QP has been destroyed.
Fixes: 349d43127dac ("net/smc: fix kernel panic caused by race of smc_sock")
Signed-off-by: Wen Gu <guwen@linux.alibaba.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Diffstat (limited to 'drivers/net/bonding')
0 files changed, 0 insertions, 0 deletions