linux-kernel - Re: [PATCH] drm: drm_auth: Convert mutex usage to guard(mutex)

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: <86103c8d-0cdf-4fc8-aa79-5a03b299d26e@igalia.com>
Date: Mon, 12 May 2025 11:27:40 -0300
From: André Almeida <andrealmeid@...lia.com>
To: Thomas Zimmermann <tzimmermann@...e.de>,
 Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>,
 Maxime Ripard <mripard@...nel.org>, David Airlie <airlied@...il.com>,
 Simona Vetter <simona@...ll.ch>
Cc: dri-devel@...ts.freedesktop.org, linux-kernel@...r.kernel.org,
 kernel-dev@...lia.com, Kees Cook <keescook@...omium.org>,
 Tvrtko Ursulin <tvrtko.ursulin@...lia.com>,
 Mario Limonciello <mario.limonciello@....com>
Subject: Re: [PATCH] drm: drm_auth: Convert mutex usage to guard(mutex)

Hi Thomas,

Thanks for the feedback.

Em 12/05/2025 03:52, Thomas Zimmermann escreveu:
> Hi
> 
> Am 09.05.25 um 16:26 schrieb André Almeida:
>> Replace open-coded mutex handling with cleanup.h guard(mutex). This
>> simplifies the code and removes the "goto unlock" pattern.
>>
>> Tested with igt tests core_auth and core_setmaster.
>>
>> Signed-off-by: André Almeida <andrealmeid@...lia.com>
> 
> Reviewed-by: Thomas Zimmermann <tzimmermann@...e.de>
> 
> but with questions below
> 
>> ---
>>
>> For more information about guard(mutex):
>> https://www.kernel.org/doc/html/latest/core-api/cleanup.html
> 
> This page lists issues with guards, so conversion from manual locking 
> should be decided on a case-by-case base IMHO.
> 

Sure, agreed. The places that I have converted to guard(mutex) here 
looks like a good fit for this conversion, where the scope of the mutex 
is well defined inside a function without conditional locking.

>> ---
>>   drivers/gpu/drm/drm_auth.c | 64 ++++++++++++++------------------------
>>   1 file changed, 23 insertions(+), 41 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/drm_auth.c b/drivers/gpu/drm/drm_auth.c
>> index 22aa015df387..d6bf605b4b90 100644
>> --- a/drivers/gpu/drm/drm_auth.c
>> +++ b/drivers/gpu/drm/drm_auth.c
>> @@ -95,7 +95,7 @@ int drm_getmagic(struct drm_device *dev, void *data, 
>> struct drm_file *file_priv)
>>       struct drm_auth *auth = data;
>>       int ret = 0;
>> -    mutex_lock(&dev->master_mutex);
>> +    guard(mutex)(&dev->master_mutex);
> 
> These guard statements are hidden variable declarations. Shouldn't they 
> rather go to the function top with the other declarations? This would 
> also help to prevent the problem listed in cleanup.html to some extend.
> 

The guard statements should go exactly where the lock should be taken, 
as it not only declares anonymous variables but also really takes the 
lock. The lock is then release when the mutex goes out of scope. File 
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c has some usage of 
guard(mutex) as well, where Mario did a similar cleanup:

f123fda19752 drm/amd/display: Use scoped guards for handle_hpd_irq_helper()
aca9ec9b050c drm/amd/display: Use scoped guard for 
amdgpu_dm_update_connector_after_detect()
f24a74d59e14 drm/amd/display: Use scoped guard for dm_resume()


> Best regards
> Thomas
>