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

[Justin Tee]

> Aristeau's original stack trace was in nvme-fc (Initiator) though, I think.
Kind of sort of, the Last Breaking-Event-Address is on the target side
(target/fcloop.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

It just so happens the intended lsrsp->done(lsrsp) call is trying to
reach into nvme_fc (initiator) code because done is supposed to be set
to nvme_fc_xmt_ls_rsp_done.

Additionally, consistent reproduction on a x86_64 system yields a call
trace like below:

Oops: general protection fault, probably for non-canonical address
0xd3ea351027e1e8d8: 0000 [#1] SMP NOPTI

Workqueue: events nvme_fc_handle_ls_rqst_work [nvme_fc]
RIP: 0010:fcloop_t2h_xmt_ls_rsp+0xca/0x130 [nvme_fcloop]
Code: 8b 72 18 41 b8 f0 01 00 00 48 c7 c1 40 d0 a8 c0 48 c7 c2 fa d2
a8 c0 48 c7 c7 50 d4 a8 c0 e8 8d 58 7b f3 48 8b 43 18 48 89 df <ff> d0
0f 1f 00 b9 fd 01 00 00 48 c7 c2 40 d0 a8 c0 48 c7 c6 fa d2
RSP: 0018:ff50b14f0a9abd88 EFLAGS: 00010246
RAX: d3ea351027e1e8d8 RBX: ff2ab922d2016ef0 RCX: 0000000000000027
RDX: 0000000000000000 RSI: 0000000000000001 RDI: ff2ab922d2016ef0
RBP: 0000000000000000 R08: 0000000000000000 R09: ff50b14f0a9abc40
R10: ff50b14f0a9abc38 R11: ff2ab9323f9c6328 R12: ff2ab922d79bc000
R13: ff2ab922c59c0800 R14: 0800000002000000 R15: ff2ab922d79bc098
FS:  0000000000000000(0000) GS:ff2ab92a687fc000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 000055fecf7f6a60 CR3: 00000001116c0005 CR4: 0000000000773ef0
PKRU: 55555554
Call Trace:
 <TASK>
 nvme_fc_xmt_ls_rsp+0x46/0x90 [nvme_fc deaa37bfaf3bed135f3fe0a56933d272bbdc0340]
 nvme_fc_handle_ls_rqst_work+0xd0/0x650 [nvme_fc
deaa37bfaf3bed135f3fe0a56933d272bbdc0340]
 process_one_work+0x18e/0x3c0
 worker_thread+0x29d/0x3c0
 kthread+0xfc/0x210
 ret_from_fork+0x197/0x1d0
 ret_from_fork_asm+0x1a/0x30
 </TASK>


What’s happening is that rport->remoteport.port_state is not set to
FC_OBJSTATE_ONLINE so nvme_fc_handle_ls_rqst is not setting the
lsrsp->done function pointer to nvme_fc_xmt_ls_rsp_done.  So, when
target/fcloop.c calls lsrsp->done it’s crashing.

I have a patch in mind to resolve this, and will report back.