[PATCH 0/2] Add __require_explicit_initialization and its first user

[PATCH 0/2] Add __require_explicit_initialization and its first user

[Kees Cook]

Hi!

As discussed in Ian's kobj_type::release series[1], this takes its first
patch (to add __require_explicit_initialization), with Miguel's requested
comment tweak (the attribute needs Clang 20 or later), along with a first
user that needs no fix-ups first: seq_file's seq_operations callbacks,
which are called without a NULL check. This will make the attribute
available in v7.4-rc1, while the kobj_type fixes continue separately.

The annotation adds no warnings anywhere in the tree today that I could
find across allmodconfig builds:

  Clang 24.0.0git: x86_64, arm64, i386, arm, riscv, s390, loongarch, powerpc.
  GCC 16.2.0: x86_64, arm64, i386, arm, riscv, s390, m68k, mips, parisc,
	      sparc, loongarch, xtensa, arc, and openrisc.

Thanks!

-Kees

[1] https://lore.kernel.org/all/20261013223946.1836757-1-irogers@google.com/

Ian Rogers (1):
  Compiler Attributes: Add __require_explicit_initialization macro

Kees Cook (1):
  seq_file: Require explicit initialization of struct seq_operations

 scripts/checkpatch.pl                 |  1 +
 Documentation/conf.py                 |  1 +
 include/linux/compiler_attributes.h   | 12 ++++++++++++
 include/linux/seq_file.h              | 13 +++++++++----
 tools/lib/python/kdoc/xforms_lists.py |  1 +
 5 files changed, 24 insertions(+), 4 deletions(-)

-- 
2.55.0

[PATCH 1/2] Compiler Attributes: Add __require_explicit_initialization macro

[Kees Cook]

From: Ian Rogers <irogers@google.com>

Clang supports the 'require_explicit_initialization' attribute on struct
fields to indicate that a field must be initialized explicitly by the
user when the object is constructed. When an aggregate initializer or
uninitialized variable omits an annotated field, Clang emits a
-Wuninitialized-explicit-init warning (enabled by default).

Add the __require_explicit_initialization macro to
include/linux/compiler_attributes.h (which is included by
include/linux/compiler_types.h and include/linux/compiler.h) so kernel
structs with error-prone initialization (such as mandatory callbacks or
cleanup handlers) can enforce explicit initialization at compile time,
as discussed at the Linux Plumbers Conference.

Also teach Sphinx (Documentation/conf.py), kernel-doc
(tools/lib/python/kdoc/xforms_lists.py), and checkpatch.pl about the new
attribute macro.

Link: https://lpc.events/event/20/contributions/2392/
Assisted-by: Antigravity:gemini-3.1-pro
Signed-off-by: Ian Rogers <irogers@google.com>
Acked-by: Miguel Ojeda <ojeda@kernel.org>
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
Signed-off-by: Kees Cook <kees@kernel.org>
---
 scripts/checkpatch.pl                 |  1 +
 Documentation/conf.py                 |  1 +
 include/linux/compiler_attributes.h   | 12 ++++++++++++
 tools/lib/python/kdoc/xforms_lists.py |  1 +
 4 files changed, 15 insertions(+)

diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index 8a7787d228a6..4a3ae6b0100a 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -6871,6 +6871,7 @@ sub process {
 				"noreturn"			=> "__noreturn",
 				"packed"			=> "__packed",
 				"pure"				=> "__pure",
+				"require_explicit_initialization" => "__require_explicit_initialization",
 				"section"			=> "__section",
 				"used"				=> "__used",
 				"weak"				=> "__weak"
diff --git a/Documentation/conf.py b/Documentation/conf.py
index 5ab26ce89daf..3e5cb9ca0970 100644
--- a/Documentation/conf.py
+++ b/Documentation/conf.py
@@ -203,6 +203,7 @@ c_id_attributes = [
     "__noreturn",
     "__packed",
     "__pure",
+    "__require_explicit_initialization",
     "__section",
     "__always_unused",
     "__maybe_unused",
diff --git a/include/linux/compiler_attributes.h b/include/linux/compiler_attributes.h
index 476c4c560d17..625e95e684c7 100644
--- a/include/linux/compiler_attributes.h
+++ b/include/linux/compiler_attributes.h
@@ -322,6 +322,18 @@
  */
 #define __pure                          __attribute__((__pure__))
 
+/*
+ * Optional: not supported by gcc
+ * Optional: only supported since clang >= 20.0
+ *
+ * clang: https://clang.llvm.org/docs/AttributeReference.html#require-explicit-initialization
+ */
+#if __has_attribute(__require_explicit_initialization__)
+# define __require_explicit_initialization __attribute__((__require_explicit_initialization__))
+#else
+# define __require_explicit_initialization
+#endif
+
 /*
  *   gcc: https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html#index-section-function-attribute
  *   gcc: https://gcc.gnu.org/onlinedocs/gcc/Common-Variable-Attributes.html#index-section-variable-attribute
diff --git a/tools/lib/python/kdoc/xforms_lists.py b/tools/lib/python/kdoc/xforms_lists.py
index e3dda2fe8a53..32066fbbe763 100644
--- a/tools/lib/python/kdoc/xforms_lists.py
+++ b/tools/lib/python/kdoc/xforms_lists.py
@@ -36,6 +36,7 @@ class CTransforms:
         (CMatch("CRYPTO_MINALIGN_ATTR"), ""),
         (CMatch("__private"), ""),
         (CMatch("__rcu"), ""),
+        (CMatch("__require_explicit_initialization"), ""),
         (CMatch("____cacheline_aligned_in_smp"), ""),
         (CMatch("____cacheline_aligned"), ""),
         (CMatch("__cacheline_group_(?:begin|end)"), ""),
-- 
2.55.0

[PATCH 2/2] seq_file: Require explicit initialization of struct seq_operations

[Kees Cook]

In the very unlikely chance that a seq_operations didn't get initialized,
we wouldn't want them calling some random location. As a first example
user of __require_explicit_initialization, annotate them so a missing
initializer is a compile-time warning.

Every seq_operations in the tree already sets all four, so no new warnings
are added.

Signed-off-by: Kees Cook <kees@kernel.org>
---
 include/linux/seq_file.h | 13 +++++++++----
 1 file changed, 9 insertions(+), 4 deletions(-)

diff --git a/include/linux/seq_file.h b/include/linux/seq_file.h
index dc0e8c62d9e0..f0e7e52a0905 100644
--- a/include/linux/seq_file.h
+++ b/include/linux/seq_file.h
@@ -28,11 +28,16 @@ struct seq_file {
 	void *private;
 };
 
+/* All four are called without checking for NULL. */
 struct seq_operations {
-	void * (*start) (struct seq_file *m, loff_t *pos);
-	void (*stop) (struct seq_file *m, void *v);
-	void * (*next) (struct seq_file *m, void *v, loff_t *pos);
-	int (*show) (struct seq_file *m, void *v);
+	void *(*start)(struct seq_file *m, loff_t *pos)
+		__require_explicit_initialization;
+	void (*stop)(struct seq_file *m, void *v)
+		__require_explicit_initialization;
+	void *(*next)(struct seq_file *m, void *v, loff_t *pos)
+		__require_explicit_initialization;
+	int (*show)(struct seq_file *m, void *v)
+		__require_explicit_initialization;
 };
 
 #define SEQ_SKIP 1
-- 
2.55.0

Re: [PATCH 1/2] Compiler Attributes: Add __require_explicit_initialization macro

[Nathan Chancellor]

On Wed, Oct 14, 2026 at 03:58:15PM -0700, Kees Cook wrote:
> From: Ian Rogers <irogers@google.com>
> 
> Clang supports the 'require_explicit_initialization' attribute on struct
> fields to indicate that a field must be initialized explicitly by the
> user when the object is constructed. When an aggregate initializer or
> uninitialized variable omits an annotated field, Clang emits a
> -Wuninitialized-explicit-init warning (enabled by default).
> 
> Add the __require_explicit_initialization macro to
> include/linux/compiler_attributes.h (which is included by
> include/linux/compiler_types.h and include/linux/compiler.h) so kernel
> structs with error-prone initialization (such as mandatory callbacks or
> cleanup handlers) can enforce explicit initialization at compile time,
> as discussed at the Linux Plumbers Conference.
> 
> Also teach Sphinx (Documentation/conf.py), kernel-doc
> (tools/lib/python/kdoc/xforms_lists.py), and checkpatch.pl about the new
> attribute macro.
> 
> Link: https://lpc.events/event/20/contributions/2392/
> Assisted-by: Antigravity:gemini-3.1-pro
> Signed-off-by: Ian Rogers <irogers@google.com>
> Acked-by: Miguel Ojeda <ojeda@kernel.org>
> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
> Signed-off-by: Kees Cook <kees@kernel.org>

Reviewed-by: Nathan Chancellor <nathan@kernel.org>

-- 
Cheers,
Nathan

Re: [PATCH 1/2] Compiler Attributes: Add __require_explicit_initialization macro

[Greg Kroah-Hartman]

On Wed, Oct 14, 2026 at 03:58:15PM -0700, Kees Cook wrote:
> From: Ian Rogers <irogers@google.com>
> 
> Clang supports the 'require_explicit_initialization' attribute on struct
> fields to indicate that a field must be initialized explicitly by the
> user when the object is constructed. When an aggregate initializer or
> uninitialized variable omits an annotated field, Clang emits a
> -Wuninitialized-explicit-init warning (enabled by default).
> 
> Add the __require_explicit_initialization macro to
> include/linux/compiler_attributes.h (which is included by
> include/linux/compiler_types.h and include/linux/compiler.h) so kernel
> structs with error-prone initialization (such as mandatory callbacks or
> cleanup handlers) can enforce explicit initialization at compile time,
> as discussed at the Linux Plumbers Conference.
> 
> Also teach Sphinx (Documentation/conf.py), kernel-doc
> (tools/lib/python/kdoc/xforms_lists.py), and checkpatch.pl about the new
> attribute macro.
> 
> Link: https://lpc.events/event/20/contributions/2392/
> Assisted-by: Antigravity:gemini-3.1-pro
> Signed-off-by: Ian Rogers <irogers@google.com>
> Acked-by: Miguel Ojeda <ojeda@kernel.org>
> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
> Signed-off-by: Kees Cook <kees@kernel.org>
> ---

Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Re: [PATCH 2/2] seq_file: Require explicit initialization of struct seq_operations

[Greg KH]

On Wed, Oct 14, 2026 at 03:58:16PM -0700, Kees Cook wrote:
> In the very unlikely chance that a seq_operations didn't get initialized,
> we wouldn't want them calling some random location. As a first example
> user of __require_explicit_initialization, annotate them so a missing
> initializer is a compile-time warning.
> 
> Every seq_operations in the tree already sets all four, so no new warnings
> are added.
> 
> Signed-off-by: Kees Cook <kees@kernel.org>
> ---
>  include/linux/seq_file.h | 13 +++++++++----
>  1 file changed, 9 insertions(+), 4 deletions(-)
> 
> diff --git a/include/linux/seq_file.h b/include/linux/seq_file.h
> index dc0e8c62d9e0..f0e7e52a0905 100644
> --- a/include/linux/seq_file.h
> +++ b/include/linux/seq_file.h
> @@ -28,11 +28,16 @@ struct seq_file {
>  	void *private;
>  };
>  
> +/* All four are called without checking for NULL. */
>  struct seq_operations {
> -	void * (*start) (struct seq_file *m, loff_t *pos);
> -	void (*stop) (struct seq_file *m, void *v);
> -	void * (*next) (struct seq_file *m, void *v, loff_t *pos);
> -	int (*show) (struct seq_file *m, void *v);
> +	void *(*start)(struct seq_file *m, loff_t *pos)
> +		__require_explicit_initialization;
> +	void (*stop)(struct seq_file *m, void *v)
> +		__require_explicit_initialization;
> +	void *(*next)(struct seq_file *m, void *v, loff_t *pos)
> +		__require_explicit_initialization;
> +	int (*show)(struct seq_file *m, void *v)
> +		__require_explicit_initialization;
>  };

Hm, I acked the first patch, but seeing this "in the wild" is
interesting.  Feels kind of ackward, but I don't really know what to
suggest instead?  What about just making the lines longer:

	void *(*start)(struct seq_file *m, loff_t *pos)		__require_explicit_initialization;
	void (*stop)(struct seq_file *m, void *v)		__require_explicit_initialization;
	void *(*next)(struct seq_file *m, void *v, loff_t *pos) __require_explicit_initialization;
	int (*show)(struct seq_file *m, void *v)		__require_explicit_initialization;

?

Anyway, I don't know.  I like this feature, and maybe it's going to be
used so infrequently it's not a big deal, but feels clunky.

thanks,

greg k-h

Re: [PATCH 2/2] seq_file: Require explicit initialization of struct seq_operations

[Miguel Ojeda]

On Thu, Oct 15, 2026 at 7:21 AM Greg KH <greg@kroah.com> wrote:
>
> Anyway, I don't know.  I like this feature, and maybe it's going to be
> used so infrequently it's not a big deal, but feels clunky.

Perhaps we could call it something shorter, like `__explicit_init` or
similar -- I don't see that substring (even without the double
underscores) used anywhere.

Cheers,
Miguel

Re: [PATCH 2/2] seq_file: Require explicit initialization of struct seq_operations

[Kees Cook]

On October 14, 2026 10:46:02 PM PDT, Miguel Ojeda <miguel.ojeda.sandonis@gmail.com> wrote:
>On Thu, Oct 15, 2026 at 7:21 AM Greg KH <greg@kroah.com> wrote:
>>
>> Anyway, I don't know.  I like this feature, and maybe it's going to be
>> used so infrequently it's not a big deal, but feels clunky.
>
>Perhaps we could call it something shorter, like `__explicit_init` or
>similar -- I don't see that substring (even without the double
>underscores) used anywhere.

