Re: 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)

From: Jason Gunthorpe <jgg@nvidia.com>
To: Thorsten Leemhuis <linux@leemhuis.info>
Cc: iommu@lists.linux.dev, Joerg Roedel <joro@8bytes.org>,
	linux-arm-kernel@lists.infradead.org,
	Robin Murphy <robin.murphy@arm.com>,
	Will Deacon <will@kernel.org>, Eric Auger <eric.auger@redhat.com>,
	Moritz Fischer <mdf@kernel.org>,
	Moritz Fischer <moritzf@google.com>,
	Michael Shavit <mshavit@google.com>,
	Nicolin Chen <nicolinc@nvidia.com>,
	patches@lists.linux.dev,
	Shameer Kolothum <shameerali.kolothum.thodi@huawei.com>,
	Mostafa Saleh <smostafa@google.com>
Subject: Re: 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)
Date: Tue, 7 May 2024 09:41:34 -0300	[thread overview]
Message-ID: <20240507124134.GN3341011@nvidia.com> (raw)
In-Reply-To: <aeea8546-5bce-4c51-b506-5d2008e52fef@leemhuis.info>

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????

> 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.

> /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 :\

Let me come up with something

Jason

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel