fcoe_ctlr_device_delete(9)

💖 NAME 💖

fcoe_ctlr_device_delete — bestie, this one deletes a FIP ctlr and its whole sysfs subtree, no cap ✨

So this is a fcoe_ctlr_device_delete(9) page from the Kernel API Manual, and we're about to get into it 💅

---

🦋 SYNOPSIS 🦋

void fcoe_ctlr_device_delete (struct fcoe_ctlr_device *ctlr );

---

🎀 ARGUMENTS 🎀

• ctlr — a pointer to the ctlr that's getting deleted, periodt 💖

---

✨ DESCRIPTION ✨

Okay so picture this: fcoe_ctlr_device_delete deletes a FIP ctlr and any fcfs attached to it. And the way deleting those fcfs works? Their children get deleted too — it's giving cascading main character energy 👑

The ctlr gets detached from sysfs and its resources are freed (work q), but the memory is not freed until its last reference is released. So like… the vibe is gone, but the memory is still lowkey hanging around until everybody lets go 🙈

This routine expects no locks to be held before calling. Zero. None. Don't do it, bestie 😭

TODO: currently there are no callbacks to clean up LLD data for a fcoe_fcf_device. LLDs must keep this in mind, because they need to clean up each of their LLD data for all fcoe_fcf_device before calling fcoe_ctlr_device_delete. This is important — don't skip the cleanup, fr fr 💀

---

🌈 SEE ALSO 🌈

• Kernel file ./drivers/scsi/fcoe/fcoe_sysfs.c
• fcoe_ctlr_device_release(9)
• fcoe_fcf_device_release(9)
• fcoe_ctlr_device_flush_work(9)
• fcoe_ctlr_device_queue_work(9)
• fcoe_ctlr_device_flush_devloss(9)
• fcoe_ctlr_device_queue_devloss_work(9)
• fcoe_ctlr_device_add(9)
• fcoe_fcf_device_final_delete(9)
• fip_timeout_deleted_fcf(9)
• fcoe_fcf_device_delete(9)
• fcoe_fcf_device_add(9)

---

Okay that's the whole page, bestie 🫶 this little icon comes straight from the ./drivers/scsi/fcoe corner of the kernel, version October 2026, and it's a whole fcoe_ctlr_device_delete(9) situation. Slay, stay lock-free, and clean up your LLD data before you call her 💜🎀