summaryrefslogtreecommitdiff
path: root/drivers/net/ipa/data/ipa_data-v3.1.c
diff options
context:
space:
mode:
authorNick Child <nnac123@linux.ibm.com>2024-04-16 19:41:28 +0300
committerPaolo Abeni <pabeni@redhat.com>2024-04-18 13:13:38 +0300
commit5cb431dcf8048572e9ffc6c30cdbd8832cbe502d (patch)
tree926e7129e991439361cf7cd93a0c3b80525efd6a /drivers/net/ipa/data/ipa_data-v3.1.c
parenteabf425bc6ad32fa49cfb35c7bc59db07dfdd36e (diff)
downloadlinux-5cb431dcf8048572e9ffc6c30cdbd8832cbe502d.tar.xz
ibmvnic: Return error code on TX scrq flush fail
In ibmvnic_xmit() if ibmvnic_tx_scrq_flush() returns H_CLOSED then it will inform upper level networking functions to disable tx queues. H_CLOSED signals that the connection with the vnic server is down and a transport event is expected to recover the device. Previously, ibmvnic_tx_scrq_flush() was hard-coded to return success. Therefore, the queues would remain active until ibmvnic_cleanup() is called within do_reset(). The problem is that do_reset() depends on the RTNL lock. If several ibmvnic devices are resetting then there can be a long wait time until the last device can grab the lock. During this time the tx/rx queues still appear active to upper level functions. FYI, we do make a call to netif_carrier_off() outside the RTNL lock but its calls to dev_deactivate() are also dependent on the RTNL lock. As a result, large amounts of retransmissions were observed in a short period of time, eventually leading to ETIMEOUT. This was specifically seen with HNV devices, likely because of even more RTNL dependencies. Therefore, ensure the return code of ibmvnic_tx_scrq_flush() is propagated to the xmit function to allow for an earlier (and lock-less) response to a transport event. Signed-off-by: Nick Child <nnac123@linux.ibm.com> Link: https://lore.kernel.org/r/20240416164128.387920-1-nnac123@linux.ibm.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Diffstat (limited to 'drivers/net/ipa/data/ipa_data-v3.1.c')
0 files changed, 0 insertions, 0 deletions