linux-next: manual merge of the net-next tree with the netfilter tree

Posted by Mark Brown 2 months, 1 week ago

Hi all,

Today's linux-next merge of the net-next tree got a conflict in:

  net/ipv6/seg6_iptunnel.c

between commit:

  c3812651b522f ("seg6: separate dst_cache for input and output paths in seg6 lwtunnel")

from the netfilter tree and commit:

  78723a62b969a ("seg6: add per-route tunnel source address")

from the net-next tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

diff --cc net/ipv6/seg6_iptunnel.c
index d6a0f7df90807,e76cc0cc481ec..0000000000000
--- a/net/ipv6/seg6_iptunnel.c
+++ b/net/ipv6/seg6_iptunnel.c
@@@ -48,8 -48,8 +48,9 @@@ static size_t seg6_lwt_headroom(struct 
  }
  
  struct seg6_lwt {
 -	struct dst_cache cache;
 +	struct dst_cache cache_input;
 +	struct dst_cache cache_output;
+ 	struct in6_addr tunsrc;
  	struct seg6_iptunnel_encap tuninfo[];
  };

Re: linux-next: manual merge of the net-next tree with the netfilter tree

Posted by Mark Brown 2 months, 1 week ago

On Wed, Apr 08, 2026 at 03:10:10PM +0100, Mark Brown wrote:
> Hi all,
> 
> Today's linux-next merge of the net-next tree got a conflict in:
> 
>   net/ipv6/seg6_iptunnel.c
> 
> between commit:
> 
>   c3812651b522f ("seg6: separate dst_cache for input and output paths in seg6 lwtunnel")
> 
> from the netfilter tree and commit:
> 
>   78723a62b969a ("seg6: add per-route tunnel source address")
> 
> from the net-next tree.
> 
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging.  You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
> 
> diff --cc net/ipv6/seg6_iptunnel.c
> index d6a0f7df90807,e76cc0cc481ec..0000000000000
> --- a/net/ipv6/seg6_iptunnel.c
> +++ b/net/ipv6/seg6_iptunnel.c
> @@@ -48,8 -48,8 +48,9 @@@ static size_t seg6_lwt_headroom(struct 
>   }
>   
>   struct seg6_lwt {
>  -	struct dst_cache cache;
>  +	struct dst_cache cache_input;
>  +	struct dst_cache cache_output;
> + 	struct in6_addr tunsrc;
>   	struct seg6_iptunnel_encap tuninfo[];
>   };
>   

This also needs a fixup for a new jump to the error handling paths that
was added in seg6_build_state().

Re: linux-next: manual merge of the net-next tree with the netfilter tree

Posted by Matthieu Baerts 2 months, 1 week ago

Hello,

On 08/04/2026 17:08, Mark Brown wrote:
> On Wed, Apr 08, 2026 at 03:10:10PM +0100, Mark Brown wrote:
>> Hi all,
>>
>> Today's linux-next merge of the net-next tree got a conflict in:
>>
>>   net/ipv6/seg6_iptunnel.c
>>
>> between commit:
>>
>>   c3812651b522f ("seg6: separate dst_cache for input and output paths in seg6 lwtunnel")
>>
>> from the netfilter tree and commit:
>>
>>   78723a62b969a ("seg6: add per-route tunnel source address")
>>
>> from the net-next tree.
>>
>> I fixed it up (see below) and can carry the fix as necessary. This
>> is now fixed as far as linux-next is concerned, but any non trivial
>> conflicts should be mentioned to your upstream maintainer when your tree
>> is submitted for merging.  You may also want to consider cooperating
>> with the maintainer of the conflicting tree to minimise any particularly
>> complex conflicts.

Thank you for having fixed the conflict on linux-next!

>> diff --cc net/ipv6/seg6_iptunnel.c
>> index d6a0f7df90807,e76cc0cc481ec..0000000000000
>> --- a/net/ipv6/seg6_iptunnel.c
>> +++ b/net/ipv6/seg6_iptunnel.c
>> @@@ -48,8 -48,8 +48,9 @@@ static size_t seg6_lwt_headroom(struct 
>>   }
>>   
>>   struct seg6_lwt {
>>  -	struct dst_cache cache;
>>  +	struct dst_cache cache_input;
>>  +	struct dst_cache cache_output;
>> + 	struct in6_addr tunsrc;
>>   	struct seg6_iptunnel_encap tuninfo[];
>>   };
>>   
> 
> This also needs a fixup for a new jump to the error handling paths that
> was added in seg6_build_state().

I also had this other conflict there, and I did this when resolving it
in MPTCP tree:

--------------------- 8< ---------------------
diff --cc net/ipv6/seg6_iptunnel.c
index e76cc0cc481e,d6a0f7df9080..97b50d9b1365
--- a/net/ipv6/seg6_iptunnel.c
+++ b/net/ipv6/seg6_iptunnel.c
@@@ -48,8 -48,8 +48,9 @@@ static size_t seg6_lwt_headroom(struct 
  }
  
  struct seg6_lwt {
- 	struct dst_cache cache;
+ 	struct dst_cache cache_input;
+ 	struct dst_cache cache_output;
 +	struct in6_addr tunsrc;
  	struct seg6_iptunnel_encap tuninfo[];
  };
  
