… > Fix this problem by resuing the global mutex to protect > nullb_device_power_store() and nullb_update_nr_hw_queues() from configfs. > > Fixes: 45919fbfe1c4 ("null_blk: Enable modifying 'submit_queues' after an instance has been configured") … > +++ b/drivers/block/null_blk/main.c > @@ -413,13 +413,25 @@ static int nullb_update_nr_hw_queues(struct nullb_device *dev, > static int nullb_apply_submit_queues(struct nullb_device *dev, > unsigned int submit_queues) > { > - return nullb_update_nr_hw_queues(dev, submit_queues, dev->poll_queues); > + int ret; > + > + mutex_lock(&lock); > + ret = nullb_update_nr_hw_queues(dev, submit_queues, dev->poll_queues); > + mutex_unlock(&lock); > + > + return ret; > } … How do you think about to increase the application of scope-based resource management here? https://elixir.bootlin.com/linux/v6.9.1/source/include/linux/cleanup.h#L124 Will development interests grow for the usage of a statement like “guard(mutex)(&lock);”? Regards, Markus