[PATCH] nvme: fc: stop lsrcv workqueue before freeing a rport

[Justin Tee]

> Broadcom will have a deeper look into the call trace and will report back.
Providing a status update that Broadcom does not quite agree with the
proposed patch yet.  Specifically, because the crash occurs in
target/fcloop.c and not host/fc.c

    [12996.173750] Last Breaking-Event-Address:
    [12996.173750]  [<0000017ed7b594da>]
fcloop_t2h_xmt_ls_rsp+0x10a/0x140 [nvme_fcloop]
    [12996.173757] Kernel panic - not syncing: Fatal exception: panic_on_oops

If anything, the suggested cancel_work_sync(&rport->lsrcv_work) in
host/fc.c is delaying or avoiding the real issue.  And, I believe the
issue is related to the following commit:
“10c165af35d2 nvmet-fcloop: call done callback even when remote port is gone”

The panic occurs exactly during the lsrsp->done(lsrsp) call.  Are we
sure lsrsp is guaranteed to be valid when targetport is gone?
Broadcom will investigate the target/fcloop.c module some more and
report back again.

Regards,
Justin