fc_remote_port_delete(9)

💅 fc_remote_port_delete — kernel API manual, but make it make sense

okay bestie, so you know that one function in the fibre channel transport that's like "hey, this remote port? gone. not a thing anymore"? yeah. that's her. this is fc_remote_port_delete from the Kernel API Manual, and honestly she's a whole vibe once you get what she's doing 🦋

---

✨ NAME ✨

fc_remote_port_delete — notifies the fc transport that a remote port is no longer in existence. she's the messenger, no cap 💌

---

🌸 SYNOPSIS 🌸

void fc_remote_port_delete (struct fc_rport *rport );

---

🎀 ARGUMENTS 🎀

• rport — the remote port that no longer exists. rip to her honestly, but she's still a struct fc_rport * on the way in 🫶

---

💜 DESCRIPTION 💜

so the LLDD calls this routine to notify the transport that a remote port is no longer part of the topology. that's the whole job. iconic.

but here's the tea: although a port may no longer be part of the topology, it may persist in the remote ports displayed by the fc_host. wild, right? we do this under 2 conditions:

1. if the port was a scsi target, we delay its deletion by "blocking" it 🔒. this lets the port temporarily disappear, then reappear without disrupting the SCSI device tree attached to it. during the "blocked" period the port will still exist. she's on a little break, not fired.
2. if the port was a scsi target and disappears for longer than we expect, we'll delete the port and tear down the SCSI device tree attached to it 😭. BUT — we want to semi-persist the target id assigned to that port if it eventually does exist. so the port structure will remain (although with minimal information) so that the target id bindings also remain. keeping the receipts, basically 🧾

if the remote port is not an FCP Target, it will be fully torn down and deallocated, including the fc_remote_port class device. full send. no leftovers.

if the remote port is an FCP Target, the port will be placed in a temporary blocked state 🚧. from the LLDD's perspective, the rport no longer exists. from the SCSI midlayer's perspective, the SCSI target exists, but all sdevs on it are blocked from further I/O. so both sides see a completely different situation, and honestly? relatable.

the following is then expected 👇

if the remote port does not return (signaled by a LLDD call to fc_remote_port_add) within the dev_loss_tmo timeout, then the scsi target is removed — killing all outstanding i/o and removing the scsi devices attached to it 💀. the port structure will be marked Not Present and be partially cleared, leaving only enough information to recognize the remote port relative to the scsi target id binding if it later appears. the port will remain as long as there is a valid binding (e.g. until the user changes the binding type or unloads the scsi host with the binding).

if the remote port does return within the dev_loss_tmo value (and matches according to the target id binding type), the port structure will be reused ♻️. if it is no longer a SCSI target, the target will be torn down. if it continues to be a SCSI target, then the target will be unblocked (allowing i/o to be resumed), and a scan will be activated to ensure that all luns are detected. welcome back queen 👑

big caveat, no jokes here: called from normal process context only — cannot be called from interrupt. like, seriously. do not. 🙅‍♀️

---

🫶 NOTES 🫶

this routine assumes no locks are held on entry. so, y'know. don't come in holding anything 🔓

---

🌈 SEE ALSO 🌈

kernel file ./drivers/scsi/scsi_transport_fc.c, plus the whole friend group:

fc_get_event_number(9), fc_host_post_fc_event(9), fc_host_post_event(9), fc_host_post_vendor_event(9), fc_find_rport_by_wwpn(9), fc_host_fpin_rcv(9), fc_eh_timed_out(9), fc_queue_work(9), fc_flush_work(9), fc_queue_devloss_work(9), fc_flush_devloss(9), fc_remove_host(9), fc_starget_delete(9), fc_rport_final_delete(9), fc_remote_port_create(9), fc_remote_port_add(9), fc_remote_port_rolechg(9), fc_timeout_deleted_rport(9), fc_timeout_fail_rport_io(9), fc_scsi_scan_rport(9), fc_block_rport(9), fc_block_scsi_eh(9), fc_vport_setup(9), fc_vport_create(9), fc_vport_terminate(9), fc_vport_sched_delete(9), fc_bsg_job_timeout(9), fc_bsg_host_dispatch(9), fc_bsg_rport_dispatch(9), fc_bsg_hostadd(9), fc_bsg_rportadd(9), fc_bsg_remove(9)

---

okay that's the whole page bestie, you're so caught up rn 🎀 this one lives under ./drivers/scsi and the version stamp says October 2026 — screenshot it for the group chat, mwah 💋✨