On Wed, Feb 05, 2025 at 01:39:04AM +0100, Stefano Brivio wrote:
> This implements flow preparation on the source, transfer of data with
> a format roughly inspired by struct tcp_tap_conn, and flow insertion
> on the target, with all the appropriate window options, window
> scaling, MSS, etc.
> 
> The target side is rather convoluted because we first need to create
> sockets and switch them to repair mode, before we can apply options
> that are *not* stored in the flow table. However, we don't want to
> request repair mode for sockets one by one. So we need to do this in
> several steps.
> 
> A hack in order to connect() on the "RARP" message should be easy to
> enable, I left a couple of comments in that sense.
> 
> This is very much draft quality, but I tested the whole flow, and it
> works for me. Window parameters and MSS match, too.
> 
> Signed-off-by: Stefano Brivio <sbrivio@redhat.com>

[snip]
> diff --git a/isolation.c b/isolation.c
> index c944fb3..df58bb8 100644
> --- a/isolation.c
> +++ b/isolation.c
> @@ -377,7 +377,7 @@ void isolate_postfork(const struct ctx *c)
>  {
>  	struct sock_fprog prog;
>  
> -	prctl(PR_SET_DUMPABLE, 0);
> +//	prctl(PR_SET_DUMPABLE, 0);

Looks like a stray debugging change made it in here.  Fwiw, I keep a
branch around with debugging hacks including exactly this.  To make it
harder to accidentally leak debug hacks into "real" series, I usually
rebase between my debugging branch and main.

In this case it conflicted with the patch from my debugging branch, of
course, which is why I spotted it.


>  
>  	switch (c->mode) {
>  	case MODE_PASST:

-- 
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