Searched hist:e9ba8b42 (Results 1 – 1 of 1) sorted by relevance
/openbmc/linux/drivers/scsi/libfc/ |
H A D | fc_lport.c | e9ba8b42 Wed Jul 29 19:04:33 CDT 2009 Joe Eykholt <jeykholt@cisco.com> [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> e9ba8b42 Wed Jul 29 19:04:33 CDT 2009 Joe Eykholt <jeykholt@cisco.com> [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>
|