[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <m2sffw17ti.fsf@ja.int.chopps.org>
Date: Fri, 27 Jan 2023 07:22:40 -0500
From: Christian Hopps <chopps@...pps.org>
To: Herbert Xu <herbert@...dor.apana.org.au>
Cc: Christian Hopps <chopps@...pps.org>,
Steffen Klassert <steffen.klassert@...unet.com>,
"David S. Miller" <davem@...emloft.net>, devel@...ux-ipsec.org,
Eric Dumazet <edumazet@...gle.com>,
Jakub Kicinski <kuba@...nel.org>,
Paolo Abeni <pabeni@...hat.com>, netdev@...r.kernel.org,
chopps@...n.net
Subject: Re: [PATCH ipsec-next v2] xfrm: fix bug with DSCP copy to v6 from
v4 tunnel
Herbert Xu <herbert@...dor.apana.org.au> writes:
> On Thu, Jan 26, 2023 at 11:33:50AM -0500, Christian Hopps wrote:
>> When copying the DSCP bits for decap-dscp into IPv6 don't assume the
>> outer encap is always IPv6. Instead, as with the inner IPv4 case, copy
>> the DSCP bits from the correctly saved "tos" value in the control block.
>>
>> Fixes: 227620e29509 ("[IPSEC]: Separate inner/outer mode processing on input")
>
> Please fix this Fixes header as that commit did not introduce
> this bug.
This was a suggested add from Eyal that I was initially hesitant to add. He justified it b/c this commit purported to add support for mixed versions and this is a bug in that new functionality. It is useful to have that tracked which is why I added it. Is there a better way to track that?
Thanks,
Chris.
Powered by blists - more mailing lists