That's nice, yeah. And it's not the first time we've changed the "spelling" of an attribute.

Does anyone object to that? I can replace it with that in my tree...

-Kees

-- 
Kees Cook

Re: [PATCH 2/2] seq_file: Require explicit initialization of struct seq_operations

[Greg KH]

On Wed, Oct 14, 2026 at 10:57:57PM -0700, Kees Cook wrote:
> 
> 
> On October 14, 2026 10:46:02 PM PDT, Miguel Ojeda <miguel.ojeda.sandonis@gmail.com> wrote:
> >On Thu, Oct 15, 2026 at 7:21 AM Greg KH <greg@kroah.com> wrote:
> >>
> >> Anyway, I don't know.  I like this feature, and maybe it's going to be
> >> used so infrequently it's not a big deal, but feels clunky.
> >
> >Perhaps we could call it something shorter, like `__explicit_init` or
> >similar -- I don't see that substring (even without the double
> >underscores) used anywhere.

__must_init might be smaller?

Naming is hard :)

> That's nice, yeah. And it's not the first time we've changed the "spelling" of an attribute.
> 
> Does anyone object to that? I can replace it with that in my tree...

No objection from me to make it shorter, and yes, we can always change
it going forward if someone comes up with a better term.

thanks,

greg k-h

Re: [PATCH 2/2] seq_file: Require explicit initialization of struct seq_operations

