From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-8.3 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A,SIGNED_OFF_BY, SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id F07CDC433DF for ; Mon, 19 Oct 2020 12:25:45 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 9639C222BA for ; Mon, 19 Oct 2020 12:25:45 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727155AbgJSMZo (ORCPT ); Mon, 19 Oct 2020 08:25:44 -0400 Received: from mx0a-00191d01.pphosted.com ([67.231.149.140]:62176 "EHLO mx0a-00191d01.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726249AbgJSMZo (ORCPT ); Mon, 19 Oct 2020 08:25:44 -0400 X-Greylist: delayed 1232 seconds by postgrey-1.27 at vger.kernel.org; Mon, 19 Oct 2020 08:25:44 EDT Received: from pps.filterd (m0049297.ppops.net [127.0.0.1]) by m0049297.ppops.net-00191d01. (8.16.0.42/8.16.0.42) with SMTP id 09JCMMYZ006512; Mon, 19 Oct 2020 08:25:42 -0400 Received: from tlpd255.enaf.dadc.sbc.com (sbcsmtp3.sbc.com [144.160.112.28]) by m0049297.ppops.net-00191d01. with ESMTP id 3492uccrcf-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 19 Oct 2020 08:25:41 -0400 Received: from enaf.dadc.sbc.com (localhost [127.0.0.1]) by tlpd255.enaf.dadc.sbc.com (8.14.5/8.14.5) with ESMTP id 09JCPe8g082036; Mon, 19 Oct 2020 07:25:41 -0500 Received: from zlp30494.vci.att.com (zlp30494.vci.att.com [135.46.181.159]) by tlpd255.enaf.dadc.sbc.com (8.14.5/8.14.5) with ESMTP id 09JCPZVv081932 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 19 Oct 2020 07:25:35 -0500 Received: from zlp30494.vci.att.com (zlp30494.vci.att.com [127.0.0.1]) by zlp30494.vci.att.com (Service) with ESMTP id 1156B4005C32; Mon, 19 Oct 2020 12:25:35 +0000 (GMT) Received: from tlpd252.dadc.sbc.com (unknown [135.31.184.157]) by zlp30494.vci.att.com (Service) with ESMTP id F06454005C31; Mon, 19 Oct 2020 12:25:34 +0000 (GMT) Received: from dadc.sbc.com (localhost [127.0.0.1]) by tlpd252.dadc.sbc.com (8.14.5/8.14.5) with ESMTP id 09JCPYmL091809; Mon, 19 Oct 2020 07:25:34 -0500 Received: from mail.eng.vyatta.net (mail.eng.vyatta.net [10.156.50.82]) by tlpd252.dadc.sbc.com (8.14.5/8.14.5) with ESMTP id 09JCPSr6091409; Mon, 19 Oct 2020 07:25:28 -0500 Received: from [10.156.47.164] (unknown [10.156.47.164]) by mail.eng.vyatta.net (Postfix) with ESMTPA id AEF663601CE; Mon, 19 Oct 2020 05:24:27 -0700 (PDT) Reply-To: mmanning@vyatta.att-mail.com Subject: Re: Why revert commit 2271c95 ("vrf: mark skb for multicast or link-local as enslaved to VRF")? From: Mike Manning To: David Ahern , Stephen Suryaputra Cc: netdev@vger.kernel.org, sashal@kernel.org References: <20201018132436.GA11729@ICIPI.localdomain> <75fda8c7-adf3-06a4-298f-b75ac6e6969b@gmail.com> <20201018160624.GB11729@ICIPI.localdomain> <33c7f9b3-aec6-6327-53b3-3b54f74ddcf6@gmail.com> <544357d4-1481-8563-323a-addf8b89d9e4@vyatta.att-mail.com> Message-ID: Date: Mon, 19 Oct 2020 13:24:26 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: <544357d4-1481-8563-323a-addf8b89d9e4@vyatta.att-mail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235,18.0.687 definitions=2020-10-19_05:2020-10-16,2020-10-19 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 mlxlogscore=999 phishscore=0 priorityscore=1501 mlxscore=0 malwarescore=0 clxscore=1015 bulkscore=0 impostorscore=0 lowpriorityscore=0 adultscore=0 spamscore=0 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2010190090 Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org 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 >>> 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 >> 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.