Re: [PATCH 4/6] nvmet: take subsys->lock in nvmet_subsys_attr_tbkas_store()

[Christoph Hellwig <hch@lst.de>]

On Fri, Nov 06, 2026 at 09:58:40AM +0800, Guixin Liu wrote:
> The tbkas store handler walks subsys->ctrls to force every controller
> to reconnect, but it holds only nvmet_config_sem for write.
> subsys->ctrls is protected by subsys->lock: nvmet_alloc_ctrl() adds an
> entry under subsys->lock, and nvmet_ctrl_free() removes it under
> subsys->lock with list_del() + kfree(). A concurrent controller
> teardown can therefore corrupt the walk.
> 
> This is the same bug fixed for nvmet_subsys_attr_qid_max_store() in
> commit 9f426f140511 ("nvmet: take subsys->lock while
> force-reconnecting in nvmet_subsys_attr_qid_max_store()"), which
> missed this second instance of the pattern. Take subsys->lock around
> the list_for_each_entry() loop. ->delete_ctrl() only queues
> asynchronous controller teardown, so it does not re-enter subsys->lock
> under the loop.
> 
> Fixes: e98e45e9465b ("nvmet: Add traffic based keep alive support to configfs")

I'm pretty sure I saw this fly by already in the last days.  If
that wasn't you we might already have something like this in the
queue.

If not:

Reviewed-by: Christoph Hellwig <hch@lst.de>