Hi Simon, On Tue, 21 Jan 2025 at 05:53, Simon Kaegi <simon.kaegi@xxxxxxxxx> wrote: > > #regzbot introduced v6.6.69..v6.6.70 > #regzbot introduced: ad91a2dacbf8c26a446658cdd55e8324dfeff1e7 > > We hit this regression when updating our guest vm kernel from 6.6.69 > to 6.6.70 -- bisecting, this problem was introduced in > ad91a2dacbf8c26a446658cdd55e8324dfeff1e7 -- net: restrict SO_REUSEPORT > to inet sockets > > We're getting a timeout when trying to connect to the vsocket in the > guest VM when launching a kata containers 3.10.1 agent which > unsurprisingly ... uses a vsocket to communicate back to the host. > > We updated this commit and added an additional sk_is_vsock check and > recompiled and this works correctly for us. > - if (valbool && !sk_is_inet(sk)) > + if (valbool && !(sk_is_inet(sk) || sk_is_vsock(sk))) > > My understanding is limited here so I've added Stefano as he is likely > to better understand what makes sense here. Thanks for adding me, do you have a reproducer here? AFAIK in AF_VSOCK we never supported SO_REUSEPORT, so it seems strange to me. I understand that the patch you refer to actually changes the behavior of setsockopt(..., SO_REUSEPORT, ...) on an AF_VSOCK socket, where it used to return successfully before that change, but now returns an error, but subsequent binds should have still failed even without this patch. Do you actually use the SO_REUSEPORT feature on AF_VSOCK? If so, I need to better understand if the core socket does anything, but as I recall AF_VSOCK allocates ports internally, so I don't think multiple binds on the same port have ever been supported. Thanks, Stefano
