[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 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 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

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

[Kees Cook]

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?
> 
> (Of course, if one knows that the attribute only applies to fields,
> then it doesn't make much of a difference)

Hmm, I just noticed Clang isn't diagnosing for file-scoped definitions.
I've opened: https://github.com/llvm/llvm-project/issues/232483

Do we want to wait on this attribute until Clang has full coverage for
all initializer cases, or land the attribute so we can continue to add
coverage for function-level coverage? I'm worried about a compiler bump
(once the bug is fixed) suddenly exposing a bunch of missed
initializers, but then again we also have no users yet...

-Kees

-- 
Kees Cook

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

[Nick Desaulniers]

On Thu, Oct 15, 2026 at 1:07 PM Kees Cook <kees@kernel.org> wrote:
>
> 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?
> >
> > (Of course, if one knows that the attribute only applies to fields,
> > then it doesn't make much of a difference)
>
> Hmm, I just noticed Clang isn't diagnosing for file-scoped definitions.
> I've opened: https://github.com/llvm/llvm-project/issues/232483
>
> Do we want to wait on this attribute until Clang has full coverage for
> all initializer cases, or land the attribute so we can continue to add
> coverage for function-level coverage? I'm worried about a compiler bump
> (once the bug is fixed) suddenly exposing a bunch of missed
> initializers, but then again we also have no users yet...

This is a false negative, right? When it gets fixed in clang, the
existing uses in globals start getting checked.  Nothing that would
require compiler version checks, IMO.

>
> -Kees
>
> --
> Kees Cook



-- 
Thanks,
~Nick Desaulniers

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

[Ian Rogers]

On Thu, Oct 15, 2026 at 1:50 AM Greg KH <greg@kroah.com> wrote:
>
> 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 :)

Fwiw, I like __must_init for being both short and intention revealing.
I'll hold off sending my v2 for kobject::release to avoid renaming the
attribute.

Thanks,
Ian