From: Erick Karanja <karanja99erick@gmail.com>
To: linux-kernel@vger.kernel.org, kernel-janitors@vger.kernel.org
Cc: Julia Lawall <julia.lawall@inria.fr>
Subject: [RFC] coccinelle script: scope-based resource cleanup
Date: Wed, 17 Sep 2025 16:10:49 +0300 [thread overview]
Message-ID: <64c3889e132a96853a361791c44fcea1a0aaac8c.camel@gmail.com> (raw)
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
next reply other threads:[~2025-09-17 13:11 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-17 13:10 Erick Karanja [this message]
2025-09-18 12:40 ` [RFC] coccinelle script: scope-based resource cleanup Markus Elfring
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=64c3889e132a96853a361791c44fcea1a0aaac8c.camel@gmail.com \
--to=karanja99erick@gmail.com \
--cc=julia.lawall@inria.fr \
--cc=kernel-janitors@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox