[PATCH] nvmet-fc: don't drop the last assoc reference in nvmet_fc_delete_ctrl()

[Daniel Wagner]

On Thu, Oct 08, 2026 at 08:18:48PM +0100, Palla Raghunath wrote:
> syzbot hit a recursive locking report on subsys->lock when a subsystem
> is unlinked from an FC port.
> 
> nvmet_port_del_ctrls() holds subsys->lock while it calls ->delete_ctrl()
> for each controller. nvmet_fc_delete_ctrl() grabs a reference on the
> association, queues del_work and then drops the reference. If del_work
> gets to run to completion before that put, ours is the last reference.
> Freeing the assoc tears down the queues, the last nvmet_cq_put() drops
> the last ctrl reference, and nvmet_ctrl_free() goes for subsys->lock
> again:
> 
>   WARNING: possible recursive locking detected
>   ...
>    nvmet_ctrl_free+0xa6/0x8e0 drivers/nvme/target/core.c:1766
>    nvmet_cq_put+0x158/0x200 drivers/nvme/target/core.c:848
>    nvmet_fc_target_assoc_free+0x418/0x2220 drivers/nvme/target/fc.c:1173
>    nvmet_fc_delete_ctrl+0x717/0x7e0 drivers/nvme/target/fc.c:1581
>    nvmet_port_del_ctrls+0xfb/0x150 drivers/nvme/target/core.c:311
>    nvmet_port_subsys_drop_link+0x1e8/0x310 drivers/nvme/target/configfs.c:1119
> 
> It's a real hang, not only a lockdep warning. I reproduced it with
> fcloop by putting an msleep() before the put: rm on the configfs link
> gets stuck in D state for good.
> 
> I don't think we need that reference at all.

Yes, you are correct. The reference does not protect from del_work
getting scheduled. Indeed this is buggy and your fix looks correct.

Thanks!

Reviewed-by: Daniel Wagner <dwagner at suse.de>