linux-kernel - Re: [PATCH v7 05/28] dma-heap: Add proper kref handling on dma-buf heaps

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <7c0e8a0e-3282-4d4e-a5b8-bcd979da3bfa@web.de>
Date: Mon, 22 Jul 2024 20:38:23 +0200
From: Markus Elfring <Markus.Elfring@....de>
To: John Stultz <jstultz@...gle.com>, "T. J. Mercier" <tjmercier@...gle.com>,
 Yong Wu <yong.wu@...iatek.com>, Yunfei Dong <yunfei.dong@...iatek.com>,
 Project_Global_Chrome_Upstream_Group@...iatek.com,
 linux-mediatek@...ts.infradead.org, linux-arm-kernel@...ts.infradead.org,
 linux-media@...r.kernel.org, dri-devel@...ts.freedesktop.org
Cc: Angelo Gioacchino Del Regno <angelogioacchino.delregno@...labora.com>,
 Benjamin Gaignard <benjamin.gaignard@...labora.com>,
 Hans Verkuil <hverkuil-cisco@...all.nl>,
 Jeffrey Kardatzke <jkardatzke@...gle.com>,
 Marek Szyprowski <m.szyprowski@...sung.com>,
 Mauro Carvalho Chehab <mchehab@...nel.org>,
 Nathan Hebert <nhebert@...omium.org>,
 Nicolas Dufresne <nicolas.dufresne@...labora.com>,
 Nícolas F. R. A. Prado <nfraprado@...labora.com>,
 Sebastian Fricke <sebastian.fricke@...labora.com>,
 Tomasz Figa <tfiga@...omium.org>, LKML <linux-kernel@...r.kernel.org>,
 Brian Starkey <Brian.Starkey@....com>, Chen-Yu Tsai <wenst@...omium.org>,
 Christian König <christian.koenig@....com>,
 Daniel Vetter <daniel@...ll.ch>, Fritz König
 <frkoenig@...omium.org>, Hsin-yi Wang <hsinyi@...omium.org>,
 Matthias Brugger <matthias.bgg@...il.com>, Steve Cho
 <stevecho@...omium.org>, Sumit Semwal <sumit.semwal@...aro.org>
Subject: Re: [PATCH v7 05/28] dma-heap: Add proper kref handling on dma-buf
 heaps

>> …
>>> +++ 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