There were more EXPORT_SYMBOL types in the past. The following commits
removed unused ones.

 - f1c3d73e ("module: remove EXPORT_SYMBOL_GPL_FUTURE")
 - 36794822 ("module: remove EXPORT_UNUSED_SYMBOL*")

There are 3 remaining in enum export, but export_unknown does not make
any sense because we never expect such a situation like "we do not know
how it was exported".

If the symbol name starts with "__ksymtab_", but the section name
does not start with "___ksymtab+" or "___ksymtab_gpl+", it is not an
exported symbol.

It occurs when a variable starting with "__ksymtab_" is directly defined:

   int __ksymtab_foo;

Presumably, there is no practical issue for using such a weird variable
name (but there is no good reason for doing so, either).

Anyway, that is not an exported symbol. Setting export_unknown is not
the right thing to do. Do not call sym_add_exported() in this case.

With pointless export_unknown removed, the export type finally becomes
boolean (either EXPORT_SYMBOL or EXPORT_SYMBOL_GPL).

I renamed the field name to is_gpl_only. EXPORT_SYMBOL_GPL sets it true.
Only GPL-compatible modules can use it.

I removed the orphan comment, "How a symbol is exported", which is
unrelated to sec_mismatch_count. It is about enum export.
See commit bd5cbced ("kbuild: export-type enhancement to modpost.c")
Signed-off-by: NMasahiro Yamada <masahiroy@kernel.org>
Reviewed-by: NNicolas Schier <nicolas@fjasle.eu>
Tested-by: NNathan Chancellor <nathan@kernel.org>

A later commit will add more code to this list_for_each_entry loop.

Before that, move the loop body into a separate helper function.
Signed-off-by: NMasahiro Yamada <masahiroy@kernel.org>
Reviewed-by: NNicolas Schier <nicolas@fjasle.eu>
Tested-by: NNathan Chancellor <nathan@kernel.org>

add_intree_flag(), add_retpoline(), and add_staging_flag() are small
enough to be merged into add_header().
Signed-off-by: NMasahiro Yamada <masahiroy@kernel.org>
Reviewed-by: NNicolas Schier <nicolas@fjasle.eu>
Tested-by: NNathan Chancellor <nathan@kernel.org>

new_symbol() does two things; allocate a new symbol and register it
to the hash table.

Using a separate function for each is easier to understand.

Replace new_symbol() with hash_add_symbol(). Remove the second parameter
of alloc_symbol().
Signed-off-by: NMasahiro Yamada <masahiroy@kernel.org>
Reviewed-by: NNick Desaulniers <ndesaulniers@google.com>

Currently, sym_add_exported() does not allocate a symbol if the same
name symbol already exists in the hash table.

This does not reflect the real use cases. You can let an external
module override the in-tree one. In this case, the external module
will export the same name symbols as the in-tree one. However,
modpost simply ignores those symbols, then Module.symvers for the
external module loses its symbols.

sym_add_exported() should allocate a new symbol.
Signed-off-by: NMasahiro Yamada <masahiroy@kernel.org>
Reviewed-by: NNick Desaulniers <ndesaulniers@google.com>

This is currently a warning, but I think modpost should stop building
in this case.

If the same symbol is exported multiple times and we let it keep going,
the sanity check becomes difficult.

Only the legitimate case is that an external module overrides the
corresponding in-tree module to provide a different implementation
with the same interface.

Also, there exists an upstream example that exploits this feature.

  $ make M=tools/testing/nvdimm

... builds tools/testing/nvdimm/libnvdimm.ko. This is a mocked module
that overrides the symbols from drivers/nvdimm/libnvdimm.ko.
Signed-off-by: NMasahiro Yamada <masahiroy@kernel.org>
Reviewed-by: NNick Desaulniers <ndesaulniers@google.com>

modpost dumps the exported symbols into Module.symvers, but currently
in random order because it iterates in the hash table.

Add a linked list of exported symbols in struct module, so we can
iterate on symbols per module.

This commit makes Module.symvers much more readable; the outer loop in
write_dump() iterates over the modules in the order of modules.order,
and the inner loop dumps symbols in each module.
Signed-off-by: NMasahiro Yamada <masahiroy@kernel.org>
Reviewed-by: NNick Desaulniers <ndesaulniers@google.com>

