Many architectures have similar install.sh scripts.
The first half is really generic; it verifies that the kernel image
and System.map exist, then executes ~/bin/${INSTALLKERNEL} or
/sbin/${INSTALLKERNEL} if available.
The second half is kind of arch-specific; it copies the kernel image
and System.map to the destination, but the code is slightly different.
Factor out the generic part into scripts/install.sh.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Reviewed-by: Nicolas Schier <n.schier@avm.de>
It's not meaningful for the GCC plugins to track their versions separately
from the rest of the kernel. Switch all versions to the kernel version.
Fix mismatched indenting while we're at it.
Cc: linux-hardening@vger.kernel.org
Signed-off-by: Kees Cook <keescook@chromium.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: Masahiro Yamada <masahiroy@kernel.org>
Reviewed-by: Nick 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: Masahiro Yamada <masahiroy@kernel.org>
Reviewed-by: Nick 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: Masahiro Yamada <masahiroy@kernel.org>
Reviewed-by: Nick 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: Masahiro Yamada <masahiroy@kernel.org>
Reviewed-by: Nick 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: Masahiro Yamada <masahiroy@kernel.org>
Reviewed-by: Nick 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: Masahiro Yamada <masahiroy@kernel.org>
Reviewed-by: Nick 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: Masahiro Yamada <masahiroy@kernel.org>
Reviewed-by: Nick 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: Masahiro Yamada <masahiroy@kernel.org>
Reviewed-by: Nick 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: Masahiro Yamada <masahiroy@kernel.org>
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
Import include/linux/list.h to use convenient list macros in modpost.
I dropped kernel-space code such as {WRITE,READ}_ONCE etc. and unneeded
macros.
I also imported container_of() from include/linux/container_of.h and
type definitions from include/linux/types.h.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Reviewed-by: Nick 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 1d6cd39293 ("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: Masahiro Yamada <masahiroy@kernel.org>
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
I think this hack is a bad idea. arch/powerpc/boot/Makefile is the
only and last user. Let's stop doing this.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Acked-by: Michael Ellerman <mpe@ellerman.id.au> (powerpc)
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: Masahiro Yamada <masahiroy@kernel.org>
Reviewed-by: Nick 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: Masahiro Yamada <masahiroy@kernel.org>
Reviewed-by: Nick 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=2763b6bcb96e6a38a2fe31108fe5759ec5bcc80a
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Reviewed-by: Nick 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 040fcc819a ("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: Masahiro Yamada <masahiroy@kernel.org>
Reviewed-by: Nick 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: Masahiro Yamada <masahiroy@kernel.org>
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
