>> …
>>> +++ b/drivers/dma-buf/dma-heap.c
>> …
>>> +static void dma_heap_release(struct kref *ref)
>>> +{
>> …
>>> + mutex_lock(&heap_list_lock);
>>> + list_del(&heap->list);
>>> + mutex_unlock(&heap_list_lock);
>> …
>>
>> Under which circumstances would you become interested to apply a statement
>> like “guard(mutex)(&heap_list_lock);”?
>> https://elixir.bootlin.com/linux/v6.10/source/include/linux/mutex.h#L196
>
> This strikes me as a strange place to apply it, as it seems like it
> would grow the lock hold time to the entire scope of the function
> unless one created a subscope for just the list_del, at which point
> you're not saving much or really improving readability. I definitely
> think guard usage is very interesting in places where locks are
> released in multiple exit paths, etc. but this is a very trivial and
> straightforward lock/unlock usage, so I fret I don't quite understand
> the suggestion.
I propose to take further design possibilities better into account for
applications of scope-based resource management.
Additional compound statements may be constructed on demand by adding
extra curly brackets.
You might occasionally find scoped guards more appealing.
https://elixir.bootlin.com/linux/v6.10/source/include/linux/cleanup.h#L137
Regards,
Markus
