Some nits in the commit message only:
On Fri, 5 Jul 2024 12:07:20 +1000
David Gibson <david(a)gibson.dropbear.id.au> wrote:
Currently we create flows for datagrams from
socket interfaces, and use
them to direct "spliced" (socket to socket) datagrams. We don't yet
match datagrams from the tap interface to existing flows, nor create new
flows for them. Add that functionality, matching datagrams from tap to
existing flows when they exist, or creating new ones.
As with spliced flows, when creating a new flow from tap to socket, we
create a new connected socket to receive reply datagrams attached to that
flow specifically. We extend udp_flow_sock_handler() to handle reply
packets bound for tap rather than another socket.
For non-obvious reasons, this caused a failure for me when running under
valgrind, because valgrind invoked rt_sigreturn which is not in our
seccomp filter.
That might be because the stack area needed by udp_reply_sock_handler()
is now a bit bigger... or something like that, I suppose.
Since we already allow rt_signaction and others
in the
rt_sigaction
valgrind, it seems reasonable to add rt_sigreturn
as well.
valgrind target