Use the doubly linked list to traverse the list in the added order.
This makes the code more consistent.
Signed-off-by: NMasahiro Yamada <masahiroy@kernel.org>
Reviewed-by: NNick Desaulniers <ndesaulniers@google.com>

This looks easier to understand (just because this is a pattern in
the kernel code). No functional change is intended.
Signed-off-by: NMasahiro Yamada <masahiroy@kernel.org>
Reviewed-by: NNick Desaulniers <ndesaulniers@google.com>

Currently, modpost manages unresolved in a singly linked list; it adds
a new node to the head, and traverses the list from new to old.

Use a doubly linked list to keep the order in the symbol table in the
ELF file.
Signed-off-by: NMasahiro Yamada <masahiroy@kernel.org>
Reviewed-by: NNick Desaulniers <ndesaulniers@google.com>

Add a small helper, sym_add_unresolved() to ease the further
refactoring.

Remove the 'weak' argument from alloc_symbol() because it is sensible
only for unresolved symbols.
Signed-off-by: NMasahiro Yamada <masahiroy@kernel.org>
Reviewed-by: NNick Desaulniers <ndesaulniers@google.com>

Currently, modpost manages modules in a singly linked list; it adds
a new node to the head, and traverses the list from new to old.

It works, but the error messages are shown in the reverse order.

If you have a Makefile like this:

  obj-m += foo.o bar.o

then, modpost shows error messages in bar.o, foo.o, in this order.

Use a doubly linked list to keep the order in modules.order; use
list_add_tail() for the node addition and list_for_each_entry() for
the list traverse.

Now that the kernel's list macros have been imported to modpost, I will
use them actively going forward.
Signed-off-by: NMasahiro Yamada <masahiroy@kernel.org>
Reviewed-by: NNick Desaulniers <ndesaulniers@google.com>

Currently, mod->gpl_compatible is tristate; it is set to -1 by default,
then to 1 or 0 when MODULE_LICENSE() is found.

Maybe, -1 was chosen to represent the 'unknown' license, but it is not
useful.

The current code:

    if (!mod->gpl_compatible)
            check_for_gpl_usage(exp->export, basename, exp->name);

... only cares whether gpl_compatible is zero or not.

Change it to a bool type with the initial value 'true', which has no
functional change.

The default value should be 'true' instead of 'false'.