[Miguel Ojeda]

On Thu, Oct 15, 2026 at 9:11 AM Greg KH <greg@kroah.com> wrote:
>
> __must_init might be smaller?

That sounds fine too. I like that it says that something *has* to be
done (like the original name did). Hmm... On the other hand, I guess
"must" could sound like one has to initialize the field "somehow",
i.e. writing:

  struct S s = {};

definitely initializes it, yet the compiler would warn. Would
"explicit" hint a bit more at the fact that one has to actually
"write" the field, even if it may have been initialized anyway?

(Of course, if one knows that the attribute only applies to fields,
then it doesn't make much of a difference)

Cheers,
Miguel

Re: [PATCH 2/2] seq_file: Require explicit initialization of struct seq_operations

[Greg KH]

On Thu, Oct 15, 2026 at 09:47:34AM +0200, Miguel Ojeda wrote:
> On Thu, Oct 15, 2026 at 9:11 AM Greg KH <greg@kroah.com> wrote:
> >
> > __must_init might be smaller?
> 
> That sounds fine too. I like that it says that something *has* to be
> done (like the original name did). Hmm... On the other hand, I guess
> "must" could sound like one has to initialize the field "somehow",
> i.e. writing:
> 
>   struct S s = {};
> 
> definitely initializes it, yet the compiler would warn. Would
> "explicit" hint a bit more at the fact that one has to actually
> "write" the field, even if it may have been initialized anyway?

"explicit" is a description, "must" is an action that tells the reader
what they have to do, so maybe "must" is better?

Anyway, I don't care, naming is hard, either is fine with me, I'll let
the authors of the patch here pick what they want :)

thanks,

greg k-h