[SCSI] libfc: in fc_lport_destroy, flush rports after turning off link
authorJoe Eykholt <jeykholt@cisco.com>
Thu, 30 Jul 2009 00:04:33 +0000 (17:04 -0700)
committerJames Bottomley <James.Bottomley@suse.de>
Sat, 22 Aug 2009 22:52:05 +0000 (17:52 -0500)
commite9ba8b427852937caee6ca39bb6f9a893bb32ae1
treede3db30488262ae451b61322d9166db99872b198
parent1190d925813aab80d17ff10f26c115f5846b3308
[SCSI] libfc: in fc_lport_destroy, flush rports after turning off link

During an fcoe module unload, we saw a problem where fc_rport_work()
finds the lport has been freed.  The rdata points to an area
containing 0x6b6b6b6b... the pool poison value from kmem_free().

In fcoe_if_destroy() we call fc_fabric_logoff() then fc_lport_destroy().
fc_fabric_logoff() flushes the remote port work, but we're still receiving
requests, and an RSCN or PLOGI arrives which creates more rports.

Note that although the LLD also checks link_up, it doesn't do it
under the lport mutex, so it can deliver frames to
fc_lport_recv_req() even after link_up is cleared.
So, re-check link_up there.

We need to flush the rports by calling disc_stop_final()
after we clear link_up.

Signed-off-by: Joe Eykholt <jeykholt@cisco.com>
Signed-off-by: Robert Love <robert.w.love@intel.com>
Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
Signed-off-by: James Bottomley <James.Bottomley@suse.de>
drivers/scsi/libfc/fc_lport.c