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?