summaryrefslogtreecommitdiff
path: root/scripts/mod
AgeCommit message (Collapse)Author
2020-03-13modpost: return error if module is missing ns imports and ↵Jessica Yu
MODULE_ALLOW_MISSING_NAMESPACE_IMPORTS=n Currently when CONFIG_MODULE_ALLOW_MISSING_NAMESPACE_IMPORTS=n, modpost only warns when a module is missing namespace imports. Under this configuration, such a module cannot be loaded into the kernel anyway, as the module loader would reject it. We might as well return a build error when a module is missing namespace imports under CONFIG_MODULE_ALLOW_MISSING_NAMESPACE_IMPORTS=n, so that the build warning does not go ignored/unnoticed. Signed-off-by: Jessica Yu <jeyu@kernel.org> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2020-03-13modpost: rework and consolidate logging interfaceJessica Yu
Rework modpost's logging interface by consolidating merror(), warn(), and fatal() to use a single function, modpost_log(). Introduce different logging levels (WARN, ERROR, FATAL) as well. The purpose of this cleanup is to reduce code duplication when deciding whether or not to warn or error out based on a condition. Signed-off-by: Jessica Yu <jeyu@kernel.org> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2020-02-28i3c: Generate aliases for i3c modulesBoris Brezillon
This part was missing, thus preventing user space from loading modules automatically when MODALIAS uevents are received. Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com> Signed-off-by: Vitor Soares <vitor.soares@synopsys.com> Link: https://lore.kernel.org/linux-i3c/79687073b915182e06fccfb18adcedfd0fadbc99.1582796652.git.vitor.soares@synopsys.com
2020-02-04kbuild: rename hostprogs-y/always to hostprogs/always-yMasahiro Yamada
In old days, the "host-progs" syntax was used for specifying host programs. It was renamed to the current "hostprogs-y" in 2004. It is typically useful in scripts/Makefile because it allows Kbuild to selectively compile host programs based on the kernel configuration. This commit renames like follows: always -> always-y hostprogs-y -> hostprogs So, scripts/Makefile will look like this: always-$(CONFIG_BUILD_BIN2C) += ... always-$(CONFIG_KALLSYMS) += ... ... hostprogs := $(always-y) $(always-m) I think this makes more sense because a host program is always a host program, irrespective of the kernel configuration. We want to specify which ones to compile by CONFIG options, so always-y will be handier. The "always", "hostprogs-y", "hostprogs-m" will be kept for backward compatibility for a while. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2020-01-16modpost: assume STT_SPARC_REGISTER is definedMasahiro Yamada
Commit 8d5290149ee1 ("[SPARC]: Deal with glibc changing macro names in modpost.c") was more than 14 years ago. STT_SPARC_REGISTER is hopefully defined in elf.h of recent C libraries. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Acked-by: David S. Miller <davem@davemloft.net>
2019-11-23modpost: respect the previous export when 'exported twice' is warnedMasahiro Yamada
When 'exported twice' is warned, let sym_add_exported() return without updating the symbol info. This respects the previous export, which is ordered first in modules.order This simplifies the code too. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2019-11-23modpost: do not set ->preloaded for symbols from Module.symversMasahiro Yamada
Now that there is no overwrap between symbols from ELF files and ones from Module.symvers. So, the 'exported twice' warning should be reported irrespective of where the symbol in question came from. The exceptional case is external module; in some cases, we build an external module to provide a different version/variant of the corresponding in-kernel module, overriding the same set of exported symbols. You can see this use-case in upstream; tools/testing/nvdimm/libnvdimm.ko replaces drivers/nvdimm/libnvdimm.ko in order to link it against mocked version of core kernel symbols. So, let's relax the 'exported twice' warning when building external modules. The multiple export from external modules is warned only when the previous one is from vmlinux or itself. With this refactoring, the ugly preloading goes away. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2019-11-23modpost: stop symbol preloading for modversion CRCMasahiro Yamada
It is complicated to add mocked-up symbols for pre-handling CRC. Handle CRC after all the export symbols in the relevant module are registered. Call handle_modversion() after the handle_symbol() iteration. In some cases, I see atand-alone __crc_* without __ksymtab_*. For example, ARCH=arm allyesconfig produces __crc_ccitt_veneer and __crc_itu_t_veneer. I guess they come from crc_ccitt, crc_itu_t, respectively. Since __*_veneer are auto-generated symbols, just ignore them. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2019-11-23modpost: rename handle_modversions() to handle_symbol()Masahiro Yamada
This function handles not only modversions, but also unresolved symbols, export symbols, etc. Rename it to a more proper function name. While I was here, I also added the 'const' qualifier to *sym. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2019-11-23modpost: refactor namespace_from_kstrtabns() to not hard-code section nameMasahiro Yamada
Currently, namespace_from_kstrtabns() relies on the fact that namespace strings are recorded in the __ksymtab_strings section. Actually, it is coded in include/linux/export.h, but modpost does not need to hard-code the section name. Elf_Sym::st_shndx holds the index of the relevant section. Using it is a more portable way to get the namespace string. Make namespace_from_kstrtabns() simply call sym_get_data(), and delete the info->ksymtab_strings . While I was here, I added more 'const' qualifiers to pointers. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2019-11-23modpost: add a helper to get data pointed by a symbolMasahiro Yamada
When CONFIG_MODULE_REL_CRCS is enabled, the value of __crc_* is not an absolute value, but the address to the CRC data embedded in the .rodata section. Getting the data pointed by the symbol value is somewhat complex. Split it out into a new helper, sym_get_data(). I will reuse it to refactor namespace_from_kstrtabns() in the next commit. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2019-11-11modpost: remove unneeded local variable in contains_namespace()Masahiro Yamada
The local variable, ns_entry, is unneeded. While I was here, I also cleaned up the comparison with NULL or 0. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Reviewed-by: Matthias Maennich <maennich@google.com>
2019-11-11modpost: dump missing namespaces into a single modules.nsdeps fileMasahiro Yamada
The modpost, with the -d option given, generates per-module .ns_deps files. Kbuild generates per-module .mod files to carry module information. This is convenient because Make handles multiple jobs in parallel when the -j option is given. On the other hand, the modpost always runs as a single thread. I do not see a strong reason to produce separate .ns_deps files. This commit changes the modpost to generate just one file, modules.nsdeps, each line of which has the following format: <module_name>: <list of missing namespaces> Please note it contains *missing* namespaces instead of required ones. So, modules.nsdeps is empty if the namespace dependency is all good. This will work more efficiently because spatch will no longer process already imported namespaces. I removed the '(if needed)' from the nsdeps log since spatch is invoked only when needed. This also solves the stale .ns_deps problem reported by Jessica Yu: https://lkml.org/lkml/2019/10/28/467 Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Tested-by: Jessica Yu <jeyu@kernel.org> Acked-by: Jessica Yu <jeyu@kernel.org> Reviewed-by: Matthias Maennich <maennich@google.com> Tested-by: Matthias Maennich <maennich@google.com>
2019-11-11modpost: free ns_deps_buf.p after writing ns_deps filesMasahiro Yamada
buf_write() allocates memory. Free it. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2019-11-11modpost: do not invoke extra modpost for nsdepsMasahiro Yamada
'make nsdeps' invokes the modpost three times at most; before linking vmlinux, before building modules, and finally for generating .ns_deps files. Running the modpost again and again is not efficient. The last two can be unified. When the -d option is given, the modpost still does the usual job, and in addition, generates .ns_deps files. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Tested-by: Matthias Maennich <maennich@google.com> Reviewed-by: Matthias Maennich <maennich@google.com>
2019-11-11kbuild: do not read $(KBUILD_EXTMOD)/Module.symversMasahiro Yamada
Since commit 040fcc819a2e ("kbuild: improved modversioning support for external modules"), the external module build reads Module.symvers in the directory of the module itself, then dumps symbols back into it. It accumulates stale symbols in the file when you build an external module incrementally. The idea behind it was, as the commit log explained, you can copy Modules.symvers from one module to another when you need to pass symbol information between two modules. However, the manual copy of the file sounds questionable to me, and containing stale symbols is a downside. Some time later, commit 0d96fb20b7ed ("kbuild: Add new Kbuild variable KBUILD_EXTRA_SYMBOLS") introduced a saner approach. So, this commit removes the former one. Going forward, the external module build dumps symbols into Module.symvers to be carried via KBUILD_EXTRA_SYMBOLS, but never reads it automatically. With the -I option removed, there is no one to set the external_module flag unless KBUILD_EXTRA_SYMBOLS is passed. Now the -i option does it instead. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2019-10-18symbol namespaces: revert to previous __ksymtab name schemeMatthias Maennich
The introduction of Symbol Namespaces changed the naming schema of the __ksymtab entries from __kysmtab__symbol to __ksymtab_NAMESPACE.symbol. That caused some breakages in tools that depend on the name layout in either the binaries(vmlinux,*.ko) or in System.map. E.g. kmod's depmod would not be able to read System.map without a patch to support symbol namespaces. A warning reported by depmod for namespaced symbols would look like depmod: WARNING: [...]/uas.ko needs unknown symbol usb_stor_adjust_quirks In order to address this issue, revert to the original naming scheme and rather read the __kstrtabns_<symbol> entries and their corresponding values from __ksymtab_strings to update the namespace values for symbols. After having read all symbols and handled them in handle_modversions(), the symbols are created. In a second pass, read the __kstrtabns_ entries and update the namespaces accordingly. Fixes: 8651ec01daed ("module: add support for symbol namespaces.") Reported-by: Stefan Wahren <stefan.wahren@i2se.com> Suggested-by: Masahiro Yamada <yamada.masahiro@socionext.com> Acked-by: Will Deacon <will@kernel.org> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Reviewed-by: Masahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by: Matthias Maennich <maennich@google.com> Signed-off-by: Jessica Yu <jeyu@kernel.org>
2019-10-18modpost: make updating the symbol namespace explicitMatthias Maennich
Setting the symbol namespace of a symbol within sym_add_exported feels displaced and lead to issues in the current implementation of symbol namespaces. This patch makes updating the namespace an explicit call to decouple it from adding a symbol to the export list. Acked-by: Will Deacon <will@kernel.org> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Reviewed-by: Masahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by: Matthias Maennich <maennich@google.com> Signed-off-by: Jessica Yu <jeyu@kernel.org>
2019-10-18modpost: delegate updating namespaces to separate functionMatthias Maennich
Let the function 'sym_update_namespace' take care of updating the namespace for a symbol. While this currently only replaces one single location where namespaces are updated, in a following patch, this function will get more call sites. The function signature is intentionally close to sym_update_crc and taking the name by char* seems like unnecessary work as the symbol has to be looked up again. In a later patch of this series, this concern will be addressed. This function ensures that symbol::namespace is either NULL or has a valid non-empty value. Previously, the empty string was considered 'no namespace' as well and this lead to confusion. Acked-by: Will Deacon <will@kernel.org> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Reviewed-by: Masahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by: Matthias Maennich <maennich@google.com> Signed-off-by: Jessica Yu <jeyu@kernel.org>
2019-10-11Merge tag 'modules-for-v5.4-rc3' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/jeyu/linux Pull module fixes from Jessica Yu: "Code cleanups and kbuild/namespace related fixups from Masahiro. Most importantly, it fixes a namespace-related modpost issue for external module builds - Fix broken external module builds due to a modpost bug in read_dump(), where the namespace was not being strdup'd and sym->namespace would be set to bogus data. - Various namespace-related kbuild fixes and cleanups thanks to Masahiro Yamada" * tag 'modules-for-v5.4-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/jeyu/linux: doc: move namespaces.rst from kbuild/ to core-api/ nsdeps: make generated patches independent of locale nsdeps: fix hashbang of scripts/nsdeps kbuild: fix build error of 'make nsdeps' in clean tree module: rename __kstrtab_ns_* to __kstrtabns_* to avoid symbol conflict modpost: fix broken sym->namespace for external module builds module: swap the order of symbol.namespace scripts: add_namespace: Fix coccicheck failed
2019-10-07modpost: fix broken sym->namespace for external module buildsMasahiro Yamada
Currently, external module builds produce tons of false-positives: WARNING: module <mod> uses symbol <sym> from namespace <ns>, but does not import it. Here, the <ns> part shows a random string. When you build external modules, the symbol info of vmlinux and in-kernel modules are read from $(objtree)/Module.symvers, but read_dump() is buggy in multiple ways: [1] When the modpost is run for vmlinux and in-kernel modules, sym_extract_namespace() allocates memory for the namespace. On the other hand, read_dump() does not, then sym->namespace will point to somewhere in the line buffer of get_next_line(). The data in the buffer will be replaced soon, and sym->namespace will end up with pointing to unrelated data. As a result, check_exports() will show random strings in the warning messages. [2] When there is no namespace, sym_extract_namespace() returns NULL. On the other hand, read_dump() sets namespace to an empty string "". (but, it will be later replaced with unrelated data due to bug [1].) The check_exports() shows a warning unless exp->namespace is NULL, so every symbol read from read_dump() emits the warning, which is mostly false positive. To address [1], sym_add_exported() calls strdup() for s->namespace. The namespace from sym_extract_namespace() must be freed to avoid memory leak. For [2], I changed the if-conditional in check_exports(). This commit also fixes sym_add_exported() to set s->namespace correctly when the symbol is preloaded. Reviewed-by: Matthias Maennich <maennich@google.com> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by: Jessica Yu <jeyu@kernel.org>
2019-10-07module: swap the order of symbol.namespaceMasahiro Yamada
Currently, EXPORT_SYMBOL_NS(_GPL) constructs the kernel symbol as follows: __ksymtab_SYMBOL.NAMESPACE The sym_extract_namespace() in modpost allocates memory for the part SYMBOL.NAMESPACE when '.' is contained. One problem is that the pointer returned by strdup() is lost because the symbol name will be copied to malloc'ed memory by alloc_symbol(). No one will keep track of the pointer of strdup'ed memory. sym->namespace still points to the NAMESPACE part. So, you can free it with complicated code like this: free(sym->namespace - strlen(sym->name) - 1); It complicates memory free. To fix it elegantly, I swapped the order of the symbol and the namespace as follows: __ksymtab_NAMESPACE.SYMBOL then, simplified sym_extract_namespace() so that it allocates memory only for the NAMESPACE part. I prefer this order because it is intuitive and also matches to major languages. For example, NAMESPACE::NAME in C++, MODULE.NAME in Python. Reviewed-by: Matthias Maennich <maennich@google.com> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by: Jessica Yu <jeyu@kernel.org>
2019-10-01modpost: fix static EXPORT_SYMBOL warnings for UML buildMasahiro Yamada
Johannes Berg reports lots of modpost warnings on ARCH=um builds: WARNING: "rename" [vmlinux] is a static EXPORT_SYMBOL WARNING: "lseek" [vmlinux] is a static EXPORT_SYMBOL WARNING: "ftruncate64" [vmlinux] is a static EXPORT_SYMBOL WARNING: "getuid" [vmlinux] is a static EXPORT_SYMBOL WARNING: "lseek64" [vmlinux] is a static EXPORT_SYMBOL WARNING: "unlink" [vmlinux] is a static EXPORT_SYMBOL WARNING: "pwrite64" [vmlinux] is a static EXPORT_SYMBOL WARNING: "close" [vmlinux] is a static EXPORT_SYMBOL WARNING: "opendir" [vmlinux] is a static EXPORT_SYMBOL WARNING: "pread64" [vmlinux] is a static EXPORT_SYMBOL WARNING: "syscall" [vmlinux] is a static EXPORT_SYMBOL WARNING: "readdir" [vmlinux] is a static EXPORT_SYMBOL WARNING: "readdir64" [vmlinux] is a static EXPORT_SYMBOL WARNING: "futimes" [vmlinux] is a static EXPORT_SYMBOL WARNING: "__lxstat" [vmlinux] is a static EXPORT_SYMBOL WARNING: "write" [vmlinux] is a static EXPORT_SYMBOL WARNING: "closedir" [vmlinux] is a static EXPORT_SYMBOL WARNING: "__xstat" [vmlinux] is a static EXPORT_SYMBOL WARNING: "fsync" [vmlinux] is a static EXPORT_SYMBOL WARNING: "__lxstat64" [vmlinux] is a static EXPORT_SYMBOL WARNING: "__fxstat64" [vmlinux] is a static EXPORT_SYMBOL WARNING: "telldir" [vmlinux] is a static EXPORT_SYMBOL WARNING: "printf" [vmlinux] is a static EXPORT_SYMBOL WARNING: "readlink" [vmlinux] is a static EXPORT_SYMBOL WARNING: "__sprintf_chk" [vmlinux] is a static EXPORT_SYMBOL WARNING: "link" [vmlinux] is a static EXPORT_SYMBOL WARNING: "rmdir" [vmlinux] is a static EXPORT_SYMBOL WARNING: "fdatasync" [vmlinux] is a static EXPORT_SYMBOL WARNING: "truncate" [vmlinux] is a static EXPORT_SYMBOL WARNING: "statfs" [vmlinux] is a static EXPORT_SYMBOL WARNING: "__errno_location" [vmlinux] is a static EXPORT_SYMBOL WARNING: "__xmknod" [vmlinux] is a static EXPORT_SYMBOL WARNING: "open64" [vmlinux] is a static EXPORT_SYMBOL WARNING: "truncate64" [vmlinux] is a static EXPORT_SYMBOL WARNING: "open" [vmlinux] is a static EXPORT_SYMBOL WARNING: "read" [vmlinux] is a static EXPORT_SYMBOL WARNING: "chown" [vmlinux] is a static EXPORT_SYMBOL WARNING: "chmod" [vmlinux] is a static EXPORT_SYMBOL WARNING: "utime" [vmlinux] is a static EXPORT_SYMBOL WARNING: "fchmod" [vmlinux] is a static EXPORT_SYMBOL WARNING: "seekdir" [vmlinux] is a static EXPORT_SYMBOL WARNING: "ioctl" [vmlinux] is a static EXPORT_SYMBOL WARNING: "dup2" [vmlinux] is a static EXPORT_SYMBOL WARNING: "statfs64" [vmlinux] is a static EXPORT_SYMBOL WARNING: "utimes" [vmlinux] is a static EXPORT_SYMBOL WARNING: "mkdir" [vmlinux] is a static EXPORT_SYMBOL WARNING: "fchown" [vmlinux] is a static EXPORT_SYMBOL WARNING: "__guard" [vmlinux] is a static EXPORT_SYMBOL WARNING: "symlink" [vmlinux] is a static EXPORT_SYMBOL WARNING: "access" [vmlinux] is a static EXPORT_SYMBOL WARNING: "__stack_smash_handler" [vmlinux] is a static EXPORT_SYMBOL When you run "make", the modpost is run twice; before linking vmlinux, and before building modules. All the warnings above are from the second modpost. The offending symbols are defined not in vmlinux, but in the C library. The first modpost is run against the relocatable vmlinux.o, and those warnings are nicely suppressed because the SH_UNDEF entries from the symbol table clear the ->is_static flag. The second modpost is run against the executable vmlinux (+ modules), where those symbols have been resolved, but the definitions do not exist. This commit fixes it in a straightforward way; suppress the static EXPORT_SYMBOL warnings from "vmlinux". Without this commit, we see valid warnings twice anyway. For example, ARCH=arm64 defconfig shows the following warning twice: WARNING: "HYPERVISOR_platform_op" [vmlinux] is a static EXPORT_SYMBOL_GPL So, it is reasonable to suppress the second one. Fixes: 15bfc2348d54 ("modpost: check for static EXPORT_SYMBOL* functions") Reported-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Tested-by: Johannes Berg <johannes@sipsolutions.net> Tested-by: Denis Efremov <efremov@linux.com>
2019-09-22Merge tag 'modules-for-v5.4' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/jeyu/linux Pull modules updates from Jessica Yu: "The main bulk of this pull request introduces a new exported symbol namespaces feature. The number of exported symbols is increasingly growing with each release (we're at about 31k exports as of 5.3-rc7) and we currently have no way of visualizing how these symbols are "clustered" or making sense of this huge export surface. Namespacing exported symbols allows kernel developers to more explicitly partition and categorize exported symbols, as well as more easily limiting the availability of namespaced symbols to other parts of the kernel. For starters, we have introduced the USB_STORAGE namespace to demonstrate the API's usage. I have briefly summarized the feature and its main motivations in the tag below. Summary: - Introduce exported symbol namespaces. This new feature allows subsystem maintainers to partition and categorize their exported symbols into explicit namespaces. Module authors are now required to import the namespaces they need. Some of the main motivations of this feature include: allowing kernel developers to better manage the export surface, allow subsystem maintainers to explicitly state that usage of some exported symbols should only be limited to certain users (think: inter-module or inter-driver symbols, debugging symbols, etc), as well as more easily limiting the availability of namespaced symbols to other parts of the kernel. With the module import requirement, it is also easier to spot the misuse of exported symbols during patch review. Two new macros are introduced: EXPORT_SYMBOL_NS() and EXPORT_SYMBOL_NS_GPL(). The API is thoroughly documented in Documentation/kbuild/namespaces.rst. - Some small code and kbuild cleanups here and there" * tag 'modules-for-v5.4' of git://git.kernel.org/pub/scm/linux/kernel/git/jeyu/linux: module: Remove leftover '#undef' from export header module: remove unneeded casts in cmp_name() module: move CONFIG_UNUSED_SYMBOLS to the sub-menu of MODULES module: remove redundant 'depends on MODULES' module: Fix link failure due to invalid relocation on namespace offset usb-storage: export symbols in USB_STORAGE namespace usb-storage: remove single-use define for debugging docs: Add documentation for Symbol Namespaces scripts: Coccinelle script for namespace dependencies. modpost: add support for generating namespace dependencies export: allow definition default namespaces in Makefiles or sources module: add config option MODULE_ALLOW_MISSING_NAMESPACE_IMPORTS modpost: add support for symbol namespaces module: add support for symbol namespaces. export: explicitly align struct kernel_symbol module: support reading multiple values per modinfo tag
2019-09-14modpost: use __section in the output to *.mod.cMasahiro Yamada
Use the __section() shorthand. This avoids escaping double-quotes, and improves the readability. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2019-09-14modpost: use MODULE_INFO() for __module_dependsMasahiro Yamada
This makes *.mod.c much more readable. I confirmed depmod still produced the same modules.dep file. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2019-09-10modpost: add support for generating namespace dependenciesMatthias Maennich
This patch adds an option to modpost to generate a <module>.ns_deps file per module, containing the namespace dependencies for that module. E.g. if the linked module my-module.ko would depend on the symbol myfunc.MY_NS in the namespace MY_NS, the my-module.ns_deps file created by modpost would contain the entry MY_NS to express the namespace dependency of my-module imposed by using the symbol myfunc. These files can subsequently be used by static analysis tools (like coccinelle scripts) to address issues with missing namespace imports. A later patch of this series will introduce such a script 'nsdeps' and a corresponding make target to automatically add missing MODULE_IMPORT_NS() definitions to the module's sources. For that it uses the information provided in the generated .ns_deps files. Co-developed-by: Martijn Coenen <maco@android.com> Signed-off-by: Martijn Coenen <maco@android.com> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Matthias Maennich <maennich@google.com> Signed-off-by: Jessica Yu <jeyu@kernel.org>
2019-09-10modpost: add support for symbol namespacesMatthias Maennich
Add support for symbols that are exported into namespaces. For that, extract any namespace suffix from the symbol name. In addition, emit a warning whenever a module refers to an exported symbol without explicitly importing the namespace that it is defined in. This patch consistently adds the namespace suffix to symbol names exported into Module.symvers. Example warning emitted by modpost in case of the above violation: WARNING: module ums-usbat uses symbol usb_stor_resume from namespace USB_STORAGE, but does not import it. Co-developed-by: Martijn Coenen <maco@android.com> Signed-off-by: Martijn Coenen <maco@android.com> Reviewed-by: Joel Fernandes (Google) <joel@joelfernandes.org> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Matthias Maennich <maennich@google.com> Signed-off-by: Jessica Yu <jeyu@kernel.org>
2019-09-04modpost: add NOFAIL to strndupDenis Efremov
Add NOFAIL check for the strndup call, because the function allocates memory and can return NULL. All calls to strdup in modpost are checked with NOFAIL. Signed-off-by: Denis Efremov <efremov@linux.com> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2019-09-04modpost: add guid_t type definitionHeikki Krogerus
Since guid_t is the recommended data type for UUIDs in kernel (and I guess uuid_le is meant to be ultimately replaced with it), it should be made available here as well. Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2019-08-14modpost: check for static EXPORT_SYMBOL* functionsDenis Efremov
This patch adds a check to warn about static EXPORT_SYMBOL* functions during the modpost. In most of the cases, a static symbol marked for exporting is an odd combination that should be fixed either by deleting the exporting mark or by removing the static attribute and adding the appropriate declaration to headers. This check could help to detect the following problems: 1. 550113d4e9f5 ("i2c: add newly exported functions to the header, too") 2. 54638c6eaf44 ("net: phy: make exported variables non-static") 3. 98ef2046f28b ("mm: remove the exporting of totalram_pages") 4. 73df167c819e ("s390/zcrypt: remove the exporting of ap_query_configuration") 5. a57caf8c527f ("sunrpc/cache: remove the exporting of cache_seq_next") 6. e4e4730698c9 ("crypto: skcipher - remove the exporting of skcipher_walk_next") 7. 14b4c48bb1ce ("gve: Remove the exporting of gve_probe") 8. 9b79ee9773a8 ("scsi: libsas: remove the exporting of sas_wait_eh") 9. ... The build time impact is very limited and is almost at the unnoticeable level (< 1 sec). Acked-by: Emil Velikov <emil.l.velikov@gmail.com> Signed-off-by: Denis Efremov <efremov@linux.com> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2019-07-18kbuild: remove the first line of *.mod filesMasahiro Yamada
The current format of *.mod is like this: line 1: directory path to the .ko file line 2: a list of objects linked into this module line 3: unresolved symbols (only when CONFIG_TRIM_UNUSED_KSYMS=y) Now that *.mod and *.ko are created in the same directory, the line 1 provides no valuable information. It can be derived by replacing the extension .mod with .ko. In fact, nobody uses the first line any more. Cut down the first line. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2019-07-18kbuild: create *.mod with full directory path and remove MODVERDIRMasahiro Yamada
While descending directories, Kbuild produces objects for modules, but do not link final *.ko files; it is done in the modpost. To keep track of modules, Kbuild creates a *.mod file in $(MODVERDIR) for every module it is building. Some post-processing steps read the necessary information from *.mod files. This avoids descending into directories again. This mechanism was introduced in 2003 or so. Later, commit 551559e13af1 ("kbuild: implement modules.order") added modules.order. So, we can simply read it out to know all the modules with directory paths. This is easier than parsing the first line of *.mod files. $(MODVERDIR) has a flat directory structure, that is, *.mod files are named only with base names. This is based on the assumption that the module name is unique across the tree. This assumption is really fragile. Stephen Rothwell reported a race condition caused by a module name conflict: https://lkml.org/lkml/2019/5/13/991 In parallel building, two different threads could write to the same $(MODVERDIR)/*.mod simultaneously. Non-unique module names are the source of all kind of troubles, hence commit 3a48a91901c5 ("kbuild: check uniqueness of module names") introduced a new checker script. However, it is still fragile in the build system point of view because this race happens before scripts/modules-check.sh is invoked. If it happens again, the modpost will emit unclear error messages. To fix this issue completely, create *.mod with full directory path so that two threads never attempt to write to the same file. $(MODVERDIR) is no longer needed. Since modules with directory paths are listed in modules.order, Kbuild is still able to find *.mod files without additional descending. I also killed cmd_secanalysis; scripts/mod/sumversion.c computes MD4 hash for modules with MODULE_VERSION(). When CONFIG_DEBUG_SECTION_MISMATCH=y, it occurs not only in the modpost stage, but also during directory descending, where sumversion.c may parse stale *.mod files. It would emit 'No such file or directory' warning when an object consisting a module is renamed, or when a single-obj module is turned into a multi-obj module or vice versa. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Acked-by: Nicolas Pitre <nico@fluxnic.net>
2019-03-28kbuild: modversions: Fix relative CRC byte order interpretationFredrik Noring
Fix commit 56067812d5b0 ("kbuild: modversions: add infrastructure for emitting relative CRCs") where CRCs are interpreted in host byte order rather than proper kernel byte order. The bug is conditional on CONFIG_MODULE_REL_CRCS. For example, when loading a BE module into a BE kernel compiled with a LE system, the error "disagrees about version of symbol module_layout" is produced. A message such as "Found checksum D7FA6856 vs module 5668FAD7" will be given with debug enabled, which indicates an obvious endian problem within __kcrctab within the kernel image. The general solution is to use the macro TO_NATIVE, as is done in similar cases throughout modpost.c. With this correction it has been verified that a BE kernel compiled with a LE system accepts BE modules. This change has also been verified with a LE kernel compiled with a LE system, in which case TO_NATIVE returns its value unmodified since the byte orders match. This is by far the common case. Fixes: 56067812d5b0 ("kbuild: modversions: add infrastructure for emitting relative CRCs") Signed-off-by: Fredrik Noring <noring@nocrew.org> Cc: stable@vger.kernel.org Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2019-03-14modpost: always show verbose warning for section mismatchMasahiro Yamada
Unless CONFIG_DEBUG_SECTION_MISMATCH is enabled, modpost only shows the number of section mismatches. If you want to know the symbols causing the issue, you need to rebuild with CONFIG_DEBUG_SECTION_MISMATCH. It is tedious. I think it is fine to show annoying warning when a new section mismatch comes in. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2019-03-10Merge tag 'platform-drivers-x86-v5.1-1' of ↵Linus Torvalds
git://git.infradead.org/linux-platform-drivers-x86 Pull x86 platform driver updates from Darren Hart: - use MODULE_DEVICE_TABLE across several wmi drivers, keeping wmi_device_id and MODULE_ALIAS() declarations in sync - add several Ideapad models to the no_hw_rfkill list - add support for new Mellanox platforms, including new fan and LED functionality - address Dell keyboard backlight change event and power button release issues - update dell_rbu to use appropriate memory allocation mechanisms - several small fixes and Ice Lake support for intel_pmc_core - fix a suspend regression for Cherry Trail based devices in intel_int0002_vgpio - a few other routine fixes * tag 'platform-drivers-x86-v5.1-1' of git://git.infradead.org/linux-platform-drivers-x86: (50 commits) MAINTAINERS: Include mlxreg.h in Mellanox Platform Driver files platform/x86: ideapad-laptop: Add S130-14IGM to no_hw_rfkill list platform/x86: mlx-platform: Fix access mode for fan_dir attribute platform/x86: mlx-platform: Add UID LED for the next generation systems platform/x86: mlx-platform: Add extra CPLD for next generation systems platform/x86: wmi-bmof: use MODULE_DEVICE_TABLE() instead of MODULE_ALIAS() platform/x86: intel-wmi-thunderbolt: use MODULE_DEVICE_TABLE() instead of MODULE_ALIAS() platform/x86: huawei-wmi: use MODULE_DEVICE_TABLE() instead of MODULE_ALIAS() platform/x86: dell-wmi: use MODULE_DEVICE_TABLE() instead of MODULE_ALIAS() platform/x86: dell-wmi-descriptor: use MODULE_DEVICE_TABLE() instead of MODULE_ALIAS() platform/x86: dell-smbios-wmi: use MODULE_DEVICE_TABLE() instead of MODULE_ALIAS() platform/x86: wmi: add WMI support to MODULE_DEVICE_TABLE() platform/x86: wmi: move struct wmi_device_id to mod_devicetable.h modpost: file2alias: define size of alias platform/x86: touchscreen_dmi: Add info for the CHUWI Hi10 Air tablet platform/x86: ideapad-laptop: Add Ideapad 530S-14ARR to no_hw_rfkill list platform/x86: ideapad-laptop: Add Yoga C930 to no_hw_rfkill_list platform/x86: intel_pmc_core: Quirk to ignore XTAL shutdown platform/x86: intel_pmc_core: Add Package cstates residency info platform/x86: intel_pmc_core: Add ICL platform support ...
2019-03-07platform/x86: wmi: add WMI support to MODULE_DEVICE_TABLE()Mattias Jacobsson
The kernel provides the macro MODULE_DEVICE_TABLE() where driver authors can specify their device type and their array of device_ids and thereby trigger the generation of the appropriate MODULE_ALIAS() output. This is opposed to having to specify one MODULE_ALIAS() for each device. The WMI device type is currently not supported. While using MODULE_DEVICE_TABLE() does increase the complexity as well as spreading out the implementation across the kernel, it does come with some benefits too; * It makes different drivers look more similar; if you can specify the array of device_ids any device type specific input to MODULE_ALIAS() will automatically be generated for you. * It helps each driver avoid keeping multiple versions of the same information in sync. That is, both the array of device_ids and the potential multitude of MODULE_ALIAS()'s. Add WMI support to MODULE_DEVICE_TABLE() by adding info about struct wmi_device_id in devicetable-offsets.c and add a WMI entry point in file2alias.c. The type argument for MODULE_DEVICE_TABLE(type, name) is wmi. Suggested-by: Pali Rohár <pali.rohar@gmail.com> Signed-off-by: Mattias Jacobsson <2pi@mok.nu> Acked-by: Masahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by: Darren Hart (VMware) <dvhart@infradead.org>
2019-03-07platform/x86: wmi: move struct wmi_device_id to mod_devicetable.hMattias Jacobsson
In preparation for adding WMI support to MODULE_DEVICE_TABLE() move the definition of struct wmi_device_id to mod_devicetable.h and inline guid_string in the struct. Changing guid_string to an inline char array changes the loop conditions when looping over an array of struct wmi_device_id. Therefore update wmi_dev_match()'s loop to check for an empty guid_string instead of a NULL pointer. Signed-off-by: Mattias Jacobsson <2pi@mok.nu> [dvhart: Move UUID_STRING_LEN define to this patch] Signed-off-by: Darren Hart (VMware) <dvhart@infradead.org>
2019-03-06modpost: file2alias: define size of aliasMattias Jacobsson
The size of the variable alias provided to do_entry functions are currently not readily available. Thus hindering do_entry functions to perform bounds checking. Define the macro ALIAS_SIZE containing the size of the variable alias. Signed-off-by: Mattias Jacobsson <2pi@mok.nu> Acked-by: Masahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by: Darren Hart (VMware) <dvhart@infradead.org>
2019-02-01tee: add bus driver framework for TEE based devicesSumit Garg
Introduce a generic TEE bus driver concept for TEE based kernel drivers which would like to communicate with TEE based devices/services. Also add support in module device table for these new TEE based devices. In this TEE bus concept, devices/services are identified via Universally Unique Identifier (UUID) and drivers register a table of device UUIDs which they can support. So this TEE bus framework registers following apis: - match(): Iterates over the driver UUID table to find a corresponding match for device UUID. If a match is found, then this particular device is probed via corresponding probe api registered by the driver. This process happens whenever a device or a driver is registered with TEE bus. - uevent(): Notifies user-space (udev) whenever a new device is registered on this bus for auto-loading of modularized drivers. Also this framework allows for device enumeration to be specific to corresponding TEE implementation like OP-TEE etc. Signed-off-by: Sumit Garg <sumit.garg@linaro.org> Reviewed-by: Daniel Thompson <daniel.thompson@linaro.org> Reviewed-by: Bhupesh Sharma <bhsharma@redhat.com> Signed-off-by: Jens Wiklander <jens.wiklander@linaro.org>
2019-01-09x86, modpost: Replace last remnants of RETPOLINE with CONFIG_RETPOLINEWANG Chao
Commit 4cd24de3a098 ("x86/retpoline: Make CONFIG_RETPOLINE depend on compiler support") replaced the RETPOLINE define with CONFIG_RETPOLINE checks. Remove the remaining pieces. [ bp: Massage commit message. ] Fixes: 4cd24de3a098 ("x86/retpoline: Make CONFIG_RETPOLINE depend on compiler support") Signed-off-by: WANG Chao <chao.wang@ucloud.cn> Signed-off-by: Borislav Petkov <bp@suse.de> Reviewed-by: Zhenzhong Duan <zhenzhong.duan@oracle.com> Reviewed-by: Masahiro Yamada <yamada.masahiro@socionext.com> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Andi Kleen <ak@linux.intel.com> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Andy Lutomirski <luto@kernel.org> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Daniel Borkmann <daniel@iogearbox.net> Cc: David Woodhouse <dwmw@amazon.co.uk> Cc: Geert Uytterhoeven <geert@linux-m68k.org> Cc: Jessica Yu <jeyu@kernel.org> Cc: Jiri Kosina <jkosina@suse.cz> Cc: Kees Cook <keescook@chromium.org> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Cc: Luc Van Oostenryck <luc.vanoostenryck@gmail.com> Cc: Michal Marek <michal.lkml@markovi.net> Cc: Miguel Ojeda <miguel.ojeda.sandonis@gmail.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Tim Chen <tim.c.chen@linux.intel.com> Cc: Vasily Gorbik <gor@linux.ibm.com> Cc: linux-kbuild@vger.kernel.org Cc: srinivas.eeda@oracle.com Cc: stable <stable@vger.kernel.org> Cc: x86-ml <x86@kernel.org> Link: https://lkml.kernel.org/r/20181210163725.95977-1-chao.wang@ucloud.cn
2018-12-01kbuild: move modpost out of 'scripts' targetMasahiro Yamada
I am eagar to build under the scripts/ directory only with $(HOSTCC), but scripts/mod/ highly depends on the $(CC) and target arch headers. That it why the 'scripts' target must depend on 'asm-generic', 'gcc-plugins', and $(autoksyms_h). Move it to the 'prepare0' stage. I know this is a cheesy workaround, but better than the current situation. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2018-12-01modpost: move unresolved symbol checks to check_exports()Masahiro Yamada
This will fit better in check_exports() than add_versions(). Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2018-12-01modpost: merge module iterationsMasahiro Yamada
Probably, this is just a matter of the order of error/warning messages. Merge the two for-loops. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2018-12-01modpost: refactor seen flag clearing in add_depends()Masahiro Yamada
You do not need to iterate over all modules for resetting ->seen flag because add_depends() is only interested in modules that export symbols referenced from the given 'mod'. This also avoids shadowing the 'modules' parameter of add_depends(). Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2018-12-01modpost: file2alias: check prototype of handlerMasahiro Yamada
Use specific prototype instead of an opaque pointer so that the compiler can catch function prototype mismatch. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Reviewed-by: Mathieu Malaterre <malat@debian.org>
2018-12-01modpost: file2alias: go back to simple devtable lookupMasahiro Yamada
Commit e49ce14150c6 ("modpost: use linker section to generate table.") was not so cool as we had expected first; it ended up with ugly section hacks when commit dd2a3acaecd7 ("mod/file2alias: make modpost compile on darwin again") came in. Given a certain degree of unknowledge about the link stage of host programs, I really want to see simple, stupid table lookup so that this works in the same way regardless of the underlying executable format. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Acked-by: Mathieu Malaterre <malat@debian.org>
2018-12-01modpost: skip ELF local symbols during section mismatch checkPaul Walmsley
During development of a serial console driver with a gcc 8.2.0 toolchain for RISC-V, the following modpost warning appeared: ---- WARNING: vmlinux.o(.data+0x19b10): Section mismatch in reference from the variable .LANCHOR1 to the function .init.text:sifive_serial_console_setup() The variable .LANCHOR1 references the function __init sifive_serial_console_setup() If the reference is valid then annotate the variable with __init* or __refdata (see linux/init.h) or name the variable: *_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console ---- ".LANCHOR1" is an ELF local symbol, automatically created by gcc's section anchor generation code: https://gcc.gnu.org/onlinedocs/gccint/Anchored-Addresses.html https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/varasm.c;h=cd9591a45617464946dcf9a126dde277d9de9804;hb=9fb89fa845c1b2e0a18d85ada0b077c84508ab78#l7473 This was verified by compiling the kernel with -fno-section-anchors and observing that the ".LANCHOR1" ELF local symbol disappeared, and modpost no longer warned about the section mismatch. The serial driver code idiom triggering the warning is standard Linux serial driver practice that has a specific whitelist inclusion in modpost.c. I'm neither a modpost nor an ELF expert, but naively, it doesn't seem useful for modpost to report section mismatch warnings caused by ELF local symbols by default. Local symbols have compiler-generated names, and thus bypass modpost's whitelisting algorithm, which relies on the presence of a non-autogenerated symbol name. This increases the likelihood that false positive warnings will be generated (as in the above case). Thus, disable section mismatch reporting on ELF local symbols. The rationale here is similar to that of commit 2e3a10a1551d ("ARM: avoid ARM binutils leaking ELF local symbols") and of similar code already present in modpost.c: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/scripts/mod/modpost.c?h=v4.19-rc4&id=7876320f88802b22d4e2daf7eb027dd14175a0f8#n1256 This third version of the patch implements a suggestion from Masahiro Yamada <yamada.masahiro@socionext.com> to restructure the code as an additional pattern matching step inside secref_whitelist(), and further improves the patch description. Signed-off-by: Paul Walmsley <paul.walmsley@sifive.com> Signed-off-by: Paul Walmsley <paul@pwsan.com> Acked-by: Sam Ravnborg <sam@ravnborg.org> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2018-11-21modpost: drop unused command line switchesPaul Walmsley
Drop modpost command line switches that are no longer used by makefile.modpost, upon request from Sam Ravnborg <sam@ravnborg.org>, who wrote: modpost is not supposed to be used outside the kernel build. [...] I checked if there were any options supported by modpost that was not configurable in Makefile.modpost. And I could see that the -M and -K options in getopt() were leftovers. The code that used these option was dropped in: commit a8773769d1a1 ("Kbuild: clear marker out of modpost") Could you add a patch that delete these on top of what you already have. https://lore.kernel.org/lkml/20181020140835.GA3351@ravnborg.org/ Suggested-by: Sam Ravnborg <sam@ravnborg.org> Signed-off-by: Paul Walmsley <paul.walmsley@sifive.com> Signed-off-by: Paul Walmsley <paul@pwsan.com> Acked-by: Sam Ravnborg <sam@ravnborg.org> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2018-11-21modpost: validate symbol names also in find_elf_symbolSami Tolvanen
If an ARM mapping symbol shares an address with a valid symbol, find_elf_symbol can currently return the mapping symbol instead, as the symbol is not validated. This can result in confusing warnings: WARNING: vmlinux.o(.text+0x18f4028): Section mismatch in reference from the function set_reset_devices() to the variable .init.text:$x.0 This change adds a call to is_valid_name to find_elf_symbol, similarly to how it's already used in find_elf_symbol2. Signed-off-by: Sami Tolvanen <samitolvanen@google.com> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>