Since commit 1d6cd392 ("modpost: turn missing MODULE_LICENSE() into
error"), unknown module license is an error.

The error message, "missing MODULE_LICENSE()" is enough to explain the
issue. It is not sensible to show another message, "GPL-incompatible
module ... uses GPL-only symbol".

Add comments to explain this.

While I was here, I renamed gpl_compatible to is_gpl_compatible for
clarification, and also slightly refactored the code.
Signed-off-by: NMasahiro Yamada <masahiroy@kernel.org>
Reviewed-by: NNick Desaulniers <ndesaulniers@google.com>

Use 'bool' to clarify that the valid value is true or false.
Signed-off-by: NMasahiro Yamada <masahiroy@kernel.org>
Reviewed-by: NNick Desaulniers <ndesaulniers@google.com>

There is no good reason to define struct namespace_list in modpost.h

struct module has pointers to struct namespace_list, but that does
not require the definition of struct namespace_list.

Move it to modpost.c.
Signed-off-by: NMasahiro Yamada <masahiroy@kernel.org>
Reviewed-by: NNick Desaulniers <ndesaulniers@google.com>

Do not repeat the similar code.

It is simpler to do this in check_exports() instead of add_versions().
Signed-off-by: NMasahiro Yamada <masahiroy@kernel.org>
Reviewed-by: NNick Desaulniers <ndesaulniers@google.com>

It took me a while to understand the intent of "exp->module == mod".

This code goes back to 2003. [1]

The commit is not in this git repository, and might be worth a little
explanation.

You can add EXPORT_SYMBOL() without having its definition in the same
file (but you need to put a declaration).

This is typical when EXPORT_SYMBOL() is added in a C file, but the
actual implementation is in a separate assembly file.

One example is arch/arm/kernel/armksyms.c

In the old days, EXPORT_SYMBOL() was only available in C files (but
this limitation does not exist any more). If you forget to add the
definition, this error occurs.

Add a separate, clearer message for this case. It should be an error
even if KBUILD_MODPOST_WARN is given.

[1]: https://git.kernel.org/pub/scm/linux/kernel/git/history/history.git/commit/?id=2763b6bcb96e6a38a2fe31108fe5759ec5bcc80aSigned-off-by: NMasahiro Yamada <masahiroy@kernel.org>
Reviewed-by: NNick Desaulniers <ndesaulniers@google.com>

The description,

  it may have already been added without a
  CRC, in this case just update the CRC

... is no longer valid.

In the old days, this function was used to update the CRC as well.

Commit 040fcc81 ("kbuild: improved modversioning support for
external modules") started to use a separate function (sym_update_crc)
for updating the CRC.

The first part, "Add an exported symbol" is correct, but it is too
obvious from the function name. Drop this comment entirely.
Signed-off-by: NMasahiro Yamada <masahiroy@kernel.org>
Reviewed-by: NNick Desaulniers <ndesaulniers@google.com>

If an error occurs, modpost will fail anyway. Do not write out
any content (, which might be invalid).
Signed-off-by: NMasahiro Yamada <masahiroy@kernel.org>
Reviewed-by: NNick Desaulniers <ndesaulniers@google.com>

Use snprintf() to avoid the potential buffer overflow, and also
check the return value to detect the too long path.
Signed-off-by: NMasahiro Yamada <masahiroy@kernel.org>
Reviewed-by: NNick Desaulniers <ndesaulniers@google.com>

There are two call sites for sym_update_namespace().

When the symbol has no namespace, s->namespace is set to NULL,
but the conversion from "" to NULL is done in two different places.

[1] read_symbols()

  This gets the namespace from __kstrtabns_<symbol>. If the symbol has
  no namespace, sym_get_data(info, sym) returns the empty string "".
  namespace_from_kstrtabns() converts it to NULL before it is passed to
  sym_update_namespace().

[2] read_dump()

  This gets the namespace from the dump file, *.symvers. If the symbol
  has no namespace, the 'namespace' is the empty string "", which is
  directly passed into sym_update_namespace(). The conversion from
  "" to NULL is done in sym_update_namespace().

namespace_from_kstrtabns() exists only for creating this inconsistency.

Remove namespace_from_kstrtabns() so that sym_update_namespace() is
consistently passed with "" instead of NULL.
Signed-off-by: NMasahiro Yamada <masahiroy@kernel.org>
Reviewed-by: NNick Desaulniers <ndesaulniers@google.com>

These are initialized with zeros without explicit initializers.
Signed-off-by: NMasahiro Yamada <masahiroy@kernel.org>
Reviewed-by: NNick Desaulniers <ndesaulniers@google.com>

The assigned 'export' is only used when

    if (strstarts(symname, "__ksymtab_"))

is met. The else-part of the assignment is the dead code.

Move the export_from_secname() call to where it is used.
Signed-off-by: NMasahiro Yamada <masahiroy@kernel.org>
Reviewed-by: NNick Desaulniers <ndesaulniers@google.com>

With commit 1743694e ("modpost: stop symbol preloading for
modversion CRC") applied, now export_from_sec() is useless.

handle_symbol() is called for every symbol in the ELF.

When 'symname' does not start with "__ksymtab", export_from_sec() is
called, and the returned value is stored in 'export'.

It is used in the last part of handle_symbol():

    if (strstarts(symname, "__ksymtab_")) {
            name = symname + strlen("__ksymtab_");
            sym_add_exported(name, mod, export);
    }

'export' is used only when 'symname' starts with "__ksymtab_".

So, the value returned by export_from_sec() is never used.

Remove useless export_from_sec(). This makes further cleanups possible.

I put the temporary code:

    export = export_unknown;

Otherwise, I would get the compiler warning:

    warning: 'export' may be used uninitialized in this function [-Wmaybe-uninitialized]

This is apparently false positive because

    if (strstarts(symname, "__ksymtab_")

... is a stronger condition than:

    if (strstarts(symname, "__ksymtab")

Anyway, this part will be cleaned up by the next commit.
Signed-off-by: NMasahiro Yamada <masahiroy@kernel.org>
Reviewed-by: NNick Desaulniers <ndesaulniers@google.com>

This log message was accidentally chopped off.

I was wondering why this happened, but checking the ML log, Mark
precisely followed my suggestion [1].

I just used "..." because I was too lazy to type the sentence fully.
Sorry for the confusion.

[1]: https://lore.kernel.org/all/CAK7LNAR6bXXk9-ZzZYpTqzFqdYbQsZHmiWspu27rtsFxvfRuVA@mail.gmail.com/

Fixes: 4a679593 ("kbuild: modpost: Explicitly warn about unprototyped symbols")
Signed-off-by: NMasahiro Yamada <masahiroy@kernel.org>
Acked-by: NMark Brown <broonie@kernel.org>
Reviewed-by: NNick Desaulniers <ndesaulniers@google.com>

Masahiro-san deemed my kbuild changes to support whole module objtool
runs too terrible to live and gracefully provided an alternative.
Suggested-by: NMasahiro Yamada <masahiroy@kernel.org>
Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org>
Link: https://lkml.kernel.org/r/CAK7LNAQ2mYMnOKMQheVi+6byUFE3KEkjm1zcndNUfe0tORGvug@mail.gmail.com

The kernel is moving from using `-std=gnu89` to `-std=gnu11`, permitting
the use of additional C11 features such as for-loop initial declarations.

One contentious aspect of C99 is that it permits mixed declarations and
code, and for now at least, it seems preferable to enforce that
declarations must come first.

These warnings were already enabled in the kernel itself, but not
for KBUILD_USERCFLAGS or the compat VDSO on arch/arm64, which uses
a separate set of CFLAGS.

This patch fixes an existing violation in modpost.c, which is not
reported because of the missing flag in KBUILD_USERCFLAGS:

| scripts/mod/modpost.c: In function ‘match’:
| scripts/mod/modpost.c:837:3: warning: ISO C90 forbids mixed declarations and code [-Wdeclaration-after-statement]
|   837 |   const char *endp = p + strlen(p) - 1;
|       |   ^~~~~
Signed-off-by: NMark Rutland <mark.rutland@arm.com>
[arnd: don't add a duplicate flag to the default set, update changelog]
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Reviewed-by: NNathan Chancellor <nathan@kernel.org>
Reviewed-by: NNick Desaulniers <ndesaulniers@google.com>
Tested-by: Sedat Dilek <sedat.dilek@gmail.com> # LLVM/Clang v13.0.0 (x86-64)
Signed-off-by: NMasahiro Yamada <masahiroy@kernel.org>

Currently with -mindirect-branch=thunk and -mfunction-return=thunk compiler
options expoline thunks are put into individual COMDAT group sections. s390
is the only architecture which has group sections and it has implications
for kpatch and objtool tools support.

Using -mindirect-branch=thunk-extern and -mfunction-return=thunk-extern
is an alternative, which comes with a need to generate all required
expoline thunks manually. Unfortunately modules area is too far away from
the kernel image, and expolines from the kernel image cannon be used.
But since all new distributions (except Debian) build kernels for machine
generations newer than z10, where "exrl" instruction is available, that
leaves only 16 expolines thunks possible.

Provide an option to build the kernel with
-mindirect-branch=thunk-extern and -mfunction-return=thunk-extern for
z10 or newer. This also requires to postlink expoline thunks into all
modules explicitly. Currently modules already contain most expolines
anyhow.

Unfortunately -mindirect-branch=thunk-extern and
-mfunction-return=thunk-extern options support is broken in gcc <= 11.2.
Additional compile test is required to verify proper gcc support.
Acked-by: NIlya Leoshkevich <iii@linux.ibm.com>
Co-developed-by: NSumanth Korikkar <sumanthk@linux.ibm.com>
Signed-off-by: NSumanth Korikkar <sumanthk@linux.ibm.com>
Signed-off-by: NVasily Gorbik <gor@linux.ibm.com>

Similar as other architectures such as arm64, x86 and so on, use
offsets relative to the exception table entry values rather than
absolute addresses for both the exception locationand the fixup.

However, RISCV label difference will actually produce two relocations,
a pair of R_RISCV_ADD32 and R_RISCV_SUB32. Take below simple code for
example:

$ cat test.S
.section .text
1:
        nop
.section __ex_table,"a"
        .balign 4
        .long (1b - .)
.previous

$ riscv64-linux-gnu-gcc -c test.S
$ riscv64-linux-gnu-readelf -r test.o
Relocation section '.rela__ex_table' at offset 0x100 contains 2 entries:
  Offset          Info           Type           Sym. Value    Sym. Name + Addend
000000000000  000600000023 R_RISCV_ADD32     0000000000000000 .L1^B1 + 0
000000000000  000500000027 R_RISCV_SUB32     0000000000000000 .L0  + 0

The modpost will complain the R_RISCV_SUB32 relocation, so we need to
patch modpost.c to skip this relocation for .rela__ex_table section.

After this patch, the __ex_table section size of defconfig vmlinux is
reduced from 7072 Bytes to 3536 Bytes.
Signed-off-by: NJisheng Zhang <jszhang@kernel.org>
Reviewed-by: NKefeng Wang <wangkefeng.wang@huawei.com>
Signed-off-by: NPalmer Dabbelt <palmer@rivosinc.com>

get_src_version() strips 'o' or 'lto.o' from the end of the object file
path (so, postfixlen is 1 or 5), then adds 'mod'.

If you look at the code closely, mod->name already holds the base path
with the extension stripped.

Most of the code changes made by commit 7ac204b5 ("modpost: lto:
strip .lto from module names") was actually unneeded.

sumversion.c does not need strends(), so it can get back local in
modpost.c again.
Signed-off-by: NMasahiro Yamada <masahiroy@kernel.org>

Using asm goto in __WARN_FLAGS() and WARN_ON() allows more
flexibility to GCC.

For that add an entry to the exception table so that
program_check_exception() knowns where to resume execution
after a WARNING.

Here are two exemples. The first one is done on PPC32 (which
benefits from the previous patch), the second is on PPC64.

	unsigned long test(struct pt_regs *regs)
	{
		int ret;

		WARN_ON(regs->msr & MSR_PR);

		return regs->gpr[3];
	}

	unsigned long test9w(unsigned long a, unsigned long b)
	{
		if (WARN_ON(!b))
			return 0;
		return a / b;
	}

Before the patch:

	000003a8 <test>:
	 3a8:	81 23 00 84 	lwz     r9,132(r3)
	 3ac:	71 29 40 00 	andi.   r9,r9,16384
	 3b0:	40 82 00 0c 	bne     3bc <test+0x14>
	 3b4:	80 63 00 0c 	lwz     r3,12(r3)
	 3b8:	4e 80 00 20 	blr

	 3bc:	0f e0 00 00 	twui    r0,0
	 3c0:	80 63 00 0c 	lwz     r3,12(r3)
	 3c4:	4e 80 00 20 	blr

	0000000000000bf0 <.test9w>:
	 bf0:	7c 89 00 74 	cntlzd  r9,r4
	 bf4:	79 29 d1 82 	rldicl  r9,r9,58,6
	 bf8:	0b 09 00 00 	tdnei   r9,0
	 bfc:	2c 24 00 00 	cmpdi   r4,0
	 c00:	41 82 00 0c 	beq     c0c <.test9w+0x1c>
	 c04:	7c 63 23 92 	divdu   r3,r3,r4
	 c08:	4e 80 00 20 	blr

	 c0c:	38 60 00 00 	li      r3,0
	 c10:	4e 80 00 20 	blr

After the patch:

	000003a8 <test>:
	 3a8:	81 23 00 84 	lwz     r9,132(r3)
	 3ac:	71 29 40 00 	andi.   r9,r9,16384
	 3b0:	40 82 00 0c 	bne     3bc <test+0x14>
	 3b4:	80 63 00 0c 	lwz     r3,12(r3)
	 3b8:	4e 80 00 20 	blr

	 3bc:	0f e0 00 00 	twui    r0,0

	0000000000000c50 <.test9w>:
	 c50:	7c 89 00 74 	cntlzd  r9,r4
	 c54:	79 29 d1 82 	rldicl  r9,r9,58,6
	 c58:	0b 09 00 00 	tdnei   r9,0
	 c5c:	7c 63 23 92 	divdu   r3,r3,r4
	 c60:	4e 80 00 20 	blr

	 c70:	38 60 00 00 	li      r3,0
	 c74:	4e 80 00 20 	blr

In the first exemple, we see GCC doesn't need to duplicate what
happens after the trap.

In the second exemple, we see that GCC doesn't need to emit a test
and a branch in the likely path in addition to the trap.

We've got some WARN_ON() in .softirqentry.text section so it needs
to be added in the OTHER_TEXT_SECTIONS in modpost.c
Signed-off-by: NChristophe Leroy <christophe.leroy@csgroup.eu>
Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/389962b1b702e3c78d169e59bcfac56282889173.1618331882.git.christophe.leroy@csgroup.eu

One common cause of modpost version generation failures is a failure to
prototype exported assembly functions - the tooling requires this for
exported functions even if they are not and should not be called from C
code in order to do the version mangling for symbols. Unfortunately the
error message is currently rather abstruse, simply saying that "version
generation failed" and even diving into the code doesn't directly show
what's going on since there's several steps between the problem and it
being observed.

Provide an explicit hint as to the likely cause of a version generation
failure to help anyone who runs into this in future more readily diagnose
and fix the problem.
Signed-off-by: NMark Brown <broonie@kernel.org>
Signed-off-by: NMasahiro Yamada <masahiroy@kernel.org>

Currently, clang LTO built vmlinux won't work with pahole.
LTO introduced cross-cu dwarf tag references and broke
current pahole model which handles one cu as a time.
The solution is to merge all cu's as one pahole cu as in [1].
We would like to do this merging only if cross-cu dwarf
references happens. The LTO build mode is a pretty good
indication for that.

In earlier version of this patch ([2]), clang flag
-grecord-gcc-switches is proposed to add to compilation flags
so pahole could detect "-flto" and then merging cu's.
This will increate the binary size of 1% without LTO though.

Arnaldo suggested to use a note to indicate the vmlinux
is built with LTO. Such a cheap way to get whether the vmlinux
is built with LTO or not helps pahole but is also useful
for tracing as LTO may inline/delete/demote global functions,
promote static functions, etc.

So this patch added an elfnote with a new type LINUX_ELFNOTE_LTO_INFO.
The owner of the note is "Linux".

With gcc 8.4.1 and clang trunk, without LTO, I got
  $ readelf -n vmlinux
  Displaying notes found in: .notes
    Owner                Data size        Description
  ...
    Linux                0x00000004       func
     description data: 00 00 00 00
  ...
With "readelf -x ".notes" vmlinux", I can verify the above "func"
with type code 0x101.

With clang thin-LTO, I got the same as above except the following:
     description data: 01 00 00 00
which indicates the vmlinux is built with LTO.

  [1] https://lore.kernel.org/bpf/20210325065316.3121287-1-yhs@fb.com/
  [2] https://lore.kernel.org/bpf/20210331001623.2778934-1-yhs@fb.com/Suggested-by: NArnaldo Carvalho de Melo <arnaldo.melo@gmail.com>
Signed-off-by: NYonghong Song <yhs@fb.com>
Reviewed-by: NNick Desaulniers <ndesaulniers@google.com>
Tested-by: Sedat Dilek <sedat.dilek@gmail.com> # LLVM/Clang v12.0.0-rc4 (x86-64)
Tested-by: NArnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: NMasahiro Yamada <masahiroy@kernel.org>

s/agorithm/algorithm/
s/criterias/criteria/
s/targetting/targeting/   ....two different places.
Signed-off-by: NBhaskar Chowdhury <unixbhaskar@gmail.com>
Signed-off-by: NMasahiro Yamada <masahiroy@kernel.org>

Nathan reports that the mips defconfig emits the following warning:

  WARNING: modpost: Symbol info of vmlinux is missing. Unresolved symbol check will be entirely skipped.

This false-positive happens when CONFIG_TRIM_UNUSED_KSYMS is enabled,
but no CONFIG option is set to 'm'.

Commit a0590473 ("nfs: fix PNFS_FLEXFILE_LAYOUT Kconfig default")
turned the last 'm' into 'y' for the mips defconfig, and uncovered
this issue.

In this case, the module feature itself is enabled, but we have no
module to build. As a result, CONFIG_TRIM_UNUSED_KSYMS drops all the
instances of EXPORT_SYMBOL. Then, modpost wrongly assumes vmlinux is
missing because vmlinux.symvers is empty. (As another false-positive
case, you can create a module that does not use any symbol of vmlinux).

The current behavior is to entirely suppress the unresolved symbol
warnings when vmlinux is missing just because there are too many.
I found the origin of this code in the historical git tree. [1]

If this is a matter of noisiness, I think modpost can display the
first 10 warnings, and the number of suppressed warnings at the end.

You will get a bit noisier logs when you run 'make modules' without
vmlinux, but such warnings are better to show because you never know
the resulting modules are actually loadable or not.

This commit changes the following:

 - If any of input *.symver files is missing, pass -w option to let
   the module build keep going with warnings instead of errors.

 - If there are too many (10+) unresolved symbol warnings, show only
   the first 10, and also the number of suppressed warnings.

[1]: https://git.kernel.org/pub/scm/linux/kernel/git/history/history.git/commit/?id=1cc0e0529569bf6a94f6d49770aa6d4b599d2c46Reported-by: NNathan Chancellor <nathan@kernel.org>
Signed-off-by: NMasahiro Yamada <masahiroy@kernel.org>

The external module build shows the following warning if Module.symvers
is missing in the kernel tree.

  WARNING: Symbol version dump "Module.symvers" is missing.
           Modules may not have dependencies or modversions.

I think this is an important heads-up because the resulting modules may
not work as expected. This happens when you did not build the entire
kernel tree, for example, you might have prepared the minimal setups
for external modules by 'make defconfig && make modules_preapre'.

A problem is that 'make modules' creates Module.symvers even without
vmlinux. In this case, that warning is suppressed since Module.symvers
already exists in spite of its incomplete content.

The incomplete (i.e. invalid) Module.symvers should not be created.

This commit changes the second pass of modpost to dump symbols into
modules-only.symvers. The final Module.symvers is created by
concatenating vmlinux.symvers and modules-only.symvers if both exist.

Module.symvers is supposed to collect symbols from both vmlinux and
modules. It might be a bit confusing, and I am not quite sure if it
is an official interface, but presumably it is difficult to rename it
because some tools (e.g. kmod) parse it.
Signed-off-by: NMasahiro Yamada <masahiroy@kernel.org>

EXPORT_UNUSED_SYMBOL* is not actually used anywhere.  Remove the
unused functionality as we generally just remove unused code anyway.
Reviewed-by: NMiroslav Benes <mbenes@suse.cz>
Reviewed-by: NEmil Velikov <emil.l.velikov@gmail.com>
Signed-off-by: NChristoph Hellwig <hch@lst.de>
Signed-off-by: NJessica Yu <jeyu@kernel.org>

As far as I can tell this has never been used at all, and certainly
not any time recently.
Reviewed-by: NMiroslav Benes <mbenes@suse.cz>
Reviewed-by: NEmil Velikov <emil.l.velikov@gmail.com>
Signed-off-by: NChristoph Hellwig <hch@lst.de>
Signed-off-by: NJessica Yu <jeyu@kernel.org>

With LTO, everything is compiled into LLVM bitcode, so we have to link
each module into native code before modpost. Kbuild uses the .lto.o
suffix for these files, which also ends up in module information. This
change strips the unnecessary .lto suffix from the module name.
Suggested-by: NBill Wendling <morbo@google.com>
Signed-off-by: NSami Tolvanen <samitolvanen@google.com>
Reviewed-by: NKees Cook <keescook@chromium.org>
Signed-off-by: NKees Cook <keescook@chromium.org>
Link: https://lore.kernel.org/r/20201211184633.3213045-11-samitolvanen@google.com

Using EXPORT_SYMBOL*() on static functions is fundamentally wrong.
Modpost currently reports that as a warning, but clearly this is not a
pattern we should allow, and all in-tree occurences should have been
fixed by now. So, promote the warn() message to error() to make sure
this never happens again.
Acked-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Reviewed-by: NMatthias Maennich <maennich@google.com>
Signed-off-by: NQuentin Perret <qperret@google.com>
Signed-off-by: NMasahiro Yamada <masahiroy@kernel.org>