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

On Mon Aug 10, 2026 at 4:30 PM CEST, Keith Busch wrote:
> 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?

Hmm I see, considering that changing max_qid triggers resets
to all of the controllers, copying the value to the controllers'
structure should indeed fix all these unsafe accesses.

I will submit a V2.

Maurizio