summaryrefslogtreecommitdiff
path: root/scripts/mod
Commit message (Collapse)AuthorAgeFilesLines
* modpost: respect the previous export when 'exported twice' is warnedMasahiro Yamada2019-11-231-15/+11
| | | | | | | | | | 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>
* modpost: do not set ->preloaded for symbols from Module.symversMasahiro Yamada2019-11-231-4/+2
| | | | | | | | | | | | | | | | | | | | | | | | | 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>
* modpost: stop symbol preloading for modversion CRCMasahiro Yamada2019-11-231-32/+39
| | | | | | | | | | | | | | | | 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>
* modpost: rename handle_modversions() to handle_symbol()Masahiro Yamada2019-11-231-3/+3
| | | | | | | | | | | 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>
* modpost: refactor namespace_from_kstrtabns() to not hard-code section nameMasahiro Yamada2019-11-232-8/+3
| | | | | | | | | | | | | | | | | 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>
* modpost: add a helper to get data pointed by a symbolMasahiro Yamada2019-11-231-4/+13
| | | | | | | | | | | | | | 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>
* modpost: remove unneeded local variable in contains_namespace()Masahiro Yamada2019-11-111-4/+2
| | | | | | | | | 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>
* modpost: dump missing namespaces into a single modules.nsdeps fileMasahiro Yamada2019-11-112-27/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* modpost: free ns_deps_buf.p after writing ns_deps filesMasahiro Yamada2019-11-111-0/+2
| | | | | | buf_write() allocates memory. Free it. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
* modpost: do not invoke extra modpost for nsdepsMasahiro Yamada2019-11-111-7/+2
| | | | | | | | | | | | | '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>
* kbuild: do not read $(KBUILD_EXTMOD)/Module.symversMasahiro Yamada2019-11-111-7/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* symbol namespaces: revert to previous __ksymtab name schemeMatthias Maennich2019-10-182-15/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* modpost: make updating the symbol namespace explicitMatthias Maennich2019-10-181-6/+6
| | | | | | | | | | | | | 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>
* modpost: delegate updating namespaces to separate functionMatthias Maennich2019-10-181-3/+21
| | | | | | | | | | | | | | | | | | | | | | 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>
* Merge tag 'modules-for-v5.4-rc3' of ↵Linus Torvalds2019-10-111-14/+15
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
| * modpost: fix broken sym->namespace for external module buildsMasahiro Yamada2019-10-071-5/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * module: swap the order of symbol.namespaceMasahiro Yamada2019-10-071-9/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | modpost: fix static EXPORT_SYMBOL warnings for UML buildMasahiro Yamada2019-10-011-4/+9
|/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* Merge tag 'modules-for-v5.4' of ↵Linus Torvalds2019-09-222-17/+142
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
| * modpost: add support for generating namespace dependenciesMatthias Maennich2019-09-102-5/+51
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * modpost: add support for symbol namespacesMatthias Maennich2019-09-102-16/+95
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | modpost: use __section in the output to *.mod.cMasahiro Yamada2019-09-141-3/+2
| | | | | | | | | | | | | | Use the __section() shorthand. This avoids escaping double-quotes, and improves the readability. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
* | modpost: use MODULE_INFO() for __module_dependsMasahiro Yamada2019-09-141-5/+2
| | | | | | | | | | | | | | 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>
* | modpost: add NOFAIL to strndupDenis Efremov2019-09-041-2/+2
| | | | | | | | | | | | | | | | | | 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>
* | modpost: add guid_t type definitionHeikki Krogerus2019-09-041-0/+5
| | | | | | | | | | | | | | | | | | | | 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>
* | modpost: check for static EXPORT_SYMBOL* functionsDenis Efremov2019-08-141-0/+32
|/ | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* kbuild: remove the first line of *.mod filesMasahiro Yamada2019-07-181-7/+2
| | | | | | | | | | | | | | | | 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>
* kbuild: create *.mod with full directory path and remove MODVERDIRMasahiro Yamada2019-07-181-13/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* kbuild: modversions: Fix relative CRC byte order interpretationFredrik Noring2019-03-281-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* modpost: always show verbose warning for section mismatchMasahiro Yamada2019-03-141-22/+5
| | | | | | | | | | | | | 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>
* Merge tag 'platform-drivers-x86-v5.1-1' of ↵Linus Torvalds2019-03-102-1/+30
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 ...
| * platform/x86: wmi: add WMI support to MODULE_DEVICE_TABLE()Mattias Jacobsson2019-03-072-0/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * platform/x86: wmi: move struct wmi_device_id to mod_devicetable.hMattias Jacobsson2019-03-071-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * modpost: file2alias: define size of aliasMattias Jacobsson2019-03-061-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | 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>
* | tee: add bus driver framework for TEE based devicesSumit Garg2019-02-012-0/+22
|/ | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* x86, modpost: Replace last remnants of RETPOLINE with CONFIG_RETPOLINEWANG Chao2019-01-091-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* kbuild: move modpost out of 'scripts' targetMasahiro Yamada2018-12-011-2/+0
| | | | | | | | | | | | 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>
* modpost: move unresolved symbol checks to check_exports()Masahiro Yamada2018-12-011-15/+18
| | | | | | This will fit better in check_exports() than add_versions(). Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
* modpost: merge module iterationsMasahiro Yamada2018-12-011-6/+1
| | | | | | | 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>
* modpost: refactor seen flag clearing in add_depends()Masahiro Yamada2018-12-011-6/+6
| | | | | | | | | | 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>
* modpost: file2alias: check prototype of handlerMasahiro Yamada2018-12-011-4/+3
| | | | | | | | 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>
* modpost: file2alias: go back to simple devtable lookupMasahiro Yamada2018-12-011-95/+49
| | | | | | | | | | | | | | | 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>
* modpost: skip ELF local symbols during section mismatch checkPaul Walmsley2018-12-011-0/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* modpost: drop unused command line switchesPaul Walmsley2018-11-211-1/+1
| | | | | | | | | | | | | | | | | | | | | | | 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>
* modpost: validate symbol names also in find_elf_symbolSami Tolvanen2018-11-211-24/+26
| | | | | | | | | | | | | | | 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>
* Merge tag 'kbuild-v4.20' of ↵Linus Torvalds2018-10-281-8/+18
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild Pull Kbuild updates from Masahiro Yamada: - optimize kallsyms slightly - remove check for old CFLAGS usage - add some compiler flags unconditionally instead of evaluating $(call cc-option,...) - fix variable shadowing in host tools - refactor scripts/mkmakefile - refactor various makefiles * tag 'kbuild-v4.20' of git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild: modpost: Create macro to avoid variable shadowing ASN.1: Remove unnecessary shadowed local variable kbuild: use 'else ifeq' for checksrc to improve readability kbuild: remove unneeded link_multi_deps kbuild: add -Wno-unused-but-set-variable flag unconditionally kbuild: add -Wdeclaration-after-statement flag unconditionally kbuild: add -Wno-pointer-sign flag unconditionally modpost: remove leftover symbol prefix handling for module device table kbuild: simplify command line creation in scripts/mkmakefile kbuild: do not pass $(objtree) to scripts/mkmakefile kbuild: remove user ID check in scripts/mkmakefile kbuild: remove VERSION and PATCHLEVEL from $(objtree)/Makefile kbuild: add --include-dir flag only for out-of-tree build kbuild: remove dead code in cmd_files calculation in top Makefile kbuild: hide most of targets when running config or mixed targets kbuild: remove old check for CFLAGS use kbuild: prefix Makefile.dtbinst path with $(srctree) unconditionally kallsyms: remove left-over Blackfin code kallsyms: reduce size a little on 64-bit
| * modpost: Create macro to avoid variable shadowingLeonardo Bras2018-10-291-4/+15
| | | | | | | | | | | | | | | | | | | | | | | | Create DEF_FIELD_ADDR_VAR as a more generic version of the DEF_FIELD_ADD macro, allowing usage of a variable name other than the struct element name. Also, sets DEF_FIELD_ADDR as a specific usage of DEF_FILD_ADDR_VAR in which the var name is the same as the struct element name. Then, makes use of DEF_FIELD_ADDR_VAR to create a variable of another name, in order to avoid variable shadowing. Signed-off-by: Leonardo Bras <leobras.c@gmail.com> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
| * modpost: remove leftover symbol prefix handling for module device tableMasahiro Yamada2018-10-191-4/+3
| | | | | | | | | | | | | | | | | | | | | | | | Blackfin and metag were the only architectures that prefix symbols with an underscore. They were removed by commit 4ba66a976072 ("arch: remove blackfin port"), commit bb6fb6dfcc17 ("metag: Remove arch/metag/"), respectively. It is no longer necessary to handle <prefix> part of module device table symbols. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
* | kbuild/Makefile: Prepare for using macros in inline assembly code to work ↵Nadav Amit2018-10-041-0/+2
|/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | around asm() related GCC inlining bugs Using macros in inline assembly allows us to work around bugs in GCC's inlining decisions. Compile macros.S and use it to assemble all C files. Currently only x86 will use it. Background: The inlining pass of GCC doesn't include an assembler, so it's not aware of basic properties of the generated code, such as its size in bytes, or that there are such things as discontiuous blocks of code and data due to the newfangled linker feature called 'sections' ... Instead GCC uses a lazy and fragile heuristic: it does a linear count of certain syntactic and whitespace elements in inlined assembly block source code, such as a count of new-lines and semicolons (!), as a poor substitute for "code size and complexity". Unsurprisingly this heuristic falls over and breaks its neck whith certain common types of kernel code that use inline assembly, such as the frequent practice of putting useful information into alternative sections. As a result of this fresh, 20+ years old GCC bug, GCC's inlining decisions are effectively disabled for inlined functions that make use of such asm() blocks, because GCC thinks those sections of code are "large" - when in reality they are often result in just a very low number of machine instructions. This absolute lack of inlining provess when GCC comes across such asm() blocks both increases generated kernel code size and causes performance overhead, which is particularly noticeable on paravirt kernels, which make frequent use of these inlining facilities in attempt to stay out of the way when running on baremetal hardware. Instead of fixing the compiler we use a workaround: we set an assembly macro and call it from the inlined assembly block. As a result GCC considers the inline assembly block as a single instruction. (Which it often isn't but I digress.) This uglifies and bloats the source code - for example just the refcount related changes have this impact: Makefile | 9 +++++++-- arch/x86/Makefile | 7 +++++++ arch/x86/kernel/macros.S | 7 +++++++ scripts/Kbuild.include | 4 +++- scripts/mod/Makefile | 2 ++ 5 files changed, 26 insertions(+), 3 deletions(-) Yay readability and maintainability, it's not like assembly code is hard to read and maintain ... We also hope that GCC will eventually get fixed, but we are not holding our breath for that. Yet we are optimistic, it might still happen, any decade now. [ mingo: Wrote new changelog describing the background. ] Tested-by: Kees Cook <keescook@chromium.org> Signed-off-by: Nadav Amit <namit@vmware.com> Acked-by: Masahiro Yamada <yamada.masahiro@socionext.com> Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org> Cc: Andy Lutomirski <luto@amacapital.net> Cc: Borislav Petkov <bp@alien8.de> Cc: Brian Gerst <brgerst@gmail.com> Cc: Denys Vlasenko <dvlasenk@redhat.com> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Michal Marek <michal.lkml@markovi.net> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Sam Ravnborg <sam@ravnborg.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: linux-kbuild@vger.kernel.org Link: http://lkml.kernel.org/r/20181003213100.189959-3-namit@vmware.com Signed-off-by: Ingo Molnar <mingo@kernel.org>
* scripts: modpost: check memory allocation resultsRandy Dunlap2018-08-221-4/+4
| | | | | | | | | | | | Fix missing error check for memory allocation functions in scripts/mod/modpost.c. Fixes kernel bugzilla #200319: https://bugzilla.kernel.org/show_bug.cgi?id=200319 Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Cc: Yuexing Wang <wangyxlandq@gmail.com> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
View Lorry Controller Status