On Wed, Oct 14, 2026 at 9:37 AM Kees Cook <[email protected]> wrote: > > 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?
I'm happy with that. I'm working to address/incorporate the other feedback for a v2 of this series, but I can drop individual patches that have already been merged. Thanks, everyone, for the positive reception in getting this landed, I plan to follow up with patch series for the other uses I found. Thanks! Ian > -- > Kees Cook
