From: Markus Elfring <Markus.Elfring@web.de>
To: Erick Karanja <karanja99erick@gmail.com>, cocci@inria.fr
Cc: kernel-janitors@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [cocci] [RFC] coccinelle script: scope-based resource cleanup
Date: Thu, 18 Sep 2025 14:40:13 +0200 [thread overview]
Message-ID: <681e64d4-4a10-4c7e-9680-97de27ca5482@web.de> (raw)
In-Reply-To: <64c3889e132a96853a361791c44fcea1a0aaac8c.camel@gmail.com>
> 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
parent reply other threads:[~2025-09-18 12:40 UTC|newest]
Thread overview: expand[flat|nested] mbox.gz Atom feed
[parent not found: <64c3889e132a96853a361791c44fcea1a0aaac8c.camel@gmail.com>]
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=681e64d4-4a10-4c7e-9680-97de27ca5482@web.de \
--to=markus.elfring@web.de \
--cc=cocci@inria.fr \
--cc=karanja99erick@gmail.com \
--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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).