nvmet_fc: support target port removal with nvmet layer
authorJames Smart <jsmart2021@gmail.com>
Thu, 9 Aug 2018 23:48:14 +0000 (16:48 -0700)
committerChristoph Hellwig <hch@lst.de>
Mon, 1 Oct 2018 21:16:10 +0000 (14:16 -0700)
commitea96d6496ff59b2b26dc9e13dc8f57d77731eb37
tree606bc12e197e733572932596703ff1061bbb6bfa
parentd4e4230c8f5646a19a0e58765a30fb2bab5f1dcc
nvmet_fc: support target port removal with nvmet layer

Currently, if a targetport has been connected to via the nvmet config
(in other words, the add_port() transport routine called, and the nvmet
port pointer stored for using in upcalls on new io), and if the
targetport is then removed (say the lldd driver decides to unload or
fully reset its hardware) and then re-added (the lldd driver reloads or
reinits its hardware), the port pointer has been lost so there's no way
to continue to post commands up to nvmet via the transport port.

Correct by allocating a small "port context" structure that will be
linked to by the targetport. The context will save the targetport WWN's
and the nvmet port pointer to use for it.  Initial allocation will occur
when the targetport is bound to via add_port.  The context will be
deallocated when remove_port() is called.  If a targetport is removed
while nvmet has the active port context, the targetport will be unlinked
from the port context before removal.  If a new targetport is registered,
the port contexts without a binding are looked through and if the WWN's
match (so it's the same as nvmet's port context) the port context is
linked to the new target port.  Thus new io can be received on the new
targetport and operation resumes with nvmet.

Additionally, this also resolves nvmet configuration changing out from
underneath of the nvme-fc target port (for example: a nvmetcli clear).

Signed-off-by: James Smart <james.smart@broadcom.com>
Signed-off-by: Christoph Hellwig <hch@lst.de>
drivers/nvme/target/fc.c