I'm not a BIRD developer, so I cannot decide hare what is the right direction for you to implement the patch. But it seems to me that it is the question that should be raised. As for implementation, I'm not sure, but from a quick glance at a code, it seem that vrf binding might be moved from sk_setup somewhere else.
On Sat, Jul 27, 2024 at 2:18 PM Christian Svensson <[email protected]> wrote: > > Hi Alexander, > > On Sat, Jul 27, 2024 at 2:05 PM Alexander Zubkov <[email protected]> wrote: > > I wonder if it is necessary at all to set a vrf on an accepted connection? > > It seems to me that setting or checking vrf should be avoided instead for > > an accepted connection. What do you think? > > Indeed, this is what I set out to do in the beginning and is, if you > boil this patch down, the actual implication when using VRFs. > > The reason I chose to implement the patch as a get+set rather than a > conditional set was that the existing code structure assumes that > sk_setup is called on multiple types of sockets and I wasn't sure > exactly how to guard for specifically sockets that are connected. > In addition I tried to find a reference in the kernel to where exactly > it inherits the bound interface when a new socket is created from > accept() but I could not. It is evident from my experiments that it is > inherited, and that is the only way accept() on a VRF bind() would > make sense. > Doing a get+set seems like the least risky change that I felt safe to propose. > > That said, if you believe it is better implemented as a conditional > and are able to nudge me how you'd want a check for the particular > socket type to look, I'd be happy to do a v2 patch. > > Regards,
