[LTP] [RFC] loading vmw_vsock_virtio_transport by systemd breaks vsock_loopback autoloading

[Petr Vorel]

[ Cc LTP ML ]

> On Fri, Mar 20, 2026 at 12:02:24PM +0100, Petr Vorel wrote:
> > Hi all,

> > there is a systemd bug [1] which causes vsock_loopback not to be autoloaded due
> > previous loading vmw_vsock_virtio_transport in an early phase of boot.
> > vmw_vsock_virtio_transport requires vmw_vsock_virtio_transport_common and vsock,
> > vsock_loopback requires vsock.

> > Reproducer: [2].
> > Proposed fix in systemd: [3]

> > While I think the bug should be fixed in systemd with proposed fix [3] we'd like
> > to know opinion of the kernel vsock developers in case there is a way to improve
> > vsock modules autoloading.

> The original idea of vsock_loopback was to be used just for
> testing/debugging, so maybe even the autoloading when no other transport was
> loaded wasn't a great idea, but at the time we thought it might be useful
> for testing.

Stefano, thanks for info.

> In general, therefore, if you want to use the loopback, it's always best to
> load vsock_loopback.

> What use case is being affected by the fact that vsock_loopback isn't loaded
> automatically?

It's actually testing. Only LTP test cve-2025-21756.c [1] used it.

Reported [2], fixed in systemd [3].
Of course we could call 'modprobe vsock_loopback' in the test, but now not
needed as as fixed in systemd.

I wonder who else uses the module. Searching in Debian's codesearch I see mostly
testing code (+ now systemd :)).

Kind regards,
Petr

[1] https://github.com/linux-test-project/ltp/blob/master/testcases/cve/cve-2025-21756.c
[2] https://github.com/systemd/systemd/issues/41100
[3] https://github.com/systemd/systemd/commit/7c1075fb8ff2d3b87fa463d542e2e00ac086cbd3
[4] https://codesearch.debian.net/search?q=vsock_loopback&perpkg=1&page=1

> Thanks,
> Stefano