mirror of
https://github.com/AuxXxilium/linux_dsm_epyc7002.git
synced 2024-12-28 11:18:45 +07:00
ef4021fe5f
When the user tries to remove a zfcp port via sysfs, we only rejected it if there are zfcp unit children under the port. With purely automatically scanned LUNs there are no zfcp units but only SCSI devices. In such cases, the port_remove erroneously continued. We close the port and this implicitly closes all LUNs under the port. The SCSI devices survive with their private zfcp_scsi_dev still holding a reference to the "removed" zfcp_port (still allocated but invisible in sysfs) [zfcp_get_port_by_wwpn in zfcp_scsi_slave_alloc]. This is not a problem as long as the fc_rport stays blocked. Once (auto) port scan brings back the removed port, we unblock its fc_rport again by design. However, there is no mechanism that would recover (open) the LUNs under the port (no "ersfs_3" without zfcp_unit [zfcp_erp_strategy_followup_success]). Any pending or new I/O to such LUN leads to repeated: Done: NEEDS_RETRY Result: hostbyte=DID_IMM_RETRY driverbyte=DRIVER_OK See also v4.10 commit |
||
|---|---|---|
| .. | ||
| Makefile | ||
| zfcp_aux.c | ||
| zfcp_ccw.c | ||
| zfcp_dbf.c | ||
| zfcp_dbf.h | ||
| zfcp_def.h | ||
| zfcp_erp.c | ||
| zfcp_ext.h | ||
| zfcp_fc.c | ||
| zfcp_fc.h | ||
| zfcp_fsf.c | ||
| zfcp_fsf.h | ||
| zfcp_qdio.c | ||
| zfcp_qdio.h | ||
| zfcp_reqlist.h | ||
| zfcp_scsi.c | ||
| zfcp_sysfs.c | ||
| zfcp_unit.c | ||