@@@ -726,18 -712,6 +731,18 @@@ static int seg6_build_state(struct net 
  
  	memcpy(&slwt->tuninfo, tuninfo, tuninfo_len);
  
 +	if (tb[SEG6_IPTUNNEL_SRC]) {
 +		slwt->tunsrc = nla_get_in6_addr(tb[SEG6_IPTUNNEL_SRC]);
 +
 +		if (ipv6_addr_any(&slwt->tunsrc) ||
 +		    ipv6_addr_is_multicast(&slwt->tunsrc) ||
 +		    ipv6_addr_loopback(&slwt->tunsrc)) {
 +			NL_SET_ERR_MSG(extack, "invalid tunsrc address");
 +			err = -EINVAL;
- 			goto free_dst_cache;
++			goto err_destroy_output;
 +		}
 +	}
 +
  	newts->type = LWTUNNEL_ENCAP_SEG6;
  	newts->flags |= LWTUNNEL_STATE_INPUT_REDIRECT;
  
@@@ -750,9 -724,9 +755,11 @@@
  
  	return 0;
  
- free_dst_cache:
- 	dst_cache_destroy(&slwt->cache);
- free_lwt_state:
++err_destroy_output:
++	dst_cache_destroy(&slwt->cache_output);
+ err_destroy_input:
+ 	dst_cache_destroy(&slwt->cache_input);
+ err_free_newts:
  	kfree(newts);
  	return err;
  }
--------------------- 8< ---------------------

I took the liberty to add the err_destroy_output label, similar to the
new err_destroy_input one.

Just in case, rerere cache file is available there:

 https://github.com/multipath-tcp/mptcp-upstream-rr-cache/commit/dbb6675

Cheers,
Matt
-- 
Sponsored by the NGI0 Core fund.

Re: linux-next: manual merge of the net-next tree with the netfilter tree

Posted by Mark Brown 2 months, 1 week ago

On Wed, Apr 08, 2026 at 06:43:36PM +0200, Matthieu Baerts wrote:
> On 08/04/2026 17:08, Mark Brown wrote:

> > This also needs a fixup for a new jump to the error handling paths that
> > was added in seg6_build_state().

> I also had this other conflict there, and I did this when resolving it
> in MPTCP tree:

>  +	if (tb[SEG6_IPTUNNEL_SRC]) {
>  +		slwt->tunsrc = nla_get_in6_addr(tb[SEG6_IPTUNNEL_SRC]);
>  +
>  +		if (ipv6_addr_any(&slwt->tunsrc) ||
>  +		    ipv6_addr_is_multicast(&slwt->tunsrc) ||
>  +		    ipv6_addr_loopback(&slwt->tunsrc)) {
>  +			NL_SET_ERR_MSG(extack, "invalid tunsrc address");
>  +			err = -EINVAL;
> - 			goto free_dst_cache;
> ++			goto err_destroy_output;
>  +		}
>  +	}
>  +

Yes, that's the additional fixup I mentioned above - it didn't conflict
for me (well, the exit path did).

Re: linux-next: manual merge of the net-next tree with the netfilter tree

Posted by Andrea Mayer 2 months, 1 week ago

On Wed, 8 Apr 2026 18:00:50 +0100
Mark Brown <broonie@kernel.org> wrote:

> On Wed, Apr 08, 2026 at 06:43:36PM +0200, Matthieu Baerts wrote:
> > On 08/04/2026 17:08, Mark Brown wrote:
> 
> > > This also needs a fixup for a new jump to the error handling paths that
> > > was added in seg6_build_state().
> 
> > I also had this other conflict there, and I did this when resolving it
> > in MPTCP tree:
> 
> >  +	if (tb[SEG6_IPTUNNEL_SRC]) {
> >  +		slwt->tunsrc = nla_get_in6_addr(tb[SEG6_IPTUNNEL_SRC]);
> >  +
> >  +		if (ipv6_addr_any(&slwt->tunsrc) ||
> >  +		    ipv6_addr_is_multicast(&slwt->tunsrc) ||
> >  +		    ipv6_addr_loopback(&slwt->tunsrc)) {
> >  +			NL_SET_ERR_MSG(extack, "invalid tunsrc address");
> >  +			err = -EINVAL;
> > - 			goto free_dst_cache;
> > ++			goto err_destroy_output;
> >  +		}
> >  +	}
> >  +
> 
> Yes, that's the additional fixup I mentioned above - it didn't conflict
> for me (well, the exit path did).

Thanks Mark and Matthieu for taking care of this.

I went through both commits and the rerere.
The resolution looks correct from the seg6 side. Build-tested.

Happy to help if anything else comes up.

Cheers,
Andrea