diff options
author | 2019-01-08 01:01:30 -0800 | |
---|---|---|
committer | 2019-01-23 17:16:59 -0700 | |
commit | 39d57757467b6346bbc1a1f416e3057f681cf903 (patch) | |
tree | c93e6d73f7499d73db7ff87edefbea35bf7a1d7f /tools/perf/scripts/python/export-to-sqlite.py | |
parent | nvme-rdma: fix timeout handler (diff) | |
download | wireguard-linux-39d57757467b6346bbc1a1f416e3057f681cf903.tar.xz wireguard-linux-39d57757467b6346bbc1a1f416e3057f681cf903.zip |
nvme-tcp: fix timeout handler
Currently, we have several problems with the timeout
handler:
1. If we timeout on the controller establishment flow, we will hang
because we don't execute the error recovery (and we shouldn't because
the create_ctrl flow needs to fail and cleanup on its own)
2. We might also hang if we get a disconnet on a queue while the
controller is already deleting. This racy flow can cause the controller
disable/shutdown admin command to hang.
We cannot complete a timed out request from the timeout handler without
mutual exclusion from the teardown flow (e.g. nvme_rdma_error_recovery_work).
So we serialize it in the timeout handler and teardown io and admin
queues to guarantee that no one races with us from completing the
request.
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Sagi Grimberg <sagi@grimberg.me>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Diffstat (limited to 'tools/perf/scripts/python/export-to-sqlite.py')
0 files changed, 0 insertions, 0 deletions