Before we unload the module we should cleanup the fc resources first, basically reorder the shutdown sequence to be in reverse order of the setup path.
If this triggers a bug, then I think it is a good idea to have a dedicated test that reproduces it if we are changing the default behavior.
Also unload the nvme-fcloop after usage. While at it also update the rdma stop_soft_rdma before the module unloading for the same reasoning.
Why? it creates the wrong reverse ordering. 1. setup soft-rdma 2. setup nvme-rdma 2. teardown nvme-rdma 1. teardown soft-rdma I don't think we need this change. I mean it is a good test to have that the rdma device goes away underneath nvme-rdma but it is good for a dedicated test.
Signed-off-by: Daniel Wagner <dwagner@xxxxxxx> --- tests/nvme/rc | 12 +++++++----- 1 file changed, 7 insertions(+), 5 deletions(-) diff --git a/tests/nvme/rc b/tests/nvme/rc index ec0cc2d8d8cc..41f196b037d6 100644 --- a/tests/nvme/rc +++ b/tests/nvme/rc @@ -260,18 +260,20 @@ _cleanup_nvmet() { shopt -u nullglob trap SIGINT- modprobe -rq nvme-"${nvme_trtype}" 2>/dev/null- if [[ "${nvme_trtype}" != "loop" ]]; then - modprobe -rq nvmet-"${nvme_trtype}" 2>/dev/null - fi - modprobe -rq nvmet 2>/dev/null if [[ "${nvme_trtype}" == "rdma" ]]; then stop_soft_rdma fi if [[ "${nvme_trtype}" == "fc" ]]; then _cleanup_fcloop "${def_local_wwnn}" "${def_local_wwpn}" \ "${def_remote_wwnn}" "${def_remote_wwpn}" + modprobe -rq nvme-fcloop fi + + modprobe -rq nvme-"${nvme_trtype}" 2>/dev/null + if [[ "${nvme_trtype}" != "loop" ]]; then + modprobe -rq nvmet-"${nvme_trtype}" 2>/dev/null + fi + modprobe -rq nvmet 2>/dev/null }_setup_nvmet() {
