From: Li Chen <chenl311@chinatelecom.cn>

Hello,

This patch series introduces a new GCC plugin called cleanup_plugin that
warns developers about problematic patterns when using variables with
__attribute__((cleanup(...))). The plugin addresses concerns documented
in include/linux/cleanup.h regarding resource leaks and interdependency
issues.

The cleanup attribute helpers (__free, DEFINE_FREE, etc.) are designed
to automatically clean up resources when variables go out of scope,
following LIFO (last in first out) ordering. However, certain patterns
can lead to subtle bugs:

1. Uninitialized cleanup variables: Variables declared with cleanup
   attributes but not initialized can cause issues when cleanup functions
   are called on undefined values.

2. NULL-initialized cleanup variables: The "__free(...) = NULL" pattern
   at function top can cause interdependency problems, especially when
   combined with guards or multiple cleanup variables, as the cleanup
   may run in unexpected contexts.

The plugin detects both of these problematic patterns and provides clear
warnings to developers, helping prevent  incorrect cleanup ordering.
Importantly, the plugin's warnings are not converted
to errors by -Werror, allowing builds to continue while still alerting
developers to potential issues.

The plugin is enabled by default as it provides valuable compile-time
feedback without impacting build performance.

Li Chen (2):
  gcc-plugins: add cleanup_plugin for uninitialized cleanup detection
  gcc-plugins: cleanup_plugin: detect NULL init

 scripts/Makefile.gcc-plugins         |   1 +
 scripts/gcc-plugins/Kconfig          |   6 +
 scripts/gcc-plugins/cleanup_plugin.c | 204 +++++++++++++++++++++++++++
 3 files changed, 211 insertions(+)
 create mode 100644 scripts/gcc-plugins/cleanup_plugin.c

-- 
2.51.0

+Peter, Dan, and Bjorn

(My apologies for the oversight)

 ---- On Wed, 05 Nov 2025 16:46:55 +0800  Li Chen <me@linux.beauty> wrote --- 
 > From: Li Chen <chenl311@chinatelecom.cn>
 > 
 > Hello,
 > 
 > This patch series introduces a new GCC plugin called cleanup_plugin that
 > warns developers about problematic patterns when using variables with
 > __attribute__((cleanup(...))). The plugin addresses concerns documented
 > in include/linux/cleanup.h regarding resource leaks and interdependency
 > issues.
 > 
 > The cleanup attribute helpers (__free, DEFINE_FREE, etc.) are designed
 > to automatically clean up resources when variables go out of scope,
 > following LIFO (last in first out) ordering. However, certain patterns
 > can lead to subtle bugs:
 > 
 > 1. Uninitialized cleanup variables: Variables declared with cleanup
 >    attributes but not initialized can cause issues when cleanup functions
 >    are called on undefined values.
 > 
 > 2. NULL-initialized cleanup variables: The "__free(...) = NULL" pattern
 >    at function top can cause interdependency problems, especially when
 >    combined with guards or multiple cleanup variables, as the cleanup
 >    may run in unexpected contexts.
 > 
 > The plugin detects both of these problematic patterns and provides clear
 > warnings to developers, helping prevent  incorrect cleanup ordering.
 > Importantly, the plugin's warnings are not converted
 > to errors by -Werror, allowing builds to continue while still alerting
 > developers to potential issues.
 > 
 > The plugin is enabled by default as it provides valuable compile-time
 > feedback without impacting build performance.
 > 
 > Li Chen (2):
 >   gcc-plugins: add cleanup_plugin for uninitialized cleanup detection
 >   gcc-plugins: cleanup_plugin: detect NULL init
 > 
 >  scripts/Makefile.gcc-plugins         |   1 +
 >  scripts/gcc-plugins/Kconfig          |   6 +
 >  scripts/gcc-plugins/cleanup_plugin.c | 204 +++++++++++++++++++++++++++
 >  3 files changed, 211 insertions(+)
 >  create mode 100644 scripts/gcc-plugins/cleanup_plugin.c
 > 
 > -- 
 > 2.51.0
 > 
 > 
Regards,

Li​

On Wed, Nov 05, 2025 at 05:04:02PM +0800, Li Chen wrote:
> +Peter, Dan, and Bjorn
> 
> (My apologies for the oversight)
> 
>  ---- On Wed, 05 Nov 2025 16:46:55 +0800  Li Chen <me@linux.beauty> wrote --- 
>  > From: Li Chen <chenl311@chinatelecom.cn>
>  > 
>  > Hello,
>  > 
>  > This patch series introduces a new GCC plugin called cleanup_plugin that
>  > warns developers about problematic patterns when using variables with
>  > __attribute__((cleanup(...))). The plugin addresses concerns documented
>  > in include/linux/cleanup.h regarding resource leaks and interdependency
>  > issues.
>  > 
>  > The cleanup attribute helpers (__free, DEFINE_FREE, etc.) are designed
>  > to automatically clean up resources when variables go out of scope,
>  > following LIFO (last in first out) ordering. However, certain patterns
>  > can lead to subtle bugs:
>  > 
>  > 1. Uninitialized cleanup variables: Variables declared with cleanup
>  >    attributes but not initialized can cause issues when cleanup functions
>  >    are called on undefined values.
>  > 
>  > 2. NULL-initialized cleanup variables: The "__free(...) = NULL" pattern
>  >    at function top can cause interdependency problems, especially when
>  >    combined with guards or multiple cleanup variables, as the cleanup
>  >    may run in unexpected contexts.
>  > 
>  > The plugin detects both of these problematic patterns and provides clear
>  > warnings to developers, helping prevent  incorrect cleanup ordering.
>  > Importantly, the plugin's warnings are not converted
>  > to errors by -Werror, allowing builds to continue while still alerting
>  > developers to potential issues.
>  > 
>  > The plugin is enabled by default as it provides valuable compile-time
>  > feedback without impacting build performance.

IIRC GCC also allow dumb stuff like gotos into the scope of a cleanup
variable, where clang will fail the compile. Does this plugin also fix
this?

Hi Peter,

 ---- On Wed, 05 Nov 2025 17:49:04 +0800  Peter Zijlstra <peterz@infradead.org> wrote --- 
 > On Wed, Nov 05, 2025 at 05:04:02PM +0800, Li Chen wrote:
 > > +Peter, Dan, and Bjorn
 > > 
 > > (My apologies for the oversight)
 > > 
 > >  ---- On Wed, 05 Nov 2025 16:46:55 +0800  Li Chen <me@linux.beauty> wrote --- 
 > >  > From: Li Chen <chenl311@chinatelecom.cn>
 > >  > 
 > >  > Hello,
 > >  > 
 > >  > This patch series introduces a new GCC plugin called cleanup_plugin that
 > >  > warns developers about problematic patterns when using variables with
 > >  > __attribute__((cleanup(...))). The plugin addresses concerns documented
 > >  > in include/linux/cleanup.h regarding resource leaks and interdependency
 > >  > issues.
 > >  > 
 > >  > The cleanup attribute helpers (__free, DEFINE_FREE, etc.) are designed
 > >  > to automatically clean up resources when variables go out of scope,
 > >  > following LIFO (last in first out) ordering. However, certain patterns
 > >  > can lead to subtle bugs:
 > >  > 
 > >  > 1. Uninitialized cleanup variables: Variables declared with cleanup
 > >  >    attributes but not initialized can cause issues when cleanup functions
 > >  >    are called on undefined values.
 > >  > 
 > >  > 2. NULL-initialized cleanup variables: The "__free(...) = NULL" pattern
 > >  >    at function top can cause interdependency problems, especially when
 > >  >    combined with guards or multiple cleanup variables, as the cleanup
 > >  >    may run in unexpected contexts.
 > >  > 
 > >  > The plugin detects both of these problematic patterns and provides clear
 > >  > warnings to developers, helping prevent  incorrect cleanup ordering.
 > >  > Importantly, the plugin's warnings are not converted
 > >  > to errors by -Werror, allowing builds to continue while still alerting
 > >  > developers to potential issues.
 > >  > 
 > >  > The plugin is enabled by default as it provides valuable compile-time
 > >  > feedback without impacting build performance.
 > 
 > IIRC GCC also allow dumb stuff like gotos into the scope of a cleanup
 > variable, where clang will fail the compile. Does this plugin also fix
 > this?
 > 

I'm sorry, but I don't fully understand what you mean by "gotos into the 
scope of a cleanup variable". Could you please provide a sample to illustrate this issue?
And I would try to fix it here if I can.

Regards,

Li​