linux-kernel - Re: [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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <681e64d4-4a10-4c7e-9680-97de27ca5482@web.de>
Date: Thu, 18 Sep 2025 14:40:13 +0200
From: Markus Elfring <Markus.Elfring@....de>
To: Erick Karanja <karanja99erick@...il.com>, cocci@...ia.fr
Cc: kernel-janitors@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [RFC] coccinelle script: scope-based resource cleanup

> 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