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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <544357d4-1481-8563-323a-addf8b89d9e4@vyatta.att-mail.com>
Date:   Mon, 19 Oct 2020 13:04: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 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