Le 17/10/2024 à 01:21, Luis Chamberlain a écrit :
On Tue, Oct 15, 2024 at 04:22:22PM -0700, Matthew Maurer wrote:
So, the basic things I can think of to test here are:
1. The kernel can still load the previous MODVERSIONS format
2. The kernel can load the new MODVERSIONS format
3. If we artificially tweak a CRC in the previous format, it will fail to load.
4. If we artificially tweak a CRC in the new format, it will fail to load.
5. With CONFIG_EXTENDED_MODVERSIONS enabled, the kernel will build and
load modules with long symbol names, with MODVERSIONS enabled.
Is there anything else you were thinking of here, or are those the
kinds of checks you were envisioning?
That sounds great. Yeah, the above would be great to test. A while ago
I wrote a new modules selftests in order to test possible improvements
on find_symbol() but I also did this due to push the limits of the
numbers of symbols we could support. I wrote all this to also test the
possible 64-bit alignment benefits of __ksymtab_ sections on
architectures without CONFIG_HAVE_ARCH_PREL32_RELOCATIONS (e.g. ppc64,
ppc64le, parisc, s390x,...). But come to think of it, you might be
able to easily leverage this to also just test long symbols by self
generated symbols as another test case. In case its useful to you I've
put this in a rebased branch 20241016-modules-symtab branch. Feel free
to use as you see fit.
By reading this, I discovered that was initially added to powerpc by
commit 271ca788774a ("arch: enable relative relocations for arm64, power
and x86") and then removed due to problem with modules, see commit
ff69279a44e9 ("powerpc: disable support for relative ksymtab references")
Wouldn't it be better to try and fix modules and activate again
CONFIG_HAVE_ARCH_PREL32_RELOCATIONS on powerpc ?
Christophe
