[RFC] coccinelle script: scope-based resource cleanup

[RFC] coccinelle script: scope-based resource cleanup

[Erick Karanja]

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

Re: [RFC] coccinelle script: scope-based resource cleanup

[Markus Elfring]

> 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

Thanks for your growing development interests.

I added some review comments for further development considerations.


> 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

How much will compiler versions matter?


> 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.

Will transformation requirements push also any improvements for the Coccinelle software?


> Examples
> case 1:
> In cases of inversed lock  pattern i.e where unlock happens before the
> lock.

Under which circumstances will “lock-free” data processing parts become supported?


> 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.

Will further collateral evolution become helpful?


> 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.

I would appreciate clarifications for such a wording.

Regards,
Markus