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  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]
Date:   Sun, 18 Oct 2020 19:53:42 -0600
From:   David Ahern <>
To:     Stephen Suryaputra <>
Subject: Re: Why revert commit 2271c95 ("vrf: mark skb for multicast or
 link-local as enslaved to VRF")?

On 10/18/20 10:06 AM, Stephen Suryaputra wrote:
> $ git --no-pager show afed1a4
> commit afed1a4dbb76c81900f10fd77397fb91ad442702
> Author: Sasha Levin <>
> 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 <>

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

Powered by blists - more mailing lists