Thread (28 messages) 28 messages, 5 authors, 2024-03-12

Re: [PATCH v5 02/10] locking/mutex: introduce devm_mutex_init

From: George Stark <hidden>
Date: 2024-03-11 23:31:34
Also in: linux-leds, lkml

Hello Christophe

On 3/7/24 16:50, Christophe Leroy wrote:

Le 07/03/2024 à 03:40, George Stark a écrit :
quoted
[Vous ne recevez pas souvent de courriers de gnstark@salutedevices.com. Découvrez pourquoi ceci est important à https://aka.ms/LearnAboutSenderIdentification ]

Using of devm API leads to a certain order of releasing resources.
So all dependent resources which are not devm-wrapped should be deleted
with respect to devm-release order. Mutex is one of such objects that
often is bound to other resources and has no own devm wrapping.
Since mutex_destroy() actually does nothing in non-debug builds
frequently calling mutex_destroy() is just ignored which is safe for now
but wrong formally and can lead to a problem if mutex_destroy() will be
extended so introduce devm_mutex_init()

Signed-off-by: George Stark <redacted>
Signed-off-by: Christophe Leroy <redacted>
---
   Hello Christophe. Hope you don't mind I put you SoB tag because you helped alot
   to make this patch happen.
Up to you, I sent a RFC patch based on yours with my ideas included
because an exemple is easier than a lot of words for understanding, and
my scripts automatically sets the Signed-off-by: but feel free to change
it to Suggested-by:
Although we had close ideas for the final patch in v4
you encouraged me to do it in the right (=effective) way and go back
from devm-helpers.h to mutex.h in the first place, reinforced the 
concept with appropriate examples from existing code, reviewed a lot. 
Thanks. Probably Suggested-by: is more suited here

-- 
Best regards
George
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help