netdev - Re: Why revert commit 2271c95 ("vrf: mark skb for multicast or link-local as enslaved to VRF")?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <b407b5d0-13cd-a506-24dc-1d705f55275d@vyatta.att-mail.com>
Date:   Mon, 19 Oct 2020 13:24:26 +0100
From:   Mike Manning <mmanning@...tta.att-mail.com>
To:     David Ahern <dsahern@...il.com>,
        Stephen Suryaputra <ssuryaextr@...il.com>
Cc:     netdev@...r.kernel.org, sashal@...nel.org
Subject: Re: Why revert commit 2271c95 ("vrf: mark skb for multicast or
 link-local as enslaved to VRF")?

On 19/10/2020 13:04, Mike Manning wrote:
> On 19/10/2020 02:53, David Ahern wrote:
>> On 10/18/20 10:06 AM, Stephen Suryaputra wrote:
>>> $ git --no-pager show afed1a4
>>>
>>> commit afed1a4dbb76c81900f10fd77397fb91ad442702
>>> Author: Sasha Levin <sashal@...nel.org>
>>> Date:   Mon Mar 23 16:21:31 2020 -0400
>>>
>>>     Revert "vrf: mark skb for multicast or link-local as enslaved to VRF"
>>>     
>>>     This reverts commit 2271c9500434af2a26b2c9eadeb3c0b075409fb5.
>>>     
>>>     This patch shouldn't have been backported to 4.14.
>>>     
>>>     Signed-off-by: Sasha Levin <sashal@...nel.org>
>>>
>> My response last November was:
>>
>> 'backporting this patch and it's bug fix, "ipv6: Fix handling of LLA
>> with VRF and sockets bound to VRF" to 4.14 is a bit questionable. They
>> definitely do not need to come back to 4.9.'
>>
>> Basically, my point is that this is work that was committed to 4.19-next
>> I believe and given the state of the VRF feature over the releases, I
>> could not confirm for 4.14 that everything works as intended. Hence, the
>> comment about it being questionable.
>>
>> If you / your company are actively using and testing VRF on 4.14 and can
>> confirm it works, then I am fine with the patch (and its bugfix) getting
>> applied.
> Hi,
>
> This fix is part of a series "vrf: allow simultaneous service instances
> in default and other VRFs" that is present in 5.x kernels and should not
> be used in isolation.
>
> But it was at a later stage erroneously backported as a standalone fix
> (without the rest of the series) to 4.14 and 4.19.
>
> So it was reverted from these kernels, especially as it was causing this
> regression:
>
> VRF: All router multicast entry(FF02:2) not added to VRF Dev but added
> on VLAN Dev
>
> Sorry for any inconvenience.
>
> Thanks, Mike
>
>
>
To clarify, the regression in 4.14 only occurred when the commit was
used in isolation, not when applied with the rest of the series.

It may be worth mentioning that we had been extensively using the series
in our local fork with 4.14 & 4.19 kernels before proceeding with
submitting the series and then switching to 5.x kernel, so that may be
an approach you can take.