On Wed, Jul 10, 2024 at 11:36:56PM +0200, Stefano Brivio wrote:
> Some nits in the commit message only:
> 
> On Fri,  5 Jul 2024 12:07:20 +1000
> David Gibson <david@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

Revised accordingly.

-- 
David Gibson (he or they)	| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you, not the other way
				| around.
http://www.ozlabs.org/~dgibson