[PATCH v3 3/3] nvme-rdma: Handle number of queue changes

[Chao Leng]

On 2022/8/30 20:22, Chao Leng wrote:
> 
> 
> On 2022/8/30 16:21, Sagi Grimberg wrote:
>>
>>>> On Mon, Aug 29, 2022 at 05:22:50PM +0800, Chao Leng wrote:
>>>>>> +    ret = nvme_rdma_start_io_queues(ctrl, nr_queues,
>>>>>> +                    ctrl->tag_set.nr_hw_queues + 1);
>>>>>> +    if (ret)
>>>>>> +        goto out_wait_freeze_timed_out;
>>>>> nvme_rdma_start_io_queues(ctrl, 1, nr_queues) need to clean.
>>>>
>>>> the teardown path in nvme_rdma_stop_io_queus() is using
>>>>
>>>>     test_and_clear_bit(NVME_RDMA_Q_LIVE, &queue->flags)
>>>>
>>>> when iterating over all nr_hw_queues.
>>> I mean that we need realloc the ctrl->queues for
>>> nvme_rdma_start_io_queues(ctrl, 1, nr_queues).
>>> Otherwise, unallocated memory will be accessed when
>>> the new queue_count is bigger than the old one.
>>
>> That can't happen. ctrl->queues is allocated at the start
>> of the controller lifetime and will never exceed this queue
>> count.
> I don't understand why it can't happen.
> nvme_rdma_start_io_queues(ctrl, nr_queues, ctrl->tag_set.nr_hw_queues + 1)
> is designed for dealing with the scenario that the new queue_count is
> bigger than the old one. it will access the unallocated memory.
> ctrl->queues is just allocated the first queue count buffers at the start
> of the controller lifetime, if the new queue count is bigger than the
> first queue count, ctrl-queues will be insufficient.
Please ignore this.
ctrl->queues is allocated the max buffers.
So you are right.
>> .
> 
> .