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