Re: [PATCH] nvmet: fix max_qid race between configfs and controller allocation

Keith Busch <[email protected]>
Newsgroups org.infradead.lists.linux-nvme
Message-ID <annggXmP2yS47QN4@kbusch-mbp>
On Mon, Aug 10, 2026 at 03:33:01PM +0200, Maurizio Lombardi wrote:
> Fix this by protecting the queue allocations and list insertion in
> nvmet_alloc_ctrl() with down_read(&nvmet_config_sem). Because
> nvmet_subsys_attr_qid_max_store() acquires down_write(&nvmet_config_sem)
> to modify the attribute, this safely prevents the configfs writer from
> modifying max_qid during controller creation.

I think there's still a race in nvmet_check_cqid() such that a command
can access an out-of-bounds index if the target side changes
subsys->max_qid to a larger value and the host sends a command with a
larger cqid than the array was initially allocated. Should the max_qid
be copied from the subystem to the controller that allocated the queue
array?
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.