Re: [PATCH v8 7/7] xen/sysctl: wrap around sysctl hypercall

[Jan Beulich <jbeulich@xxxxxxxx>]

On 22.07.2025 07:05, Penny, Zheng wrote:
> [Public]
> 
>> -----Original Message-----
>> From: Jan Beulich <jbeulich@xxxxxxxx>
>> Sent: Thursday, July 17, 2025 4:55 PM
>> To: Penny, Zheng <penny.zheng@xxxxxxx>; Stabellini, Stefano
>> <stefano.stabellini@xxxxxxx>
>> Cc: Huang, Ray <Ray.Huang@xxxxxxx>; Stefano Stabellini
>> <sstabellini@xxxxxxxxxx>; Andrew Cooper <andrew.cooper3@xxxxxxxxxx>; Roger
>> Pau Monné <roger.pau@xxxxxxxxxx>; Anthony PERARD
>> <anthony.perard@xxxxxxxxxx>; Orzel, Michal <Michal.Orzel@xxxxxxx>; Julien
>> Grall <julien@xxxxxxx>; Sergiy Kibrik <Sergiy_Kibrik@xxxxxxxx>; xen-
>> devel@xxxxxxxxxxxxxxxxxxxx
>> 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