From: Peter Zijlstra <peterz@infradead.org>
To: Li Chen <me@linux.beauty>
Cc: Kees Cook <kees@kernel.org>,
Nathan Chancellor <nathan@kernel.org>,
Nicolas Schier <nicolas.schier@linux.dev>,
linux-kernel <linux-kernel@vger.kernel.org>,
linux-hardening <linux-hardening@vger.kernel.org>,
linux-kbuild <linux-kbuild@vger.kernel.org>,
Dan Williams <dan.j.williams@intel.com>,
Bjorn Helgaas <bhelgaas@google.com>
Subject: Re: [RFC PATCH 0/2] Add cleanup_plugin for detecting problematic cleanup patterns
Date: Wed, 5 Nov 2025 10:49:04 +0100 [thread overview]
Message-ID: <20251105094904.GL3245006@noisy.programming.kicks-ass.net> (raw)
In-Reply-To: <19a53424397.26d1e5f01471331.8175059524177790573@linux.beauty>
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?
next prev parent reply other threads:[~2025-11-05 9:49 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-11-05 8:46 [PATCH 0/3] dm-pcache: built-in support and metadata hardening Li Chen
2025-11-05 8:46 ` [PATCH 1/3] dm-pcache: allow built-in build and rename flush helper Li Chen
2025-11-05 8:46 ` [PATCH 2/3] dm-pcache: reuse meta_addr in pcache_meta_find_latest Li Chen
2025-11-05 8:46 ` [PATCH 3/3] dm-pcache: avoid leaking invalid metadata in pcache_meta_find_latest() Li Chen
2025-11-10 11:18 ` Dongsheng Yang
2025-11-10 12:32 ` Li Chen
2025-11-05 8:46 ` [RFC PATCH 0/2] Add cleanup_plugin for detecting problematic cleanup patterns Li Chen
2025-11-05 9:04 ` Li Chen
2025-11-05 9:49 ` Peter Zijlstra [this message]
2025-11-05 14:52 ` Li Chen
2025-11-05 8:46 ` [RFC PATCH 1/2] gcc-plugins: add cleanup_plugin for uninitialized cleanup detection Li Chen
2025-11-07 7:39 ` kernel test robot
2025-11-05 8:46 ` [RFC PATCH 2/2] gcc-plugins: cleanup_plugin: detect NULL init Li Chen
2025-11-05 12:41 ` [PATCH 0/3] dm-pcache: built-in support and metadata hardening Li Chen
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=20251105094904.GL3245006@noisy.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=bhelgaas@google.com \
--cc=dan.j.williams@intel.com \
--cc=kees@kernel.org \
--cc=linux-hardening@vger.kernel.org \
--cc=linux-kbuild@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=me@linux.beauty \
--cc=nathan@kernel.org \
--cc=nicolas.schier@linux.dev \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.