Build error on -next: Unexpected GOT/PLT entries detected! (was Re: [PATCH v9 9/9] iommu/arm-smmu-v3: Add unit tests for arm_smmu_write_entry)

[Thorsten Leemhuis]

On 07.05.24 14:41, Jason Gunthorpe wrote:
> On Tue, May 07, 2024 at 02:15:51PM +0200, Thorsten Leemhuis wrote:
>> On 30.04.24 19:21, Jason Gunthorpe wrote:
>>> Add tests for some of the more common STE update operations that we expect
>>> to see, as well as some artificial STE updates to test the edges of
>>> arm_smmu_write_entry. These also serve as a record of which common
>>> operation is expected to be hitless, and how many syncs they require.
>>>
>>> arm_smmu_write_entry implements a generic algorithm that updates an STE/CD
>>> to any other abritrary STE/CD configuration. The update requires a
>>> sequence of write+sync operations with some invariants that must be held
>>> true after each sync. arm_smmu_write_entry lends itself well to
>>> unit-testing since the function's interaction with the STE/CD is already
>>> abstracted by input callbacks that we can hook to introspect into the
>>> sequence of operations. We can use these hooks to guarantee that
>>> invariants are held throughout the entire update operation.
>>>
>>> [...]
>>>
>>> +static void arm_smmu_v3_test_ste_expect_transition(
>>> +	struct kunit *test, const struct arm_smmu_ste *cur,
>>> +	const struct arm_smmu_ste *target, unsigned int num_syncs_expected,
>>> +	bool hitless)
>>> +{
>>> +	struct arm_smmu_ste cur_copy = *cur;
>>> [...]
>>
>> Lo! My daily -next builds of vanilla kernel RPM packages for all
>> current Fedora releases started all to fail today on ARM64.
> 
> Fedora enables kunit in a production kernel????

FWIW, I'm just a interested Fedora downstream party here that uses
Fedora's mechanisms as a base for daily -next builds.

But yes, kunit is enabled by default. All the modules then then go into
a sub-package that is shipped, but normally not installed.
>> I currently lack time to investigate this properly, so feel free to
>> ignore this, maybe this is a false alarm and cause by the build
>> instructions in the RPM .spec file doing something stupid.
> 
> That's surprising to me.. this has been in 0-day for months now and
> it's kconfig randomizer didn't hit this combination.

Wild guess: maybe the Fedora stuff that generates the kernel
configuration does something odd that later confuses olddefconfig to let
this pass?

>> /usr/bin/make -s 'HOSTCFLAGS=-O2  -fexceptions -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 \
>> -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 \
>> -mbranch-protection=standard -fasynchronous-unwind-tables -fstack-clash-protection   ' 'HOSTLDFLAGS=-Wl,-z,relro -Wl,--as-needed 
>> -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld-errors -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 \
>> -Wl,--build-id=sha1 -specs=/usr/lib/rpm/redhat/redhat-package-notes ' ARCH=arm64 'KCFLAGS= ' WITH_GCOV=0 -j4 vmlinuz.efi
>> [...]
>> ld: Unexpected GOT/PLT entries detected!
>> ld: Unexpected run-time procedure linkages detected!
>> ld: drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-test.o: in function `arm_smmu_v3_test_ste_expect_transition':
>> /builddir/build/BUILD/kernel-next-20240507/linux-6.9.0-0.0.next.20240507.458.vanilla.fc41.aarch64/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-test.c:144:(.text+0x6f8): undefined reference to `kunit_mem_assert_format'
> 
> It is because your .config has kunit as modular but smmu is not. I
> thought the kconfig prevented that in the usual way, but I see it
> doesn't work :\

Ohh. And thx!

Ciao, Thorsten