Re: [PATCHv2] block: restore two stage elevator switch while running nr_hw_queue update

[Nilay Shroff <nilay@linux.ibm.com>]

On 7/23/25 12:28 PM, Yu Kuai wrote:
>>>>> BTW, this is not related to this patch. Should we handle fall_back
>>>>> failure like blk_mq_sysfs_register_hctxs()?
>>>>>
>>>> OKay I guess you meant here handle failure case by unwinding the
>>>> queue instead of looping through it from start to end. If yes, then
>>>> it could be done but again we may not want to do it the bug fix patch.
>>>>
>>>
>>> Not like that, actually I don't have any ideas for now, the hctxs is
>>> unregistered first, and if register failed, for example, due to -ENOMEM,
>>> I can't find a way to fallback :(
>>>
>> If registering new hctxs fails, we fall back to the previous value of
>> nr_hw_queues (prev_nr_hw_queues). When prev_nr_hw_queues is less than
>> the new nr_hw_queues, we do not reallocate memory for the existing hctxs—
>> instead, we reuse the memory that was already allocated.
>>
>> Memory allocation is only attempted for the additional hctxs beyond
>> prev_nr_hw_queues. Therefore, if memory allocation for these new hctxs
>> fails, we can safely fall back to prev_nr_hw_queues because the memory
>> of the previously allocated hctxs remains intact.
> 
> No, like I said before, blk_mq_sysfs_unregister_hctxs() will free memory
> by kobject_del() for hctx->kobj and ctx->kobj, and
> __blk_mq_update_nr_hw_queues() call that helper in the beginning.
> And later in the fall back code, blk_mq_sysfs_register_hctxs() can fail
> by memory allocation in kobject_add(), however, the return value is not
> checked.
> 
This can be done checking the kobject state in sysfs: kobj->state_in_sysfs.
If kobj->state_in_sysfs is 1 then it implies that kobject_add() for this
kobj was successful and we can safely call kobject_del() on it otherwise
we can skip it. We already have few places in the kernel using this trick.
For instance, check sysfs_slab_unlink(). So, IMO, similar technique could be
used for hctx->kobj and ctx->kobj as well while we attempt to delete these 
kobjects from unregistering queue and nr_hw_queue update.

Thanks,
--Nilay