Re: [PATCH 00/11] kobject: Require explicit initialization of struct kobj_type::release

[Kees Cook <kees@kernel.org>]

On Wed, Oct 14, 2026 at 07:36:41AM +0200, Greg Kroah-Hartman wrote:
> On Tue, Oct 13, 2026 at 03:39:35PM -0700, Ian Rogers wrote:
> > Clang supports the 'require_explicit_initialization' attribute on struct
> > fields to enforce that the field is explicitly initialized when an
> > aggregate object is constructed, emitting -Wuninitialized-explicit-init
> > (enabled by default) if the field is omitted.
> > 
> > Following discussion at the Linux Plumbers Conference [1], this series
> > introduces __require_explicit_initialization in
> > include/linux/compiler_attributes.h and applies it to
> > struct kobj_type::release.
> 
> Cool, sorry I missed that talk.

Yeah, I'm really liking these compile-time checks. :)

> 
> > As Documentation/core-api/kobject.rst notes:
> >   "One important point cannot be overstated: every kobject must have a
> >   release() method, and the kobject must persist (in a consistent state)
> >   until that method is called. If these constraints are not met, the code
> >   is flawed."
> > 
> > Annotating struct kobj_type::release caught 30 struct kobj_type
> > definitions across the tree that omitted .release:
> > - Patches 2-10 fix 10 struct kobj_type definitions where dynamically
> >   allocated kobjects, ksets, or enclosing structures were either leaked on
> >   kobject_put() or freed prematurely before kobject release (risking a
> >   use-after-free when CONFIG_DEBUG_KOBJECT_RELEASE=y).
> > - Patch 11 annotates struct kobj_type::release with
> >   __require_explicit_initialization and explicitly sets .release = NULL
> >   (with explanatory comments) on the remaining legacy struct kobj_type
> >   definitions whose kobjects are static, per-CPU, or embedded in devm- or
> >   parent-managed structures.
> 
> Sounds great, but let's fix up the users before adding the attribute.
> Looks like some of these need another version so it might take a bit of
> time to get them all merged.

I'd really like to have the attribute available, and I've got at least
one user I can apply today that don't require fix-ups (seq_file), so
if Miguel is okay with it, I'd like to snag patch 1 and send it with
my seq_file "first user" for this coming merge window so it's available
starting with v7.4-rc1, and we don't end up needing to wait 10 weeks for
other subsystems to be able to use it. And the kobj fixups can continue
in parallel. Does that sounds okay?

-- 
Kees Cook