On 6/1/20 5:20 PM, Stephen Rothwell wrote:
> Hi Dave,
>
> On Mon, 11 May 2020 13:00:15 +1000 Stephen Rothwell <sfr@xxxxxxxxxxxxxxxx> wrote:
>>
>> Today's linux-next merge of the ipsec-next tree got conflicts in:
>>
>> net/ipv4/xfrm4_output.c
>> net/ipv6/xfrm6_output.c
>>
>> between commit:
>>
>> 0c922a4850eb ("xfrm: Always set XFRM_TRANSFORMED in xfrm{4,6}_output_finish")
>>
>> from Linus' tree and commit:
>>
>> 2ab6096db2f1 ("xfrm: remove output_finish indirection from xfrm_state_afinfo")
>>
>> from the ipsec-next tree.
>>
>> I fixed it up (I used the latter versions of these files and then added
>> the following patch) 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.
>>
>> From: Stephen Rothwell <sfr@xxxxxxxxxxxxxxxx>
>> Date: Mon, 11 May 2020 12:57:24 +1000
>> Subject: [PATCH] xfrm: merge fixup for "remove output_finish indirection from xfrm_state_afinfo"
>>
>> Signed-off-by: Stephen Rothwell <sfr@xxxxxxxxxxxxxxxx>
>> ---
>> net/xfrm/xfrm_output.c | 4 ----
>> 1 file changed, 4 deletions(-)
>>
>> diff --git a/net/xfrm/xfrm_output.c b/net/xfrm/xfrm_output.c
>> index 886a9b284b3a..0f4b3a5e02ba 100644
>> --- a/net/xfrm/xfrm_output.c
>> +++ b/net/xfrm/xfrm_output.c
>> @@ -574,16 +574,12 @@ int xfrm_output(struct sock *sk, struct sk_buff *skb)
>> switch (x->outer_mode.family) {
>> case AF_INET:
>> memset(IPCB(skb), 0, sizeof(*IPCB(skb)));
>> -#ifdef CONFIG_NETFILTER
>> IPCB(skb)->flags |= IPSKB_XFRM_TRANSFORMED;
>> -#endif
>> break;
>> case AF_INET6:
>> memset(IP6CB(skb), 0, sizeof(*IP6CB(skb)));
>>
>> -#ifdef CONFIG_NETFILTER
>> IP6CB(skb)->flags |= IP6SKB_XFRM_TRANSFORMED;
>> -#endif
>> break;
>> }
>>
>
> It looks like this merge resolution fix up was missed when the
> ipsec-next tree was merged into the net-next tree.
>
Thanks for catching that, Stephen. Important fix in 0c922a4850eb.
