linux-kernel - [RFC] coccinelle script: scope-based resource cleanup

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 for Android: free password hash cracker in your pocket

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

Message-ID: <64c3889e132a96853a361791c44fcea1a0aaac8c.camel@gmail.com>
Date: Wed, 17 Sep 2025 16:10:49 +0300
From: Erick Karanja <karanja99erick@...il.com>
To: linux-kernel@...r.kernel.org, kernel-janitors@...r.kernel.org
Cc: Julia Lawall <julia.lawall@...ia.fr>
Subject: [RFC] coccinelle script: scope-based resource cleanup

Hi all,
With the guidance of my mentor Julia Lawall, I have developed a
Coccinelle script that assists with scope-based cleanup in the Linux
kernel. The script aims to convert lock/unlock pattern to use guard
cleanup macro.
Link: https://github.com/Erickkaranja/scope_based_cleanup.git

When developing the rule some key consideration was taken to ensure the
correctness of the transformation. This involved enforcing some strict
rules and not transforming some patterns at all.
For instance though, some transformation were correct to use guard,
CLANG raises some warning and thus required a strict use of
scoped_guard in this scenario. Refer to this commit

https://gbmc.googlesource.com/linux/+/97f4b999e0c894d3e48e318aa1130132031815b3

In cases where no transformation is applied, it is because performing
one automatically could risk introducing errors or unintentionally
changing the function’s intended behavior, so such instances have been
deliberately left unchanged.
Examples
case 1:
In cases of inversed lock  pattern i.e where unlock happens before the
lock.

case 2:
Scoped_guard implementation uses a for loop, transforming code sections
that braces a break statement within the scoped_guard could lead to
unintended changed use of the break statement.

case 3:
In scenarios of conditional jump, if there is some function call before
the unlock, there is the danger of moving the function call to the
critical section and if the function sleeps could lead to deadlocks.

Below, Is a link to blog posts that explains in depth above cases and
provide examples of functions which are not suitable for transformation
using our script.
https://erickkaranja1.wordpress.com/2025/08/07/from-lock-unlock-to-scoped_guard-conditional-jump/
https://erickkaranja1.wordpress.com/2025/07/02/from-mutex_lock-mutex_unlock-to-scoped_guard-part-2/
https://erickkaranja1.wordpress.com/2025/06/19/from-mutex_lock-mutex_unlock-to-scoped_guard/
Regards,
Erick