From: Naman Jain <[email protected]> Sent: Monday, April 13, 2026 9:52 AM > >>> > >>> Sashiko AI raised an interesting question about the startup timing -- > >>> whether the vmbus_platform_driver_probe() is guaranteed to have > >>> set vmbus_interrupt before the VTL functions below run and use it. > >>> What causes the mshv_vtl.ko module to be loaded, and hence run > >>> mshv_vtl_init()? > >> > >> There is no race condition here. The init ordering guarantees that > >> vmbus_interrupt is always set before mshv_vtl_synic_enable_regs() > >> reads it. > >> > >> The call chain for setting vmbus_interrupt: > >> > >> subsys_initcall(hv_acpi_init) [level 4] > >> -> platform_driver_register(&vmbus_platform_driver) and so on. > >> > >> > >> The call chain for reading vmbus_interrupt: > >> > >> module_init(mshv_vtl_init) [level 6] > >> -> hv_vtl_setup_synic() > >> -> cpuhp_setup_state(CPUHP_AP_ONLINE_DYN, ..., > >> mshv_vtl_alloc_context, ...) > >> -> mshv_vtl_alloc_context() > >> -> mshv_vtl_synic_enable_regs() > >> -> sint.vector = vmbus_interrupt > >> > >> do_initcalls() processes sections in order 0 through 7, so > >> hv_acpi_init() (level 4) is guaranteed to complete before > >> mshv_vtl_init() (level 6) runs. > >> > > > > I think the situation is more complex than what you describe, depending > > on whether the VMBus driver and/or MSHV_VTL are built as modules vs. > > being built-in to the kernel image. In include/linux/module.h, see the > > comment for module_init() and how subsys_initcall() is mapped > > to module_init() when built as a module. > > > > If both are built-in, then what you describe is correct. But if either or > > both are modules, then the respective init functions (hv_acpi_init > > and mshv_vtl_init) get called at the time the module is loaded, and > > not by do_initcalls(). I think hv_vmbus.ko gets loaded when an attempt > > is first made to access a disk, but I would need to look more closely to > > be sure. I don't have any understanding of what causes mshv_vtl.ko > > to be loaded. And what is the ordering if MSHV_VTL is built-in while > > VMBus is built as a module, or vice versa? > > > > Michael > > > > Based on this, I still feel that this race is not possible. > > hv_vmbus mshv_vtl > y y -> different initcall levels, no issues > y m -> use without initialization is not possible > m y -> config dependencies take care of this, and mshv_vtl > is forced to compile as a module in this case. > m m -> config and symbol dependencies should take care of > it. mshv_vtl has symbol and config dependencies on hv_vmbus, and it > won't allow loading mshv_vtl if hv_vmbus module is not loaded. > > Relevant code here: kernel/module/main.c >
Makes sense. I'm convinced! :-) Michael
