2
0
mirror of https://github.com/edk2-porting/linux-next.git synced 2024-12-26 14:14:01 +08:00
linux-next/scripts/modules-check.sh

17 lines
303 B
Bash
Raw Normal View History

kbuild: check uniqueness of module names In the recent build test of linux-next, Stephen saw a build error caused by a broken .tmp_versions/*.mod file: https://lkml.org/lkml/2019/5/13/991 drivers/net/phy/asix.ko and drivers/net/usb/asix.ko have the same basename, and there is a race in generating .tmp_versions/asix.mod Kbuild has not checked this before, and it suddenly shows up with obscure error messages when this kind of race occurs. Non-unique module names cause various sort of problems, but it is not trivial to catch them by eyes. Hence, this script. It checks not only real modules, but also built-in modules (i.e. controlled by tristate CONFIG option, but currently compiled with =y). Non-unique names for built-in modules also cause problems because /sys/modules/ would fall over. For the latest kernel, I tested "make allmodconfig all" (or more quickly "make allyesconfig modules"), and it detected the following: warning: same basename if the following are built as modules: drivers/regulator/88pm800.ko drivers/mfd/88pm800.ko warning: same basename if the following are built as modules: drivers/gpu/drm/bridge/adv7511/adv7511.ko drivers/media/i2c/adv7511.ko warning: same basename if the following are built as modules: drivers/net/phy/asix.ko drivers/net/usb/asix.ko warning: same basename if the following are built as modules: fs/coda/coda.ko drivers/media/platform/coda/coda.ko warning: same basename if the following are built as modules: drivers/net/phy/realtek.ko drivers/net/dsa/realtek.ko Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Reviewed-by: Kees Cook <keescook@chromium.org> Reviewed-by: Stephen Rothwell <sfr@canb.auug.org.au> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
2019-05-18 00:07:15 +08:00
#!/bin/sh
# SPDX-License-Identifier: GPL-2.0
set -e
# Check uniqueness of module names
check_same_name_modules()
{
kbuild: do not check name uniqueness of builtin modules I just thought it was a good idea to scan builtin.modules in the name uniqueness checking, but a couple of false positives were found. Stephen reported a false positive for ppc64_defconfig: warning: same basename if the following are built as modules: arch/powerpc/platforms/powermac/nvram.ko drivers/char/nvram.ko The former is never built as a module as you see in arch/powerpc/platforms/powermac/Makefile: # CONFIG_NVRAM is an arch. independent tristate symbol, for pmac32 we really # need this to be a bool. Cheat here and pretend CONFIG_NVRAM=m is really # CONFIG_NVRAM=y obj-$(CONFIG_NVRAM:m=y) += nvram.o Another example of false positive is arm64 defconfig: warning: same basename if the following are built as modules: arch/arm64/lib/crc32.ko lib/crc32.ko It is true CONFIG_CRC32 is a tristate option but it is always 'y' since it is select'ed by ARM64. Hence, neither of them is built as a module for the arm64 build. From the above, modules.builtin essentially contains false positives. I do not think it is a big deal as far as kmod is concerned, but false positive warnings in the kernel build make people upset. It is better to not check it. Even without builtin.modules checked, we have enough (and more solid) test coverage with allmodconfig. While I touched this part, I replaced the sed code with neater one provided by Stephen. Link: https://lkml.org/lkml/2019/5/19/120 Link: https://lkml.org/lkml/2019/5/19/123 Fixes: 3a48a91901c5 ("kbuild: check uniqueness of module names") Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Acked-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-05-20 10:54:37 +08:00
for m in $(sed 's:.*/::' modules.order | sort | uniq -d)
kbuild: check uniqueness of module names In the recent build test of linux-next, Stephen saw a build error caused by a broken .tmp_versions/*.mod file: https://lkml.org/lkml/2019/5/13/991 drivers/net/phy/asix.ko and drivers/net/usb/asix.ko have the same basename, and there is a race in generating .tmp_versions/asix.mod Kbuild has not checked this before, and it suddenly shows up with obscure error messages when this kind of race occurs. Non-unique module names cause various sort of problems, but it is not trivial to catch them by eyes. Hence, this script. It checks not only real modules, but also built-in modules (i.e. controlled by tristate CONFIG option, but currently compiled with =y). Non-unique names for built-in modules also cause problems because /sys/modules/ would fall over. For the latest kernel, I tested "make allmodconfig all" (or more quickly "make allyesconfig modules"), and it detected the following: warning: same basename if the following are built as modules: drivers/regulator/88pm800.ko drivers/mfd/88pm800.ko warning: same basename if the following are built as modules: drivers/gpu/drm/bridge/adv7511/adv7511.ko drivers/media/i2c/adv7511.ko warning: same basename if the following are built as modules: drivers/net/phy/asix.ko drivers/net/usb/asix.ko warning: same basename if the following are built as modules: fs/coda/coda.ko drivers/media/platform/coda/coda.ko warning: same basename if the following are built as modules: drivers/net/phy/realtek.ko drivers/net/dsa/realtek.ko Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Reviewed-by: Kees Cook <keescook@chromium.org> Reviewed-by: Stephen Rothwell <sfr@canb.auug.org.au> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
2019-05-18 00:07:15 +08:00
do
kbuild: do not check name uniqueness of builtin modules I just thought it was a good idea to scan builtin.modules in the name uniqueness checking, but a couple of false positives were found. Stephen reported a false positive for ppc64_defconfig: warning: same basename if the following are built as modules: arch/powerpc/platforms/powermac/nvram.ko drivers/char/nvram.ko The former is never built as a module as you see in arch/powerpc/platforms/powermac/Makefile: # CONFIG_NVRAM is an arch. independent tristate symbol, for pmac32 we really # need this to be a bool. Cheat here and pretend CONFIG_NVRAM=m is really # CONFIG_NVRAM=y obj-$(CONFIG_NVRAM:m=y) += nvram.o Another example of false positive is arm64 defconfig: warning: same basename if the following are built as modules: arch/arm64/lib/crc32.ko lib/crc32.ko It is true CONFIG_CRC32 is a tristate option but it is always 'y' since it is select'ed by ARM64. Hence, neither of them is built as a module for the arm64 build. From the above, modules.builtin essentially contains false positives. I do not think it is a big deal as far as kmod is concerned, but false positive warnings in the kernel build make people upset. It is better to not check it. Even without builtin.modules checked, we have enough (and more solid) test coverage with allmodconfig. While I touched this part, I replaced the sed code with neater one provided by Stephen. Link: https://lkml.org/lkml/2019/5/19/120 Link: https://lkml.org/lkml/2019/5/19/123 Fixes: 3a48a91901c5 ("kbuild: check uniqueness of module names") Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Acked-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-05-20 10:54:37 +08:00
echo "warning: same module names found:" >&2
sed -n "/\/$m/s:^: :p" modules.order >&2
kbuild: check uniqueness of module names In the recent build test of linux-next, Stephen saw a build error caused by a broken .tmp_versions/*.mod file: https://lkml.org/lkml/2019/5/13/991 drivers/net/phy/asix.ko and drivers/net/usb/asix.ko have the same basename, and there is a race in generating .tmp_versions/asix.mod Kbuild has not checked this before, and it suddenly shows up with obscure error messages when this kind of race occurs. Non-unique module names cause various sort of problems, but it is not trivial to catch them by eyes. Hence, this script. It checks not only real modules, but also built-in modules (i.e. controlled by tristate CONFIG option, but currently compiled with =y). Non-unique names for built-in modules also cause problems because /sys/modules/ would fall over. For the latest kernel, I tested "make allmodconfig all" (or more quickly "make allyesconfig modules"), and it detected the following: warning: same basename if the following are built as modules: drivers/regulator/88pm800.ko drivers/mfd/88pm800.ko warning: same basename if the following are built as modules: drivers/gpu/drm/bridge/adv7511/adv7511.ko drivers/media/i2c/adv7511.ko warning: same basename if the following are built as modules: drivers/net/phy/asix.ko drivers/net/usb/asix.ko warning: same basename if the following are built as modules: fs/coda/coda.ko drivers/media/platform/coda/coda.ko warning: same basename if the following are built as modules: drivers/net/phy/realtek.ko drivers/net/dsa/realtek.ko Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Reviewed-by: Kees Cook <keescook@chromium.org> Reviewed-by: Stephen Rothwell <sfr@canb.auug.org.au> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
2019-05-18 00:07:15 +08:00
done
}
check_same_name_modules