From: Jakub Kicinski <kuba@kernel.org>
To: Masahiro Yamada <masahiroy@kernel.org>
Cc: linux-kbuild@vger.kernel.org, linux-kernel@vger.kernel.org,
workflows@vger.kernel.org, torvalds@linux-foundation.org
Subject: Re: [PATCH v2 3/4] scripts/misc-check: check missing #include <linux/export.h> when W=1
Date: Thu, 19 Jun 2025 09:01:00 -0700 [thread overview]
Message-ID: <20250619090100.39e37c5a@kernel.org> (raw)
In-Reply-To: <20250601133230.4085512-3-masahiroy@kernel.org>
On Sun, 1 Jun 2025 22:31:29 +0900 Masahiro Yamada wrote:
> The problem was described in commit 5b20755b7780 ("init: move THIS_MODULE
> from <linux/export.h> to <linux/init.h>").
>
> To summarize it again here: <linux/export.h> is included by most C files,
> even though only some of them actually export symbols. This is because
> some headers, such as include/linux/{module.h,linkage}, needlessly
> include <linux/export.h>.
>
> I have added a more detailed explanation in the comments of
> scripts/misc-check.
>
> This problem will be fixed in two steps:
>
> 1. Add #include <linux/export.h> to C files that use EXPORT_SYMBOL()
> 2. Remove #include <linux/export.h> from header files that do not use
> EXPORT_SYMBOL()
>
> This commit addresses step 1; scripts/misc-check will warn about *.[ch]
> files that use EXPORT_SYMBOL() but do not include <linux/export.h>.
> This check is only triggered when the kernel is built with W=1.
>
> We need to fix 4000+ files. I hope others will help with this effort.
IIUC you made the kernel spew nearly 5000 warnings on every W=1 build
to "encourage" others to help fix a fairly innocuous problem.
I appreciate the work that goes into separating the headers but it's
hardly urgent enough to force others to scroll thru 5k warnings.
Please LMK if I'm missing some context here, otherwise I think this is
quite antisocial behavior, and the warnings should go back to W=2 until
someone actually cares to fix most of them.
Happy to hear from others.. CC: workflows
> diff --git a/scripts/misc-check b/scripts/misc-check
> index 21551d721079..edc0e44d96de 100755
> --- a/scripts/misc-check
> +++ b/scripts/misc-check
> @@ -9,4 +9,47 @@ check_tracked_ignored_files () {
> sed 's/$/: warning: ignored by one of the .gitignore files/' >&2
> }
>
> +# Check for missing #include <linux/export.h>
> +#
> +# The rule for including <linux/export.h> is very simple:
> +# Include <linux/export.h> only when you use EXPORT_SYMBOL(). That's it.
> +#
> +# However, some headers include <linux/export.h> even though they are completely
> +# unrelated to EXPORT_SYMBOL().
> +#
> +# One example is include/linux/module.h. Please note <linux/module.h> and
> +# <linux/export.h> are orthogonal. <linux/module.h> should be included by files
> +# that can be compiled as modules. In other words, <linux/module.h> should be
> +# included by EXPORT_SYMBOL consumers. In contrast, <linux/export.h> should be
> +# included from EXPORT_SYMBOL providers, which may or may not be modular.
> +# Hence, include/linux/module.h should *not* include <linux/export.h>.
> +#
> +# Another example is include/linux/linkage.h, which is completely unrelated to
> +# EXPORT_SYMBOL(). Worse, it is included by most C files, which means, most C
> +# files end up including <linux/export.h>, even though only some of them
> +# actually export symbols. Hence, include/linux/linkage.h should *not* include
> +# <linux/export.h>.
> +#
> +# Before fixing such headers, we must ensure that C files using EXPORT_SYMBOL()
> +# include <linux/export.h> directly, since many C files currently rely on
> +# <linux/export.h> being included indirectly (likely, via <linux/linkage> etc.).
> +#
> +# Therefore, this check.
> +#
> +# The problem is simple - the warned files use EXPORT_SYMBOL(), but do not
> +# include <linux/export.h>. Please add #include <linux/export.h> to them.
> +#
> +# If the included headers are sorted alphabetically, please insert
> +# <linux/export.h> in the appropriate position to maintain the sort order.
> +# For this reason, this script only checks missing <linux/export.h>, but
> +# does not automatically fix it.
> +check_missing_include_linux_export_h () {
> +
> + git -C "${srctree:-.}" grep --files-with-matches -E 'EXPORT_SYMBOL((_NS)?(_GPL)?|_GPL_FOR_MODULES)\(.*\)' \
> + -- '*.[ch]' :^tools/ :^include/linux/export.h |
> + xargs git -C "${srctree:-.}" grep --files-without-match '#include[[:space:]]*<linux/export\.h>' |
> + xargs printf "%s: warning: EXPORT_SYMBOL() is used, but #include <linux/export.h> is missing\n" >&2
> +}
> +
> check_tracked_ignored_files
> +check_missing_include_linux_export_h
next parent reply other threads:[~2025-06-19 16:01 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20250601133230.4085512-1-masahiroy@kernel.org>
[not found] ` <20250601133230.4085512-3-masahiroy@kernel.org>
2025-06-19 16:01 ` Jakub Kicinski [this message]
2025-06-19 16:13 ` Masahiro Yamada
2025-06-19 16:26 ` Jakub Kicinski
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=20250619090100.39e37c5a@kernel.org \
--to=kuba@kernel.org \
--cc=linux-kbuild@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=masahiroy@kernel.org \
--cc=torvalds@linux-foundation.org \
--cc=workflows@vger.kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox