On 22.07.2025 07:05, Penny, Zheng wrote: > [Public] > >> -----Original Message----- >> From: Jan Beulich <[email protected]> >> Sent: Thursday, July 17, 2025 4:55 PM >> To: Penny, Zheng <[email protected]>; Stabellini, Stefano >> <[email protected]> >> Cc: Huang, Ray <[email protected]>; Stefano Stabellini >> <[email protected]>; Andrew Cooper <[email protected]>; Roger >> Pau Monné <[email protected]>; Anthony PERARD >> <[email protected]>; Orzel, Michal <[email protected]>; Julien >> Grall <[email protected]>; Sergiy Kibrik <[email protected]>; xen- >> [email protected] >> Subject: Re: [PATCH v8 7/7] xen/sysctl: wrap around sysctl hypercall >> >> On 11.07.2025 06:31, Penny Zheng wrote: >>> --- a/xen/common/Makefile >>> +++ b/xen/common/Makefile >>> @@ -49,6 +49,7 @@ obj-y += spinlock.o >>> obj-$(CONFIG_STACK_PROTECTOR) += stack-protector.o obj-y += >>> stop_machine.o obj-y += symbols.o >>> +obj-$(CONFIG_SYSCTL) += sysctl.o >>> obj-y += tasklet.o >>> obj-y += time.o >>> obj-y += timer.o >>> @@ -70,7 +71,6 @@ obj-$(CONFIG_COMPAT) += $(addprefix compat/,domain.o >>> memory.o multicall.o xlat.o ifneq ($(CONFIG_PV_SHIM_EXCLUSIVE),y) >>> obj-y += domctl.o >>> obj-$(CONFIG_VM_EVENT) += monitor.o >>> -obj-y += sysctl.o >>> endif >>> >>> extra-y := symbols-dummy.o >> >> CI demonstrates that this combination of changes is wrong. The job that >> failed >> (debian-12-x86_64-gcc-ibt) is a randconfig one, and ended up picking both >> SYSCTL=y and PV_SHIM_EXCLUSIVE=y. Which results in sysctl.c being built, >> but domctl.c not being built. Which leaves getdomaininfo() undefined, causing >> linking to fail. In case the next pipeline also ends up failing, I'll simply >> revert that >> change. In case it succeeds, not reverting may be an option, as long as a >> proper fix >> shows up pretty quickly. > > I've push commit of " xen: move getdomaininfo() to domain.c " to try to fix > the error.
And you're reasonably certain that's the only issue? I ask because it is the nature of randconfig to pick random combinations of settings; on a later pipeline I had seen a different failure. I didn't look at that in detail (it may have had to do with the domctl lock or something vaguely similar), which perhaps was a mistake. Jan
