Searched +hist:4 +hist:ce6efed (Results 1 - 5 of 5) sorted by relevance
/linux-master/scripts/mod/ | ||
H A D | modpost.h | diff cda5f94e Sat Jan 27 06:28:11 MST 2024 Masahiro Yamada <masahiroy@kernel.org> modpost: avoid using the alias attribute Aiden Leong reported modpost fails to build on macOS since commit 16a473f60edc ("modpost: inform compilers that fatal() never returns"): scripts/mod/modpost.c:93:21: error: aliases are not supported on darwin Nathan's research indicates that Darwin seems to support weak aliases at least [1]. Although the situation might be improved in future Clang versions, we can achieve a similar outcome without relying on it. This commit makes fatal() a macro of error() + exit(1) in modpost.h, as compilers recognize that exit() never returns. [1]: https://github.com/llvm/llvm-project/issues/71001 Fixes: 16a473f60edc ("modpost: inform compilers that fatal() never returns") Reported-by: Aiden Leong <aiden.leong@aibsd.com> Closes: https://lore.kernel.org/all/d9ac2960-6644-4a87-b5e4-4bfb6e0364a8@aibsd.com/ Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> diff cda5f94e Sat Jan 27 06:28:11 MST 2024 Masahiro Yamada <masahiroy@kernel.org> modpost: avoid using the alias attribute Aiden Leong reported modpost fails to build on macOS since commit 16a473f60edc ("modpost: inform compilers that fatal() never returns"): scripts/mod/modpost.c:93:21: error: aliases are not supported on darwin Nathan's research indicates that Darwin seems to support weak aliases at least [1]. Although the situation might be improved in future Clang versions, we can achieve a similar outcome without relying on it. This commit makes fatal() a macro of error() + exit(1) in modpost.h, as compilers recognize that exit() never returns. [1]: https://github.com/llvm/llvm-project/issues/71001 Fixes: 16a473f60edc ("modpost: inform compilers that fatal() never returns") Reported-by: Aiden Leong <aiden.leong@aibsd.com> Closes: https://lore.kernel.org/all/d9ac2960-6644-4a87-b5e4-4bfb6e0364a8@aibsd.com/ Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> diff b2441318 Wed Nov 01 08:07:57 MDT 2017 Greg Kroah-Hartman <gregkh@linuxfoundation.org> License cleanup: add SPDX GPL-2.0 license identifier to files with no license Many source files in the tree are missing licensing information, which makes it harder for compliance tools to determine the correct license. By default all files without license information are under the default license of the kernel, which is GPL version 2. Update the files which contain no license information with the 'GPL-2.0' SPDX license identifier. The SPDX identifier is a legally binding shorthand, which can be used instead of the full boiler plate text. This patch is based on work done by Thomas Gleixner and Kate Stewart and Philippe Ombredanne. How this work was done: Patches were generated and checked against linux-4.14-rc6 for a subset of the use cases: - file had no licensing information it it. - file was a */uapi/* one with no licensing information in it, - file was a */uapi/* one with existing licensing information, Further patches will be generated in subsequent months to fix up cases where non-standard license headers were used, and references to license had to be inferred by heuristics based on keywords. The analysis to determine which SPDX License Identifier to be applied to a file was done in a spreadsheet of side by side results from of the output of two independent scanners (ScanCode & Windriver) producing SPDX tag:value files created by Philippe Ombredanne. Philippe prepared the base worksheet, and did an initial spot review of a few 1000 files. The 4.13 kernel was the starting point of the analysis with 60,537 files assessed. Kate Stewart did a file by file comparison of the scanner results in the spreadsheet to determine which SPDX license identifier(s) to be applied to the file. She confirmed any determination that was not immediately clear with lawyers working with the Linux Foundation. Criteria used to select files for SPDX license identifier tagging was: - Files considered eligible had to be source code files. - Make and config files were included as candidates if they contained >5 lines of source - File already had some variant of a license header in it (even if <5 lines). All documentation files were explicitly excluded. The following heuristics were used to determine which SPDX license identifiers to apply. - when both scanners couldn't find any license traces, file was considered to have no license information in it, and the top level COPYING file license applied. For non */uapi/* files that summary was: SPDX license identifier # files ---------------------------------------------------|------- GPL-2.0 11139 and resulted in the first patch in this series. If that file was a */uapi/* path one, it was "GPL-2.0 WITH Linux-syscall-note" otherwise it was "GPL-2.0". Results of that was: SPDX license identifier # files ---------------------------------------------------|------- GPL-2.0 WITH Linux-syscall-note 930 and resulted in the second patch in this series. - if a file had some form of licensing information in it, and was one of the */uapi/* ones, it was denoted with the Linux-syscall-note if any GPL family license was found in the file or had no licensing in it (per prior point). Results summary: SPDX license identifier # files ---------------------------------------------------|------ GPL-2.0 WITH Linux-syscall-note 270 GPL-2.0+ WITH Linux-syscall-note 169 ((GPL-2.0 WITH Linux-syscall-note) OR BSD-2-Clause) 21 ((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause) 17 LGPL-2.1+ WITH Linux-syscall-note 15 GPL-1.0+ WITH Linux-syscall-note 14 ((GPL-2.0+ WITH Linux-syscall-note) OR BSD-3-Clause) 5 LGPL-2.0+ WITH Linux-syscall-note 4 LGPL-2.1 WITH Linux-syscall-note 3 ((GPL-2.0 WITH Linux-syscall-note) OR MIT) 3 ((GPL-2.0 WITH Linux-syscall-note) AND MIT) 1 and that resulted in the third patch in this series. - when the two scanners agreed on the detected license(s), that became the concluded license(s). - when there was disagreement between the two scanners (one detected a license but the other didn't, or they both detected different licenses) a manual inspection of the file occurred. - In most cases a manual inspection of the information in the file resulted in a clear resolution of the license that should apply (and which scanner probably needed to revisit its heuristics). - When it was not immediately clear, the license identifier was confirmed with lawyers working with the Linux Foundation. - If there was any question as to the appropriate license identifier, the file was flagged for further research and to be revisited later in time. In total, over 70 hours of logged manual review was done on the spreadsheet to determine the SPDX license identifiers to apply to the source files by Kate, Philippe, Thomas and, in some cases, confirmation by lawyers working with the Linux Foundation. Kate also obtained a third independent scan of the 4.13 code base from FOSSology, and compared selected files where the other two scanners disagreed against that SPDX file, to see if there was new insights. The Windriver scanner is based on an older version of FOSSology in part, so they are related. Thomas did random spot checks in about 500 files from the spreadsheets for the uapi headers and agreed with SPDX license identifier in the files he inspected. For the non-uapi files Thomas did random spot checks in about 15000 files. In initial set of patches against 4.14-rc6, 3 files were found to have copy/paste license identifier errors, and have been fixed to reflect the correct identifier. Additionally Philippe spent 10 hours this week doing a detailed manual inspection and review of the 12,461 patched files from the initial patch version early this week with: - a full scancode scan run, collecting the matched texts, detected license ids and scores - reviewing anything where there was a license detected (about 500+ files) to ensure that the applied SPDX license was correct - reviewing anything where there was no detection but the patch license was not GPL-2.0 WITH Linux-syscall-note to ensure that the applied SPDX license was correct This produced a worksheet with 20 files needing minor correction. This worksheet was then exported into 3 different .csv files for the different types of files to be modified. These .csv files were then reviewed by Greg. Thomas wrote a script to parse the csv files and add the proper SPDX tag to the file, in the format that the file expected. This script was further refined by Greg based on the output to detect more types of files automatically and to distinguish between header and source .c files (which need different comment types.) Finally Greg ran the script using the .csv files to generate the patches. Reviewed-by: Kate Stewart <kstewart@linuxfoundation.org> Reviewed-by: Philippe Ombredanne <pombredanne@nexb.com> Reviewed-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> diff 4ce6efed Sun Mar 23 14:38:54 MDT 2008 Sam Ravnborg <sam@uranus.ravnborg.org> kbuild: soften modpost checks when doing cross builds The module alias support in the kernel have a consistency check where it is checked that the size of a structure in the kernel and on the build host are the same. For cross builds this check does not make sense so detect when we do cross builds and silently skip the check in these situations. This fixes a build bug for a wireless driver when cross building for arm. Acked-by: Michael Buesch <mb@bu3sch.de> Tested-by: Gordon Farquharson <gordonfarquharson@gmail.com> Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Cc: stable@kernel.org diff 4ce6efed Sun Mar 23 14:38:54 MDT 2008 Sam Ravnborg <sam@uranus.ravnborg.org> kbuild: soften modpost checks when doing cross builds The module alias support in the kernel have a consistency check where it is checked that the size of a structure in the kernel and on the build host are the same. For cross builds this check does not make sense so detect when we do cross builds and silently skip the check in these situations. This fixes a build bug for a wireless driver when cross building for arm. Acked-by: Michael Buesch <mb@bu3sch.de> Tested-by: Gordon Farquharson <gordonfarquharson@gmail.com> Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Cc: stable@kernel.org diff 4f4c4ee1 Sun Aug 12 15:17:54 MDT 2007 Sam Ravnborg <sam@ravnborg.org> kbuild: Use Elfnn_Half as replacement for Elfnn_Section The Elfnn_Section is not available on all platforms, noteworthy are cygwin. Use the safe replacement _Half. Signed-off-by: Sam Ravnborg <sam@ravnborg.org> |
H A D | file2alias.c | diff ac96a15a Sat Oct 07 11:04:45 MDT 2023 Masahiro Yamada <masahiroy@kernel.org> modpost: fix ishtp MODULE_DEVICE_TABLE built on big-endian host When MODULE_DEVICE_TABLE(ishtp, ) is built on a host with a different endianness from the target architecture, it results in an incorrect MODULE_ALIAS(). For example, see a case where drivers/platform/x86/intel/ishtp_eclite.c is built as a module for x86. If you build it on a little-endian host, you will get the correct MODULE_ALIAS: $ grep MODULE_ALIAS drivers/platform/x86/intel/ishtp_eclite.mod.c MODULE_ALIAS("ishtp:{6A19CC4B-D760-4DE3-B14D-F25EBD0FBCD9}"); However, if you build it on a big-endian host, you will get a wrong MODULE_ALIAS: $ grep MODULE_ALIAS drivers/platform/x86/intel/ishtp_eclite.mod.c MODULE_ALIAS("ishtp:{BD0FBCD9-F25E-B14D-4DE3-D7606A19CC4B}"); This issue has been unnoticed because the x86 kernel is most likely built natively on an x86 host. The guid field must not be reversed because guid_t is an array of __u8. Fixes: fa443bc3c1e4 ("HID: intel-ish-hid: add support for MODULE_DEVICE_TABLE()") Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Reviewed-by: Thomas Weißschuh <linux@weissschuh.net> Tested-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> diff ac96a15a Sat Oct 07 11:04:45 MDT 2023 Masahiro Yamada <masahiroy@kernel.org> modpost: fix ishtp MODULE_DEVICE_TABLE built on big-endian host When MODULE_DEVICE_TABLE(ishtp, ) is built on a host with a different endianness from the target architecture, it results in an incorrect MODULE_ALIAS(). For example, see a case where drivers/platform/x86/intel/ishtp_eclite.c is built as a module for x86. If you build it on a little-endian host, you will get the correct MODULE_ALIAS: $ grep MODULE_ALIAS drivers/platform/x86/intel/ishtp_eclite.mod.c MODULE_ALIAS("ishtp:{6A19CC4B-D760-4DE3-B14D-F25EBD0FBCD9}"); However, if you build it on a big-endian host, you will get a wrong MODULE_ALIAS: $ grep MODULE_ALIAS drivers/platform/x86/intel/ishtp_eclite.mod.c MODULE_ALIAS("ishtp:{BD0FBCD9-F25E-B14D-4DE3-D7606A19CC4B}"); This issue has been unnoticed because the x86 kernel is most likely built natively on an x86 host. The guid field must not be reversed because guid_t is an array of __u8. Fixes: fa443bc3c1e4 ("HID: intel-ish-hid: add support for MODULE_DEVICE_TABLE()") Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Reviewed-by: Thomas Weißschuh <linux@weissschuh.net> Tested-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> diff 7f54e00e Sat Oct 07 11:04:44 MDT 2023 Masahiro Yamada <masahiroy@kernel.org> modpost: fix tee MODULE_DEVICE_TABLE built on big-endian host When MODULE_DEVICE_TABLE(tee, ) is built on a host with a different endianness from the target architecture, it results in an incorrect MODULE_ALIAS(). For example, see a case where drivers/char/hw_random/optee-rng.c is built as a module for ARM little-endian. If you build it on a little-endian host, you will get the correct MODULE_ALIAS: $ grep MODULE_ALIAS drivers/char/hw_random/optee-rng.mod.c MODULE_ALIAS("tee:ab7a617c-b8e7-4d8f-8301-d09b61036b64*"); However, if you build it on a big-endian host, you will get a wrong MODULE_ALIAS: $ grep MODULE_ALIAS drivers/char/hw_random/optee-rng.mod.c MODULE_ALIAS("tee:646b0361-9bd0-0183-8f4d-e7b87c617aab*"); The same problem also occurs when you enable CONFIG_CPU_BIG_ENDIAN, and build it on a little-endian host. This issue has been unnoticed because the ARM kernel is configured for little-endian by default, and most likely built on a little-endian host (cross-build on x86 or native-build on ARM). The uuid field must not be reversed because uuid_t is an array of __u8. Fixes: 0fc1db9d1059 ("tee: add bus driver framework for TEE based devices") Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Reviewed-by: Sumit Garg <sumit.garg@linaro.org> diff cc6711b0 Thu Aug 26 04:39:09 MDT 2021 Max Gurtovoy <mgurtovoy@nvidia.com> PCI / VFIO: Add 'override_only' support for VFIO PCI sub system Expose an 'override_only' helper macro (i.e. PCI_DRIVER_OVERRIDE_DEVICE_VFIO) for VFIO PCI sub system and add the required code to prefix its matching entries with "vfio_" in modules.alias file. It allows VFIO device drivers to include match entries in the modules.alias file produced by kbuild that are not used for normal driver autoprobing and module autoloading. Drivers using these match entries can be connected to the PCI device manually, by userspace, using the existing driver_override sysfs. For example the resulting modules.alias may have: alias pci:v000015B3d00001021sv*sd*bc*sc*i* mlx5_core alias vfio_pci:v000015B3d00001021sv*sd*bc*sc*i* mlx5_vfio_pci alias vfio_pci:v*d*sv*sd*bc*sc*i* vfio_pci In this example mlx5_core and mlx5_vfio_pci match to the same PCI device. The kernel will autoload and autobind to mlx5_core but the kernel and udev mechanisms will ignore mlx5_vfio_pci. When userspace wants to change a device to the VFIO subsystem it can implement a generic algorithm: 1) Identify the sysfs path to the device: /sys/devices/pci0000:00/0000:00:01.0/0000:01:00.0 2) Get the modalias string from the kernel: $ cat /sys/bus/pci/devices/0000:01:00.0/modalias pci:v000015B3d00001021sv000015B3sd00000001bc02sc00i00 3) Prefix it with vfio_: vfio_pci:v000015B3d00001021sv000015B3sd00000001bc02sc00i00 4) Search modules.alias for the above string and select the entry that has the fewest *'s: alias vfio_pci:v000015B3d00001021sv*sd*bc*sc*i* mlx5_vfio_pci 5) modprobe the matched module name: $ modprobe mlx5_vfio_pci 6) cat the matched module name to driver_override: echo mlx5_vfio_pci > /sys/bus/pci/devices/0000:01:00.0/driver_override 7) unbind device from original module echo 0000:01:00.0 > /sys/bus/pci/devices/0000:01:00.0/driver/unbind 8) probe PCI drivers (or explicitly bind to mlx5_vfio_pci) echo 0000:01:00.0 > /sys/bus/pci/drivers_probe The algorithm is independent of bus type. In future the other buses with VFIO device drivers, like platform and ACPI, can use this algorithm as well. This patch is the infrastructure to provide the information in the modules.alias to userspace. Convert the only VFIO pci_driver which results in one new line in the modules.alias: alias vfio_pci:v*d*sv*sd*bc*sc*i* vfio_pci Later series introduce additional HW specific VFIO PCI drivers, such as mlx5_vfio_pci. Signed-off-by: Max Gurtovoy <mgurtovoy@nvidia.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com> Acked-by: Bjorn Helgaas <bhelgaas@google.com> # for pci.h Signed-off-by: Yishai Hadas <yishaih@nvidia.com> Link: https://lore.kernel.org/r/20210826103912.128972-11-yishaih@nvidia.com Signed-off-by: Alex Williamson <alex.williamson@redhat.com> diff 4a224ace Wed Jan 06 21:37:11 MST 2021 Xu Yilun <yilun.xu@intel.com> fpga: dfl: add dfl bus support to MODULE_DEVICE_TABLE() Device Feature List (DFL) is a linked list of feature headers within the device MMIO space. It is used by FPGA to enumerate multiple sub features within it. Each feature can be uniquely identified by DFL type and feature id, which can be read out from feature headers. A dfl bus helps DFL framework modularize DFL device drivers for different sub features. The dfl bus matches its devices and drivers by DFL type and feature id. This patch adds dfl bus support to MODULE_DEVICE_TABLE() by adding info about struct dfl_device_id in devicetable-offsets.c and add a dfl entry point in file2alias.c. Acked-by: Wu Hao <hao.wu@intel.com> Signed-off-by: Xu Yilun <yilun.xu@intel.com> Signed-off-by: Wu Hao <hao.wu@intel.com> Signed-off-by: Matthew Gerlach <matthew.gerlach@linux.intel.com> Signed-off-by: Russ Weight <russell.h.weight@intel.com> Signed-off-by: Moritz Fischer <mdf@kernel.org> Link: https://lore.kernel.org/r/20210107043714.991646-6-mdf@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> diff b5924268 Mon Jun 08 14:54:35 MDT 2020 Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> soundwire: extend SDW_SLAVE_ENTRY The SoundWire 1.2 specification adds new capabilities that were not present in previous version, such as the class ID. To enable support for class drivers, and well as drivers that address a specific version, all fields of the sdw_device_id structure need to be exposed. For SoundWire 1.0 and 1.1 devices, a wildcard is used so class and version information are ignored. Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Rander Wang <rander.wang@linux.intel.com> Reviewed-by: Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com> Signed-off-by: Bard Liao <yung-chuan.liao@linux.intel.com> Link: https://lore.kernel.org/r/20200608205436.2402-4-yung-chuan.liao@linux.intel.com Signed-off-by: Vinod Koul <vkoul@kernel.org> diff 153e04b3 Fri Sep 28 00:21:55 MDT 2018 Masahiro Yamada <yamada.masahiro@socionext.com> modpost: remove leftover symbol prefix handling for module device table 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> diff 4d53b801 Sun Apr 22 16:07:02 MDT 2012 Henrik Rydberg <rydberg@euromail.se> HID: Add device group to modalias HID devices are only partially presented to userland. Hotplugged devices emit events containing a modalias based on the basic bus, vendor and product entities. However, in practise a hid device can depend on details such as a single usb interface or a particular item in a report descriptor. This patch adds a device group to the hid device id, and broadcasts it using uevent and the device modalias. The module alias generation is modified to match. As a consequence, a device with a non-zero group will be processed by the corresponding group driver instead of by the generic hid driver. Signed-off-by: Henrik Rydberg <rydberg@euromail.se> Acked-by: Benjamin Tissoires <benjamin.tissoires@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz> diff 4ce6efed Sun Mar 23 14:38:54 MDT 2008 Sam Ravnborg <sam@uranus.ravnborg.org> kbuild: soften modpost checks when doing cross builds The module alias support in the kernel have a consistency check where it is checked that the size of a structure in the kernel and on the build host are the same. For cross builds this check does not make sense so detect when we do cross builds and silently skip the check in these situations. This fixes a build bug for a wireless driver when cross building for arm. Acked-by: Michael Buesch <mb@bu3sch.de> Tested-by: Gordon Farquharson <gordonfarquharson@gmail.com> Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Cc: stable@kernel.org diff 4ce6efed Sun Mar 23 14:38:54 MDT 2008 Sam Ravnborg <sam@uranus.ravnborg.org> kbuild: soften modpost checks when doing cross builds The module alias support in the kernel have a consistency check where it is checked that the size of a structure in the kernel and on the build host are the same. For cross builds this check does not make sense so detect when we do cross builds and silently skip the check in these situations. This fixes a build bug for a wireless driver when cross building for arm. Acked-by: Michael Buesch <mb@bu3sch.de> Tested-by: Gordon Farquharson <gordonfarquharson@gmail.com> Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Cc: stable@kernel.org |
H A D | modpost.c | diff cda5f94e Sat Jan 27 06:28:11 MST 2024 Masahiro Yamada <masahiroy@kernel.org> modpost: avoid using the alias attribute Aiden Leong reported modpost fails to build on macOS since commit 16a473f60edc ("modpost: inform compilers that fatal() never returns"): scripts/mod/modpost.c:93:21: error: aliases are not supported on darwin Nathan's research indicates that Darwin seems to support weak aliases at least [1]. Although the situation might be improved in future Clang versions, we can achieve a similar outcome without relying on it. This commit makes fatal() a macro of error() + exit(1) in modpost.h, as compilers recognize that exit() never returns. [1]: https://github.com/llvm/llvm-project/issues/71001 Fixes: 16a473f60edc ("modpost: inform compilers that fatal() never returns") Reported-by: Aiden Leong <aiden.leong@aibsd.com> Closes: https://lore.kernel.org/all/d9ac2960-6644-4a87-b5e4-4bfb6e0364a8@aibsd.com/ Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> diff cda5f94e Sat Jan 27 06:28:11 MST 2024 Masahiro Yamada <masahiroy@kernel.org> modpost: avoid using the alias attribute Aiden Leong reported modpost fails to build on macOS since commit 16a473f60edc ("modpost: inform compilers that fatal() never returns"): scripts/mod/modpost.c:93:21: error: aliases are not supported on darwin Nathan's research indicates that Darwin seems to support weak aliases at least [1]. Although the situation might be improved in future Clang versions, we can achieve a similar outcome without relying on it. This commit makes fatal() a macro of error() + exit(1) in modpost.h, as compilers recognize that exit() never returns. [1]: https://github.com/llvm/llvm-project/issues/71001 Fixes: 16a473f60edc ("modpost: inform compilers that fatal() never returns") Reported-by: Aiden Leong <aiden.leong@aibsd.com> Closes: https://lore.kernel.org/all/d9ac2960-6644-4a87-b5e4-4bfb6e0364a8@aibsd.com/ Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> diff 39758650 Tue Jan 23 15:59:55 MST 2024 Nathan Chancellor <nathan@kernel.org> modpost: Add '.ltext' and '.ltext.*' to TEXT_SECTIONS After the linked LLVM change, building ARCH=um defconfig results in a segmentation fault in modpost. Prior to commit a23e7584ecf3 ("modpost: unify 'sym' and 'to' in default_mismatch_handler()"), there was a warning: WARNING: modpost: vmlinux.o(__ex_table+0x88): Section mismatch in reference to the .ltext:(unknown) WARNING: modpost: The relocation at __ex_table+0x88 references section ".ltext" which is not in the list of authorized sections. If you're adding a new section and/or if this reference is valid, add ".ltext" to the list of authorized sections to jump to on fault. This can be achieved by adding ".ltext" to OTHER_TEXT_SECTIONS in scripts/mod/modpost.c. The linked LLVM change moves global objects to the '.ltext' (and '.ltext.*' with '-ffunction-sections') sections with '-mcmodel=large', which ARCH=um uses. These sections should be handled just as '.text' and '.text.*' are, so add them to TEXT_SECTIONS. Cc: stable@vger.kernel.org Closes: https://github.com/ClangBuiltLinux/linux/issues/1981 Link: https://github.com/llvm/llvm-project/commit/4bf8a688956a759b7b6b8d94f42d25c13c7af130 Signed-off-by: Nathan Chancellor <nathan@kernel.org> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> diff c05780ef Fri Jul 07 10:00:51 MDT 2023 Palmer Dabbelt <palmer@rivosinc.com> module: Ignore RISC-V mapping symbols too RISC-V has an extended form of mapping symbols that we use to encode the ISA when it changes in the middle of an ELF. This trips up modpost as a build failure, I haven't yet verified it yet but I believe the kallsyms difference should result in stacks looking sane again. Reported-by: Randy Dunlap <rdunlap@infradead.org> Closes: https://lore.kernel.org/all/9d9e2902-5489-4bf0-d9cb-556c8e5d71c2@infradead.org/ Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com> Reviewed-by: Randy Dunlap <rdunlap@infradead.org> Tested-by: Randy Dunlap <rdunlap@infradead.org> # build-tested Signed-off-by: Luis Chamberlain <mcgrof@kernel.org> diff 3310bae8 Thu Jun 01 06:10:00 MDT 2023 Masahiro Yamada <masahiroy@kernel.org> modpost: fix section_mismatch message for R_ARM_THM_{CALL,JUMP24,JUMP19} addend_arm_rel() processes R_ARM_THM_CALL, R_ARM_THM_JUMP24, R_ARM_THM_JUMP19 in a wrong way. Here, test code. [test code for R_ARM_THM_JUMP24] .section .init.text,"ax" bar: bx lr .section .text,"ax" .globl foo foo: b bar [test code for R_ARM_THM_CALL] .section .init.text,"ax" bar: bx lr .section .text,"ax" .globl foo foo: push {lr} bl bar pop {pc} If you compile it with CONFIG_THUMB2_KERNEL=y, modpost will show the symbol name, (unknown). WARNING: modpost: vmlinux.o: section mismatch in reference: foo (section: .text) -> (unknown) (section: .init.text) (You need to use GNU linker instead of LLD to reproduce it.) Fix the code to make modpost show the correct symbol name. I checked arch/arm/kernel/module.c to learn the encoding of R_ARM_THM_CALL and R_ARM_THM_JUMP24. The module does not support R_ARM_THM_JUMP19, but I checked its encoding in ARM ARM. The '+4' is the compensation for pc-relative instruction. It is documented in "ELF for the Arm Architecture" [1]. "If the relocation is pc-relative then compensation for the PC bias (the PC value is 8 bytes ahead of the executing instruction in Arm state and 4 bytes in Thumb state) must be encoded in the relocation by the object producer." [1]: https://github.com/ARM-software/abi-aa/blob/main/aaelf32/aaelf32.rst Fixes: c9698e5cd6ad ("ARM: 7964/1: Detect section mismatches in thumb relocations") Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> diff 3310bae8 Thu Jun 01 06:10:00 MDT 2023 Masahiro Yamada <masahiroy@kernel.org> modpost: fix section_mismatch message for R_ARM_THM_{CALL,JUMP24,JUMP19} addend_arm_rel() processes R_ARM_THM_CALL, R_ARM_THM_JUMP24, R_ARM_THM_JUMP19 in a wrong way. Here, test code. [test code for R_ARM_THM_JUMP24] .section .init.text,"ax" bar: bx lr .section .text,"ax" .globl foo foo: b bar [test code for R_ARM_THM_CALL] .section .init.text,"ax" bar: bx lr .section .text,"ax" .globl foo foo: push {lr} bl bar pop {pc} If you compile it with CONFIG_THUMB2_KERNEL=y, modpost will show the symbol name, (unknown). WARNING: modpost: vmlinux.o: section mismatch in reference: foo (section: .text) -> (unknown) (section: .init.text) (You need to use GNU linker instead of LLD to reproduce it.) Fix the code to make modpost show the correct symbol name. I checked arch/arm/kernel/module.c to learn the encoding of R_ARM_THM_CALL and R_ARM_THM_JUMP24. The module does not support R_ARM_THM_JUMP19, but I checked its encoding in ARM ARM. The '+4' is the compensation for pc-relative instruction. It is documented in "ELF for the Arm Architecture" [1]. "If the relocation is pc-relative then compensation for the PC bias (the PC value is 8 bytes ahead of the executing instruction in Arm state and 4 bytes in Thumb state) must be encoded in the relocation by the object producer." [1]: https://github.com/ARM-software/abi-aa/blob/main/aaelf32/aaelf32.rst Fixes: c9698e5cd6ad ("ARM: 7964/1: Detect section mismatches in thumb relocations") Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> diff 56a24b8c Thu Jun 01 06:09:56 MDT 2023 Masahiro Yamada <masahiroy@kernel.org> modpost: fix section mismatch message for R_ARM_{PC24,CALL,JUMP24} addend_arm_rel() processes R_ARM_PC24, R_ARM_CALL, R_ARM_JUMP24 in a wrong way. Here, test code. [test code for R_ARM_JUMP24] .section .init.text,"ax" bar: bx lr .section .text,"ax" .globl foo foo: b bar [test code for R_ARM_CALL] .section .init.text,"ax" bar: bx lr .section .text,"ax" .globl foo foo: push {lr} bl bar pop {pc} If you compile it with ARM multi_v7_defconfig, modpost will show the symbol name, (unknown). WARNING: modpost: vmlinux.o: section mismatch in reference: foo (section: .text) -> (unknown) (section: .init.text) (You need to use GNU linker instead of LLD to reproduce it.) Fix the code to make modpost show the correct symbol name. I imported (with adjustment) sign_extend32() from include/linux/bitops.h. The '+8' is the compensation for pc-relative instruction. It is documented in "ELF for the Arm Architecture" [1]. "If the relocation is pc-relative then compensation for the PC bias (the PC value is 8 bytes ahead of the executing instruction in Arm state and 4 bytes in Thumb state) must be encoded in the relocation by the object producer." [1]: https://github.com/ARM-software/abi-aa/blob/main/aaelf32/aaelf32.rst Fixes: 56a974fa2d59 ("kbuild: make better section mismatch reports on arm") Fixes: 6e2e340b59d2 ("ARM: 7324/1: modpost: Fix section warnings for ARM for many compilers") Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> diff b7c63520 Thu Jun 01 06:09:55 MDT 2023 Masahiro Yamada <masahiroy@kernel.org> modpost: fix section mismatch message for R_ARM_ABS32 addend_arm_rel() processes R_ARM_ABS32 in a wrong way. Here, test code. [test code 1] #include <linux/init.h> int __initdata foo; int get_foo(void) { return foo; } If you compile it with ARM versatile_defconfig, modpost will show the symbol name, (unknown). WARNING: modpost: vmlinux.o: section mismatch in reference: get_foo (section: .text) -> (unknown) (section: .init.data) (You need to use GNU linker instead of LLD to reproduce it.) If you compile it for other architectures, modpost will show the correct symbol name. WARNING: modpost: vmlinux.o: section mismatch in reference: get_foo (section: .text) -> foo (section: .init.data) For R_ARM_ABS32, addend_arm_rel() sets r->r_addend to a wrong value. I just mimicked the code in arch/arm/kernel/module.c. However, there is more difficulty for ARM. Here, test code. [test code 2] #include <linux/init.h> int __initdata foo; int get_foo(void) { return foo; } int __initdata bar; int get_bar(void) { return bar; } With this commit applied, modpost will show the following messages for ARM versatile_defconfig: WARNING: modpost: vmlinux.o: section mismatch in reference: get_foo (section: .text) -> foo (section: .init.data) WARNING: modpost: vmlinux.o: section mismatch in reference: get_bar (section: .text) -> foo (section: .init.data) The reference from 'get_bar' to 'foo' seems wrong. I have no solution for this because it is true in assembly level. In the following output, relocation at 0x1c is no longer associated with 'bar'. The two relocation entries point to the same symbol, and the offset to 'bar' is encoded in the instruction 'r0, [r3, #4]'. Disassembly of section .text: 00000000 <get_foo>: 0: e59f3004 ldr r3, [pc, #4] @ c <get_foo+0xc> 4: e5930000 ldr r0, [r3] 8: e12fff1e bx lr c: 00000000 .word 0x00000000 00000010 <get_bar>: 10: e59f3004 ldr r3, [pc, #4] @ 1c <get_bar+0xc> 14: e5930004 ldr r0, [r3, #4] 18: e12fff1e bx lr 1c: 00000000 .word 0x00000000 Relocation section '.rel.text' at offset 0x244 contains 2 entries: Offset Info Type Sym.Value Sym. Name 0000000c 00000c02 R_ARM_ABS32 00000000 .init.data 0000001c 00000c02 R_ARM_ABS32 00000000 .init.data When find_elf_symbol() gets into a situation where relsym->st_name is zero, there is no guarantee to get the symbol name as written in C. I am keeping the current logic because it is useful in many architectures, but the symbol name is not always correct depending on the optimization. I left some comments in find_tosym(). Fixes: 56a974fa2d59 ("kbuild: make better section mismatch reports on arm") Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> diff b7c63520 Thu Jun 01 06:09:55 MDT 2023 Masahiro Yamada <masahiroy@kernel.org> modpost: fix section mismatch message for R_ARM_ABS32 addend_arm_rel() processes R_ARM_ABS32 in a wrong way. Here, test code. [test code 1] #include <linux/init.h> int __initdata foo; int get_foo(void) { return foo; } If you compile it with ARM versatile_defconfig, modpost will show the symbol name, (unknown). WARNING: modpost: vmlinux.o: section mismatch in reference: get_foo (section: .text) -> (unknown) (section: .init.data) (You need to use GNU linker instead of LLD to reproduce it.) If you compile it for other architectures, modpost will show the correct symbol name. WARNING: modpost: vmlinux.o: section mismatch in reference: get_foo (section: .text) -> foo (section: .init.data) For R_ARM_ABS32, addend_arm_rel() sets r->r_addend to a wrong value. I just mimicked the code in arch/arm/kernel/module.c. However, there is more difficulty for ARM. Here, test code. [test code 2] #include <linux/init.h> int __initdata foo; int get_foo(void) { return foo; } int __initdata bar; int get_bar(void) { return bar; } With this commit applied, modpost will show the following messages for ARM versatile_defconfig: WARNING: modpost: vmlinux.o: section mismatch in reference: get_foo (section: .text) -> foo (section: .init.data) WARNING: modpost: vmlinux.o: section mismatch in reference: get_bar (section: .text) -> foo (section: .init.data) The reference from 'get_bar' to 'foo' seems wrong. I have no solution for this because it is true in assembly level. In the following output, relocation at 0x1c is no longer associated with 'bar'. The two relocation entries point to the same symbol, and the offset to 'bar' is encoded in the instruction 'r0, [r3, #4]'. Disassembly of section .text: 00000000 <get_foo>: 0: e59f3004 ldr r3, [pc, #4] @ c <get_foo+0xc> 4: e5930000 ldr r0, [r3] 8: e12fff1e bx lr c: 00000000 .word 0x00000000 00000010 <get_bar>: 10: e59f3004 ldr r3, [pc, #4] @ 1c <get_bar+0xc> 14: e5930004 ldr r0, [r3, #4] 18: e12fff1e bx lr 1c: 00000000 .word 0x00000000 Relocation section '.rel.text' at offset 0x244 contains 2 entries: Offset Info Type Sym.Value Sym. Name 0000000c 00000c02 R_ARM_ABS32 00000000 .init.data 0000001c 00000c02 R_ARM_ABS32 00000000 .init.data When find_elf_symbol() gets into a situation where relsym->st_name is zero, there is no guarantee to get the symbol name as written in C. I am keeping the current logic because it is useful in many architectures, but the symbol name is not always correct depending on the optimization. I left some comments in find_tosym(). Fixes: 56a974fa2d59 ("kbuild: make better section mismatch reports on arm") Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> diff b7c63520 Thu Jun 01 06:09:55 MDT 2023 Masahiro Yamada <masahiroy@kernel.org> modpost: fix section mismatch message for R_ARM_ABS32 addend_arm_rel() processes R_ARM_ABS32 in a wrong way. Here, test code. [test code 1] #include <linux/init.h> int __initdata foo; int get_foo(void) { return foo; } If you compile it with ARM versatile_defconfig, modpost will show the symbol name, (unknown). WARNING: modpost: vmlinux.o: section mismatch in reference: get_foo (section: .text) -> (unknown) (section: .init.data) (You need to use GNU linker instead of LLD to reproduce it.) If you compile it for other architectures, modpost will show the correct symbol name. WARNING: modpost: vmlinux.o: section mismatch in reference: get_foo (section: .text) -> foo (section: .init.data) For R_ARM_ABS32, addend_arm_rel() sets r->r_addend to a wrong value. I just mimicked the code in arch/arm/kernel/module.c. However, there is more difficulty for ARM. Here, test code. [test code 2] #include <linux/init.h> int __initdata foo; int get_foo(void) { return foo; } int __initdata bar; int get_bar(void) { return bar; } With this commit applied, modpost will show the following messages for ARM versatile_defconfig: WARNING: modpost: vmlinux.o: section mismatch in reference: get_foo (section: .text) -> foo (section: .init.data) WARNING: modpost: vmlinux.o: section mismatch in reference: get_bar (section: .text) -> foo (section: .init.data) The reference from 'get_bar' to 'foo' seems wrong. I have no solution for this because it is true in assembly level. In the following output, relocation at 0x1c is no longer associated with 'bar'. The two relocation entries point to the same symbol, and the offset to 'bar' is encoded in the instruction 'r0, [r3, #4]'. Disassembly of section .text: 00000000 <get_foo>: 0: e59f3004 ldr r3, [pc, #4] @ c <get_foo+0xc> 4: e5930000 ldr r0, [r3] 8: e12fff1e bx lr c: 00000000 .word 0x00000000 00000010 <get_bar>: 10: e59f3004 ldr r3, [pc, #4] @ 1c <get_bar+0xc> 14: e5930004 ldr r0, [r3, #4] 18: e12fff1e bx lr 1c: 00000000 .word 0x00000000 Relocation section '.rel.text' at offset 0x244 contains 2 entries: Offset Info Type Sym.Value Sym. Name 0000000c 00000c02 R_ARM_ABS32 00000000 .init.data 0000001c 00000c02 R_ARM_ABS32 00000000 .init.data When find_elf_symbol() gets into a situation where relsym->st_name is zero, there is no guarantee to get the symbol name as written in C. I am keeping the current logic because it is useful in many architectures, but the symbol name is not always correct depending on the optimization. I left some comments in find_tosym(). Fixes: 56a974fa2d59 ("kbuild: make better section mismatch reports on arm") Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> diff b7c63520 Thu Jun 01 06:09:55 MDT 2023 Masahiro Yamada <masahiroy@kernel.org> modpost: fix section mismatch message for R_ARM_ABS32 addend_arm_rel() processes R_ARM_ABS32 in a wrong way. Here, test code. [test code 1] #include <linux/init.h> int __initdata foo; int get_foo(void) { return foo; } If you compile it with ARM versatile_defconfig, modpost will show the symbol name, (unknown). WARNING: modpost: vmlinux.o: section mismatch in reference: get_foo (section: .text) -> (unknown) (section: .init.data) (You need to use GNU linker instead of LLD to reproduce it.) If you compile it for other architectures, modpost will show the correct symbol name. WARNING: modpost: vmlinux.o: section mismatch in reference: get_foo (section: .text) -> foo (section: .init.data) For R_ARM_ABS32, addend_arm_rel() sets r->r_addend to a wrong value. I just mimicked the code in arch/arm/kernel/module.c. However, there is more difficulty for ARM. Here, test code. [test code 2] #include <linux/init.h> int __initdata foo; int get_foo(void) { return foo; } int __initdata bar; int get_bar(void) { return bar; } With this commit applied, modpost will show the following messages for ARM versatile_defconfig: WARNING: modpost: vmlinux.o: section mismatch in reference: get_foo (section: .text) -> foo (section: .init.data) WARNING: modpost: vmlinux.o: section mismatch in reference: get_bar (section: .text) -> foo (section: .init.data) The reference from 'get_bar' to 'foo' seems wrong. I have no solution for this because it is true in assembly level. In the following output, relocation at 0x1c is no longer associated with 'bar'. The two relocation entries point to the same symbol, and the offset to 'bar' is encoded in the instruction 'r0, [r3, #4]'. Disassembly of section .text: 00000000 <get_foo>: 0: e59f3004 ldr r3, [pc, #4] @ c <get_foo+0xc> 4: e5930000 ldr r0, [r3] 8: e12fff1e bx lr c: 00000000 .word 0x00000000 00000010 <get_bar>: 10: e59f3004 ldr r3, [pc, #4] @ 1c <get_bar+0xc> 14: e5930004 ldr r0, [r3, #4] 18: e12fff1e bx lr 1c: 00000000 .word 0x00000000 Relocation section '.rel.text' at offset 0x244 contains 2 entries: Offset Info Type Sym.Value Sym. Name 0000000c 00000c02 R_ARM_ABS32 00000000 .init.data 0000001c 00000c02 R_ARM_ABS32 00000000 .init.data When find_elf_symbol() gets into a situation where relsym->st_name is zero, there is no guarantee to get the symbol name as written in C. I am keeping the current logic because it is useful in many architectures, but the symbol name is not always correct depending on the optimization. I left some comments in find_tosym(). Fixes: 56a974fa2d59 ("kbuild: make better section mismatch reports on arm") Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> diff b7c63520 Thu Jun 01 06:09:55 MDT 2023 Masahiro Yamada <masahiroy@kernel.org> modpost: fix section mismatch message for R_ARM_ABS32 addend_arm_rel() processes R_ARM_ABS32 in a wrong way. Here, test code. [test code 1] #include <linux/init.h> int __initdata foo; int get_foo(void) { return foo; } If you compile it with ARM versatile_defconfig, modpost will show the symbol name, (unknown). WARNING: modpost: vmlinux.o: section mismatch in reference: get_foo (section: .text) -> (unknown) (section: .init.data) (You need to use GNU linker instead of LLD to reproduce it.) If you compile it for other architectures, modpost will show the correct symbol name. WARNING: modpost: vmlinux.o: section mismatch in reference: get_foo (section: .text) -> foo (section: .init.data) For R_ARM_ABS32, addend_arm_rel() sets r->r_addend to a wrong value. I just mimicked the code in arch/arm/kernel/module.c. However, there is more difficulty for ARM. Here, test code. [test code 2] #include <linux/init.h> int __initdata foo; int get_foo(void) { return foo; } int __initdata bar; int get_bar(void) { return bar; } With this commit applied, modpost will show the following messages for ARM versatile_defconfig: WARNING: modpost: vmlinux.o: section mismatch in reference: get_foo (section: .text) -> foo (section: .init.data) WARNING: modpost: vmlinux.o: section mismatch in reference: get_bar (section: .text) -> foo (section: .init.data) The reference from 'get_bar' to 'foo' seems wrong. I have no solution for this because it is true in assembly level. In the following output, relocation at 0x1c is no longer associated with 'bar'. The two relocation entries point to the same symbol, and the offset to 'bar' is encoded in the instruction 'r0, [r3, #4]'. Disassembly of section .text: 00000000 <get_foo>: 0: e59f3004 ldr r3, [pc, #4] @ c <get_foo+0xc> 4: e5930000 ldr r0, [r3] 8: e12fff1e bx lr c: 00000000 .word 0x00000000 00000010 <get_bar>: 10: e59f3004 ldr r3, [pc, #4] @ 1c <get_bar+0xc> 14: e5930004 ldr r0, [r3, #4] 18: e12fff1e bx lr 1c: 00000000 .word 0x00000000 Relocation section '.rel.text' at offset 0x244 contains 2 entries: Offset Info Type Sym.Value Sym. Name 0000000c 00000c02 R_ARM_ABS32 00000000 .init.data 0000001c 00000c02 R_ARM_ABS32 00000000 .init.data When find_elf_symbol() gets into a situation where relsym->st_name is zero, there is no guarantee to get the symbol name as written in C. I am keeping the current logic because it is useful in many architectures, but the symbol name is not always correct depending on the optimization. I left some comments in find_tosym(). Fixes: 56a974fa2d59 ("kbuild: make better section mismatch reports on arm") Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> |
/linux-master/scripts/ | ||
H A D | Makefile.modpost | diff f73edc89 Sat Sep 24 12:19:13 MDT 2022 Masahiro Yamada <masahiroy@kernel.org> kbuild: unify two modpost invocations Currently, modpost is executed twice; first for vmlinux, second for modules. This commit merges them. Current build flow ================== 1) build obj-y and obj-m objects 2) link vmlinux.o 3) modpost for vmlinux 4) link vmlinux 5) modpost for modules 6) link modules (*.ko) The build steps 1) through 6) are serialized, that is, modules are built after vmlinux. You do not get benefits of parallel builds when scripts/link-vmlinux.sh is being run. New build flow ============== 1) build obj-y and obj-m objects 2) link vmlinux.o 3) modpost for vmlinux and modules 4a) link vmlinux 4b) link modules (*.ko) In the new build flow, modpost is invoked just once. vmlinux and modules are built in parallel. One exception is CONFIG_DEBUG_INFO_BTF_MODULES=y, where modules depend on vmlinux. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Tested-by: Nick Desaulniers <ndesaulniers@google.com> Reviewed-by: Nicolas Schier <nicolas@fjasle.eu> diff f73edc89 Sat Sep 24 12:19:13 MDT 2022 Masahiro Yamada <masahiroy@kernel.org> kbuild: unify two modpost invocations Currently, modpost is executed twice; first for vmlinux, second for modules. This commit merges them. Current build flow ================== 1) build obj-y and obj-m objects 2) link vmlinux.o 3) modpost for vmlinux 4) link vmlinux 5) modpost for modules 6) link modules (*.ko) The build steps 1) through 6) are serialized, that is, modules are built after vmlinux. You do not get benefits of parallel builds when scripts/link-vmlinux.sh is being run. New build flow ============== 1) build obj-y and obj-m objects 2) link vmlinux.o 3) modpost for vmlinux and modules 4a) link vmlinux 4b) link modules (*.ko) In the new build flow, modpost is invoked just once. vmlinux and modules are built in parallel. One exception is CONFIG_DEBUG_INFO_BTF_MODULES=y, where modules depend on vmlinux. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Tested-by: Nick Desaulniers <ndesaulniers@google.com> Reviewed-by: Nicolas Schier <nicolas@fjasle.eu> diff f73edc89 Sat Sep 24 12:19:13 MDT 2022 Masahiro Yamada <masahiroy@kernel.org> kbuild: unify two modpost invocations Currently, modpost is executed twice; first for vmlinux, second for modules. This commit merges them. Current build flow ================== 1) build obj-y and obj-m objects 2) link vmlinux.o 3) modpost for vmlinux 4) link vmlinux 5) modpost for modules 6) link modules (*.ko) The build steps 1) through 6) are serialized, that is, modules are built after vmlinux. You do not get benefits of parallel builds when scripts/link-vmlinux.sh is being run. New build flow ============== 1) build obj-y and obj-m objects 2) link vmlinux.o 3) modpost for vmlinux and modules 4a) link vmlinux 4b) link modules (*.ko) In the new build flow, modpost is invoked just once. vmlinux and modules are built in parallel. One exception is CONFIG_DEBUG_INFO_BTF_MODULES=y, where modules depend on vmlinux. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Tested-by: Nick Desaulniers <ndesaulniers@google.com> Reviewed-by: Nicolas Schier <nicolas@fjasle.eu> diff 38e89184 Fri Dec 11 11:46:20 MST 2020 Sami Tolvanen <samitolvanen@google.com> kbuild: lto: fix module versioning With CONFIG_MODVERSIONS, version information is linked into each compilation unit that exports symbols. With LTO, we cannot use this method as all C code is compiled into LLVM bitcode instead. This change collects symbol versions into .symversions files and merges them in link-vmlinux.sh where they are all linked into vmlinux.o at the same time. Signed-off-by: Sami Tolvanen <samitolvanen@google.com> Reviewed-by: Kees Cook <keescook@chromium.org> Signed-off-by: Kees Cook <keescook@chromium.org> Link: https://lore.kernel.org/r/20201211184633.3213045-4-samitolvanen@google.com diff 4e5ab74c Sun May 31 23:57:03 MDT 2020 Masahiro Yamada <masahiroy@kernel.org> modpost: pass -N option only for modules modpost The built-in only code is not required to have MODULE_IMPORT_NS() to use symbols. So, the namespace is not checked for vmlinux(.o). Do not pass the meaningless -N option to the first pass of modpost. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> diff 91e6ee58 Sun May 31 23:57:01 MDT 2020 Masahiro Yamada <masahiroy@kernel.org> modpost: fix -i (--ignore-errors) MAKEFLAGS detection $(filter -i,$(MAKEFLAGS)) works only in limited use-cases. The representation of $(MAKEFLAGS) depends on various factors: - GNU Make version (version 3.8x or version 4.x) - The presence of other flags like -j In my experiments, $(MAKEFLAGS) is expanded as follows: * GNU Make 3.8x: * without -j option: --no-print-directory -Rri * with -j option: --no-print-directory -Rr --jobserver-fds=3,4 -j -i * GNU Make 4.x: * without -j option: irR --no-print-directory * with -j option: irR -j --jobserver-fds=3,4 --no-print-directory For GNU Make 4.x, the flags are grouped as 'irR', which does not work. For the single thread build with GNU Make 3.8x, the flags are grouped as '-Rri', which does not work either. To make it work for all cases, do likewise as commit 6f0fa58e4596 ("kbuild: simplify silent build (-s) detection"). BTW, since commit ff9b45c55b26 ("kbuild: modpost: read modules.order instead of $(MODVERDIR)/*.mod"), you also need to pass -k option to build final *.ko files. 'make -i -k' ignores compile errors in modules, and build as many remaining *.ko as possible. Please note this feature is kind of dangerous if other modules depend on the broken module because the generated modules will lack the correct module dependency or CRC. Honestly, I am not a big fan of it, but I am keeping this feature. Fixes: eed380f3f593 ("modpost: Optionally ignore secondary errors seen if a single module build fails") Cc: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> diff 91e6ee58 Sun May 31 23:57:01 MDT 2020 Masahiro Yamada <masahiroy@kernel.org> modpost: fix -i (--ignore-errors) MAKEFLAGS detection $(filter -i,$(MAKEFLAGS)) works only in limited use-cases. The representation of $(MAKEFLAGS) depends on various factors: - GNU Make version (version 3.8x or version 4.x) - The presence of other flags like -j In my experiments, $(MAKEFLAGS) is expanded as follows: * GNU Make 3.8x: * without -j option: --no-print-directory -Rri * with -j option: --no-print-directory -Rr --jobserver-fds=3,4 -j -i * GNU Make 4.x: * without -j option: irR --no-print-directory * with -j option: irR -j --jobserver-fds=3,4 --no-print-directory For GNU Make 4.x, the flags are grouped as 'irR', which does not work. For the single thread build with GNU Make 3.8x, the flags are grouped as '-Rri', which does not work either. To make it work for all cases, do likewise as commit 6f0fa58e4596 ("kbuild: simplify silent build (-s) detection"). BTW, since commit ff9b45c55b26 ("kbuild: modpost: read modules.order instead of $(MODVERDIR)/*.mod"), you also need to pass -k option to build final *.ko files. 'make -i -k' ignores compile errors in modules, and build as many remaining *.ko as possible. Please note this feature is kind of dangerous if other modules depend on the broken module because the generated modules will lack the correct module dependency or CRC. Honestly, I am not a big fan of it, but I am keeping this feature. Fixes: eed380f3f593 ("modpost: Optionally ignore secondary errors seen if a single module build fails") Cc: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> diff 91e6ee58 Sun May 31 23:57:01 MDT 2020 Masahiro Yamada <masahiroy@kernel.org> modpost: fix -i (--ignore-errors) MAKEFLAGS detection $(filter -i,$(MAKEFLAGS)) works only in limited use-cases. The representation of $(MAKEFLAGS) depends on various factors: - GNU Make version (version 3.8x or version 4.x) - The presence of other flags like -j In my experiments, $(MAKEFLAGS) is expanded as follows: * GNU Make 3.8x: * without -j option: --no-print-directory -Rri * with -j option: --no-print-directory -Rr --jobserver-fds=3,4 -j -i * GNU Make 4.x: * without -j option: irR --no-print-directory * with -j option: irR -j --jobserver-fds=3,4 --no-print-directory For GNU Make 4.x, the flags are grouped as 'irR', which does not work. For the single thread build with GNU Make 3.8x, the flags are grouped as '-Rri', which does not work either. To make it work for all cases, do likewise as commit 6f0fa58e4596 ("kbuild: simplify silent build (-s) detection"). BTW, since commit ff9b45c55b26 ("kbuild: modpost: read modules.order instead of $(MODVERDIR)/*.mod"), you also need to pass -k option to build final *.ko files. 'make -i -k' ignores compile errors in modules, and build as many remaining *.ko as possible. Please note this feature is kind of dangerous if other modules depend on the broken module because the generated modules will lack the correct module dependency or CRC. Honestly, I am not a big fan of it, but I am keeping this feature. Fixes: eed380f3f593 ("modpost: Optionally ignore secondary errors seen if a single module build fails") Cc: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> diff 91e6ee58 Sun May 31 23:57:01 MDT 2020 Masahiro Yamada <masahiroy@kernel.org> modpost: fix -i (--ignore-errors) MAKEFLAGS detection $(filter -i,$(MAKEFLAGS)) works only in limited use-cases. The representation of $(MAKEFLAGS) depends on various factors: - GNU Make version (version 3.8x or version 4.x) - The presence of other flags like -j In my experiments, $(MAKEFLAGS) is expanded as follows: * GNU Make 3.8x: * without -j option: --no-print-directory -Rri * with -j option: --no-print-directory -Rr --jobserver-fds=3,4 -j -i * GNU Make 4.x: * without -j option: irR --no-print-directory * with -j option: irR -j --jobserver-fds=3,4 --no-print-directory For GNU Make 4.x, the flags are grouped as 'irR', which does not work. For the single thread build with GNU Make 3.8x, the flags are grouped as '-Rri', which does not work either. To make it work for all cases, do likewise as commit 6f0fa58e4596 ("kbuild: simplify silent build (-s) detection"). BTW, since commit ff9b45c55b26 ("kbuild: modpost: read modules.order instead of $(MODVERDIR)/*.mod"), you also need to pass -k option to build final *.ko files. 'make -i -k' ignores compile errors in modules, and build as many remaining *.ko as possible. Please note this feature is kind of dangerous if other modules depend on the broken module because the generated modules will lack the correct module dependency or CRC. Honestly, I am not a big fan of it, but I am keeping this feature. Fixes: eed380f3f593 ("modpost: Optionally ignore secondary errors seen if a single module build fails") Cc: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> diff 91e6ee58 Sun May 31 23:57:01 MDT 2020 Masahiro Yamada <masahiroy@kernel.org> modpost: fix -i (--ignore-errors) MAKEFLAGS detection $(filter -i,$(MAKEFLAGS)) works only in limited use-cases. The representation of $(MAKEFLAGS) depends on various factors: - GNU Make version (version 3.8x or version 4.x) - The presence of other flags like -j In my experiments, $(MAKEFLAGS) is expanded as follows: * GNU Make 3.8x: * without -j option: --no-print-directory -Rri * with -j option: --no-print-directory -Rr --jobserver-fds=3,4 -j -i * GNU Make 4.x: * without -j option: irR --no-print-directory * with -j option: irR -j --jobserver-fds=3,4 --no-print-directory For GNU Make 4.x, the flags are grouped as 'irR', which does not work. For the single thread build with GNU Make 3.8x, the flags are grouped as '-Rri', which does not work either. To make it work for all cases, do likewise as commit 6f0fa58e4596 ("kbuild: simplify silent build (-s) detection"). BTW, since commit ff9b45c55b26 ("kbuild: modpost: read modules.order instead of $(MODVERDIR)/*.mod"), you also need to pass -k option to build final *.ko files. 'make -i -k' ignores compile errors in modules, and build as many remaining *.ko as possible. Please note this feature is kind of dangerous if other modules depend on the broken module because the generated modules will lack the correct module dependency or CRC. Honestly, I am not a big fan of it, but I am keeping this feature. Fixes: eed380f3f593 ("modpost: Optionally ignore secondary errors seen if a single module build fails") Cc: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> |
/linux-master/ | ||
H A D | Makefile | diff 4cece764 Sun Mar 24 15:10:05 MDT 2024 Linus Torvalds <torvalds@linux-foundation.org> Linux 6.9-rc1 diff 50a33998 Fri Mar 01 04:21:07 MST 2024 Masahiro Yamada <masahiroy@kernel.org> kbuild: fix inconsistent indentation in top Makefile Commit 3b9ab248bc45 ("kbuild: use 4-space indentation when followed by conditionals") introduced inconsistent indentation because it deliberately touched only the conditional directives to minimize the change set. This commit reformats some blocks in the top Makefile so they are consistently indented with 4 spaces. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Reviewed-by: Nathan Chancellor <nathan@kernel.org> diff 50a33998 Fri Mar 01 04:21:07 MST 2024 Masahiro Yamada <masahiroy@kernel.org> kbuild: fix inconsistent indentation in top Makefile Commit 3b9ab248bc45 ("kbuild: use 4-space indentation when followed by conditionals") introduced inconsistent indentation because it deliberately touched only the conditional directives to minimize the change set. This commit reformats some blocks in the top Makefile so they are consistently indented with 4 spaces. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Reviewed-by: Nathan Chancellor <nathan@kernel.org> diff 3b9ab248 Thu Feb 01 18:31:42 MST 2024 Masahiro Yamada <masahiroy@kernel.org> kbuild: use 4-space indentation when followed by conditionals GNU Make manual [1] clearly forbids a tab at the beginning of the conditional directive line: "Extra spaces are allowed and ignored at the beginning of the conditional directive line, but a tab is not allowed." This will not work for the next release of GNU Make, hence commit 82175d1f9430 ("kbuild: Replace tabs with spaces when followed by conditionals") replaced the inappropriate tabs with 8 spaces. However, the 8-space indentation cannot be visually distinguished. Linus suggested 2-4 spaces for those nested if-statements. [2] This commit redoes the replacement with 4 spaces. [1]: https://www.gnu.org/software/make/manual/make.html#Conditional-Syntax [2]: https://lore.kernel.org/all/CAHk-=whJKZNZWsa-VNDKafS_VfY4a5dAjG-r8BZgWk_a-xSepw@mail.gmail.com/ Suggested-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> diff 3b9ab248 Thu Feb 01 18:31:42 MST 2024 Masahiro Yamada <masahiroy@kernel.org> kbuild: use 4-space indentation when followed by conditionals GNU Make manual [1] clearly forbids a tab at the beginning of the conditional directive line: "Extra spaces are allowed and ignored at the beginning of the conditional directive line, but a tab is not allowed." This will not work for the next release of GNU Make, hence commit 82175d1f9430 ("kbuild: Replace tabs with spaces when followed by conditionals") replaced the inappropriate tabs with 8 spaces. However, the 8-space indentation cannot be visually distinguished. Linus suggested 2-4 spaces for those nested if-statements. [2] This commit redoes the replacement with 4 spaces. [1]: https://www.gnu.org/software/make/manual/make.html#Conditional-Syntax [2]: https://lore.kernel.org/all/CAHk-=whJKZNZWsa-VNDKafS_VfY4a5dAjG-r8BZgWk_a-xSepw@mail.gmail.com/ Suggested-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> diff 3b9ab248 Thu Feb 01 18:31:42 MST 2024 Masahiro Yamada <masahiroy@kernel.org> kbuild: use 4-space indentation when followed by conditionals GNU Make manual [1] clearly forbids a tab at the beginning of the conditional directive line: "Extra spaces are allowed and ignored at the beginning of the conditional directive line, but a tab is not allowed." This will not work for the next release of GNU Make, hence commit 82175d1f9430 ("kbuild: Replace tabs with spaces when followed by conditionals") replaced the inappropriate tabs with 8 spaces. However, the 8-space indentation cannot be visually distinguished. Linus suggested 2-4 spaces for those nested if-statements. [2] This commit redoes the replacement with 4 spaces. [1]: https://www.gnu.org/software/make/manual/make.html#Conditional-Syntax [2]: https://lore.kernel.org/all/CAHk-=whJKZNZWsa-VNDKafS_VfY4a5dAjG-r8BZgWk_a-xSepw@mail.gmail.com/ Suggested-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> diff 66242cfa Mon Nov 20 11:37:19 MST 2023 Heiko Carstens <hca@linux.ibm.com> checkstack: allow to pass MINSTACKSIZE parameter The checkstack script omits all functions with a stack usage of less than 100 bytes. However the script already has support for a parameter which allows to override the default, but it cannot be set with $ make checkstack Add a MINSTACKSIZE parameter which allows to change the default. This might be useful in order to print the stack usage of all functions, or only those with large stack usage: $ make checkstack MINSTACKSIZE=0 $ make checkstack MINSTACKSIZE=800 Link: https://lkml.kernel.org/r/20231120183719.2188479-4-hca@linux.ibm.com Signed-off-by: Heiko Carstens <hca@linux.ibm.com> Cc: Maninder Singh <maninder1.s@samsung.com> Cc: Masahiro Yamada <masahiroy@kernel.org> Cc: Vaneet Narang <v.narang@samsung.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> diff 4e3feaad Tue Jan 24 09:19:28 MST 2023 Nathan Chancellor <nathan@kernel.org> powerpc/vdso: Filter clang's auto var init zero enabler when linking After commit 8d9acfce3332 ("kbuild: Stop using '-Qunused-arguments' with clang"), the PowerPC vDSO shows the following error with clang-13 and older when CONFIG_INIT_STACK_ALL_ZERO is enabled: clang: error: argument unused during compilation: '-enable-trivial-auto-var-init-zero-knowing-it-will-be-removed-from-clang' [-Werror,-Wunused-command-line-argument] clang-14 added a change to make sure this flag never triggers -Wunused-command-line-argument, so it is fixed with newer releases. For older releases that the kernel still supports building with, just filter out this flag, as has been done for other flags. Fixes: f0a42fbab447 ("powerpc/vdso: Improve linker flags") Fixes: 8d9acfce3332 ("kbuild: Stop using '-Qunused-arguments' with clang") Link: https://github.com/llvm/llvm-project/commit/ca6d5813d17598cd180995fb3bdfca00f364475f Signed-off-by: Nathan Chancellor <nathan@kernel.org> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> diff 4ec5183e Sun Feb 05 14:13:28 MST 2023 Linus Torvalds <torvalds@linux-foundation.org> Linux 6.2-rc7 diff 4bf73588 Mon Dec 05 14:48:19 MST 2022 Dmitry Goncharov <dgoncharov@users.sf.net> kbuild: Port silent mode detection to future gnu make. Port silent mode detection to the future (post make-4.4) versions of gnu make. Makefile contains the following piece of make code to detect if option -s is specified on the command line. ifneq ($(findstring s,$(filter-out --%,$(MAKEFLAGS))),) This code is executed by make at parse time and assumes that MAKEFLAGS does not contain command line variable definitions. Currently if the user defines a=s on the command line, then at build only time MAKEFLAGS contains " -- a=s". However, starting with commit dc2d963989b96161472b2cd38cef5d1f4851ea34 MAKEFLAGS contains command line definitions at both parse time and build time. This '-s' detection code then confuses a command line variable definition which contains letter 's' with option -s. $ # old make $ make net/wireless/ocb.o a=s CALL scripts/checksyscalls.sh DESCEND objtool $ # this a new make which defines makeflags at parse time $ ~/src/gmake/make/l64/make net/wireless/ocb.o a=s $ We can see here that the letter 's' from 'a=s' was confused with -s. This patch checks for presence of -s using a method recommended by the make manual here https://www.gnu.org/software/make/manual/make.html#Testing-Flags. Link: https://lists.gnu.org/archive/html/bug-make/2022-11/msg00190.html Reported-by: Jan Palus <jpalus+gnu@fastmail.com> Signed-off-by: Dmitry Goncharov <dgoncharov@users.sf.net> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> |
Completed in 1417 milliseconds