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
