From patchwork Fri Aug 5 19:19:03 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Matthias May X-Patchwork-Id: 12937663 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id EAB1EC282E7 for ; Fri, 5 Aug 2022 19:24:09 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S241416AbiHETYH (ORCPT ); Fri, 5 Aug 2022 15:24:07 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39828 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S241316AbiHETYD (ORCPT ); Fri, 5 Aug 2022 15:24:03 -0400 Received: from mx07-0057a101.pphosted.com (mx07-0057a101.pphosted.com [205.220.184.10]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 8DA986612E; Fri, 5 Aug 2022 12:24:01 -0700 (PDT) Received: from pps.filterd (m0214197.ppops.net [127.0.0.1]) by mx07-0057a101.pphosted.com (8.17.1.5/8.17.1.5) with ESMTP id 275JCsRd016655; Fri, 5 Aug 2022 21:20:12 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=westermo.com; h=from : to : cc : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type; s=12052020; bh=OpFHzG1kl6wCe+/tAFHSweb+0GXtByAYdqY1N4yQX8g=; b=iVcpuJi3uZCdKrMqeLXNMxFHoWDGbBBCOhp2BuNBxmFmemCtBAK/y0Neq+hPorl6pEEm Ncq7t/W4l0BOlcV+KrRjnlFpvboLBpv7xFD3boS1BJGAtK72VRG6c+v1HRX/viME3OXT s5X44qdhLVSbvoMP+Jepqi7jmFGnoG40dpOzboPBFoVjxjN/xL+XpV4+8soYyp6JoQfc 5k0xoI68iuzpZqIor/nd6e0hIhlaV5nMhLEP2lAio4qx4oX2vANzaNFOAO1ByIwpmvTV vDdPgcDt2+7t5Fbpb0ilEmOUvoy7uqEbU+Ta583+5by1wU0bgbZtUa3P6knx5Uuk3fhg nQ== Received: from mail.beijerelectronics.com ([195.67.87.131]) by mx07-0057a101.pphosted.com (PPS) with ESMTPS id 3hr3tdsntk-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Fri, 05 Aug 2022 21:20:12 +0200 Received: from Orpheus.nch.westermo.com (172.29.100.2) by EX01GLOBAL.beijerelectronics.com (10.101.10.25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.2375.17; Fri, 5 Aug 2022 21:20:09 +0200 From: Matthias May To: CC: , , , , , , , , , , , , , , , , , , , , , , , , , , , , , Matthias May Subject: [PATCH v3 net 1/4] geneve: do not use RT_TOS for IPv6 flowlabel Date: Fri, 5 Aug 2022 21:19:03 +0200 Message-ID: <20220805191906.9323-2-matthias.may@westermo.com> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220805191906.9323-1-matthias.may@westermo.com> References: <20220805191906.9323-1-matthias.may@westermo.com> MIME-Version: 1.0 X-Originating-IP: [172.29.100.2] X-ClientProxiedBy: wsevst-s0023.westermo.com (192.168.130.120) To EX01GLOBAL.beijerelectronics.com (10.101.10.25) X-Proofpoint-GUID: goU3PmD8isX_P2PEqIj0xuXGqowA7BiQ X-Proofpoint-ORIG-GUID: goU3PmD8isX_P2PEqIj0xuXGqowA7BiQ Precedence: bulk List-ID: X-Mailing-List: linux-rdma@vger.kernel.org According to Guillaume Nault RT_TOS should never be used for IPv6. Quote: RT_TOS() is an old macro used to interprete IPv4 TOS as described in the obsolete RFC 1349. It's conceptually wrong to use it even in IPv4 code, although, given the current state of the code, most of the existing calls have no consequence. But using RT_TOS() in IPv6 code is always a bug: IPv6 never had a "TOS" field to be interpreted the RFC 1349 way. There's no historical compatibility to worry about. Fixes: 3a56f86f1be6 ("geneve: handle ipv6 priority like ipv4 tos") Acked-by: Guillaume Nault Signed-off-by: Matthias May --- v1 -> v2: - Fix spacing of "Fixes" tag. - Add missing CCs v2 -> v3: - Add the info from the cover to the actual patch message (Guillaume Nault) - Correct length of fixes-tag from 13 to 12 characters (Guillaume Nault) --- drivers/net/geneve.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/net/geneve.c b/drivers/net/geneve.c index 4c380c06f178..e1a4480e6f17 100644 --- a/drivers/net/geneve.c +++ b/drivers/net/geneve.c @@ -877,8 +877,7 @@ static struct dst_entry *geneve_get_v6_dst(struct sk_buff *skb, use_cache = false; } - fl6->flowlabel = ip6_make_flowinfo(RT_TOS(prio), - info->key.label); + fl6->flowlabel = ip6_make_flowinfo(prio, info->key.label); dst_cache = (struct dst_cache *)&info->dst_cache; if (use_cache) { dst = dst_cache_get_ip6(dst_cache, &fl6->saddr); From patchwork Fri Aug 5 19:19:04 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Matthias May X-Patchwork-Id: 12937661 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 5AF8DC25B07 for ; Fri, 5 Aug 2022 19:24:06 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S241369AbiHETYE (ORCPT ); Fri, 5 Aug 2022 15:24:04 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39822 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S241113AbiHETYC (ORCPT ); Fri, 5 Aug 2022 15:24:02 -0400 Received: from mx07-0057a101.pphosted.com (mx07-0057a101.pphosted.com [205.220.184.10]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 333466AA00; Fri, 5 Aug 2022 12:24:00 -0700 (PDT) Received: from pps.filterd (m0214197.ppops.net [127.0.0.1]) by mx07-0057a101.pphosted.com (8.17.1.5/8.17.1.5) with ESMTP id 275IwDco020717; Fri, 5 Aug 2022 21:20:15 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=westermo.com; h=from : to : cc : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type; s=12052020; bh=KNwb78g0eGkKfY8cM6IPLc3keEhAD6R+o+WDqMnC85A=; b=b61DjV+T2JSYRV4vf7giWIByrmz94NxQ0YOsh2jYdfmBaFTGUNuX2KKdDFWbCoq/zrkU CFpD/ms0JWrJQDqCZU5ZIgHyaw3K+ZqCbqvuZaRxCDWO/DDMe+K1GUKrMBYBkmBNyw8u ebGaFqAbk0WQ9DYaQB1pLtTfqfPJOZGw3MatgcWBDKNoZGEEuyL7zbKY1SSes5bgmDzQ 9kPHu0cwxbTvb56mG23l7mUTpx3aA7MGzW1jUKLo+um91dOEX051hUnnuwRQ1BfdGtZD Oulf2fY+sghkjAPFE6/zDLGkPebgKHPFF9dHaGyvWlnXw149PtOC7UjiTjzvvYxkT0sV pQ== Received: from mail.beijerelectronics.com ([195.67.87.131]) by mx07-0057a101.pphosted.com (PPS) with ESMTPS id 3hr3tdsntn-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Fri, 05 Aug 2022 21:20:15 +0200 Received: from Orpheus.nch.westermo.com (172.29.100.2) by EX01GLOBAL.beijerelectronics.com (10.101.10.25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.2375.17; Fri, 5 Aug 2022 21:20:12 +0200 From: Matthias May To: CC: , , , , , , , , , , , , , , , , , , , , , , , , , , , , , Matthias May Subject: [PATCH v3 net 2/4] vxlan: do not use RT_TOS for IPv6 flowlabel Date: Fri, 5 Aug 2022 21:19:04 +0200 Message-ID: <20220805191906.9323-3-matthias.may@westermo.com> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220805191906.9323-1-matthias.may@westermo.com> References: <20220805191906.9323-1-matthias.may@westermo.com> MIME-Version: 1.0 X-Originating-IP: [172.29.100.2] X-ClientProxiedBy: wsevst-s0023.westermo.com (192.168.130.120) To EX01GLOBAL.beijerelectronics.com (10.101.10.25) X-Proofpoint-GUID: t4-9ggl_BGKV-pPZ8OBnhmlGUtXOnoC2 X-Proofpoint-ORIG-GUID: t4-9ggl_BGKV-pPZ8OBnhmlGUtXOnoC2 Precedence: bulk List-ID: X-Mailing-List: linux-rdma@vger.kernel.org According to Guillaume Nault RT_TOS should never be used for IPv6. Quote: RT_TOS() is an old macro used to interprete IPv4 TOS as described in the obsolete RFC 1349. It's conceptually wrong to use it even in IPv4 code, although, given the current state of the code, most of the existing calls have no consequence. But using RT_TOS() in IPv6 code is always a bug: IPv6 never had a "TOS" field to be interpreted the RFC 1349 way. There's no historical compatibility to worry about. Fixes: 1400615d64cf ("vxlan: allow setting ipv6 traffic class") Acked-by: Guillaume Nault Signed-off-by: Matthias May --- v1 -> v2: - Fix spacing of "Fixes" tag. - Add missing CCs v2 -> v3: - Add the info from the cover to the actual patch message (Guillaume Nault) --- drivers/net/vxlan/vxlan_core.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/vxlan/vxlan_core.c b/drivers/net/vxlan/vxlan_core.c index 265d4a0245e7..797585fbb004 100644 --- a/drivers/net/vxlan/vxlan_core.c +++ b/drivers/net/vxlan/vxlan_core.c @@ -2320,7 +2320,7 @@ static struct dst_entry *vxlan6_get_route(struct vxlan_dev *vxlan, fl6.flowi6_oif = oif; fl6.daddr = *daddr; fl6.saddr = *saddr; - fl6.flowlabel = ip6_make_flowinfo(RT_TOS(tos), label); + fl6.flowlabel = ip6_make_flowinfo(tos, label); fl6.flowi6_mark = skb->mark; fl6.flowi6_proto = IPPROTO_UDP; fl6.fl6_dport = dport; From patchwork Fri Aug 5 19:19:05 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Matthias May X-Patchwork-Id: 12937662 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id E1113C00140 for ; Fri, 5 Aug 2022 19:24:08 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231262AbiHETYG (ORCPT ); Fri, 5 Aug 2022 15:24:06 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39824 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S241310AbiHETYD (ORCPT ); Fri, 5 Aug 2022 15:24:03 -0400 Received: from mx07-0057a101.pphosted.com (mx07-0057a101.pphosted.com [205.220.184.10]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 332046717E; Fri, 5 Aug 2022 12:24:00 -0700 (PDT) Received: from pps.filterd (m0214197.ppops.net [127.0.0.1]) by mx07-0057a101.pphosted.com (8.17.1.5/8.17.1.5) with ESMTP id 275JBPjX015217; Fri, 5 Aug 2022 21:20:18 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=westermo.com; h=from : to : cc : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type; s=12052020; bh=qUVyOM8ZbJXuR7I4XxQ00/jzZhstTj0MGA/CSTUhe14=; b=upI0D1oMNdFTOjDaOZ1WQunJvSdcne9R+uvN3JW48aTCIJsSRTW4Juga2Iu8DB1+NCbX RrJ5ugp4ENG/6kbSa9mrbtrf3cD9O+1168//t12IJNlztERmjgzgSxAglsgpz+d73+Za Iyn62Tjqc7WyyLs8mC5uXkGedvGgAQExvnH6mXVAopSJsFSkVg8d7O3Gm3fXQKZi0RyC oeROANXeRQDH1lyf4FlA+SDayZyGkLJtomDyufrkpWbqIjo/gNxBKytlURixN+MIwVuK g+1KORFaOkO2tx8xvoFUXMJAJQDNlSDBbnR45QlS7i+YrWd7GVs1Nn6kfCNlswEosiXo 3w== Received: from mail.beijerelectronics.com ([195.67.87.131]) by mx07-0057a101.pphosted.com (PPS) with ESMTPS id 3hr3tdsntp-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Fri, 05 Aug 2022 21:20:18 +0200 Received: from Orpheus.nch.westermo.com (172.29.100.2) by EX01GLOBAL.beijerelectronics.com (10.101.10.25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.2375.17; Fri, 5 Aug 2022 21:20:15 +0200 From: Matthias May To: CC: , , , , , , , , , , , , , , , , , , , , , , , , , , , , , Matthias May Subject: [PATCH v3 net 3/4] mlx5: do not use RT_TOS for IPv6 flowlabel Date: Fri, 5 Aug 2022 21:19:05 +0200 Message-ID: <20220805191906.9323-4-matthias.may@westermo.com> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220805191906.9323-1-matthias.may@westermo.com> References: <20220805191906.9323-1-matthias.may@westermo.com> MIME-Version: 1.0 X-Originating-IP: [172.29.100.2] X-ClientProxiedBy: wsevst-s0023.westermo.com (192.168.130.120) To EX01GLOBAL.beijerelectronics.com (10.101.10.25) X-Proofpoint-GUID: C9xbPar2GVj89GpUD_VoSA0oODIXM_hl X-Proofpoint-ORIG-GUID: C9xbPar2GVj89GpUD_VoSA0oODIXM_hl Precedence: bulk List-ID: X-Mailing-List: linux-rdma@vger.kernel.org According to Guillaume Nault RT_TOS should never be used for IPv6. Quote: RT_TOS() is an old macro used to interprete IPv4 TOS as described in the obsolete RFC 1349. It's conceptually wrong to use it even in IPv4 code, although, given the current state of the code, most of the existing calls have no consequence. But using RT_TOS() in IPv6 code is always a bug: IPv6 never had a "TOS" field to be interpreted the RFC 1349 way. There's no historical compatibility to worry about. Fixes: ce99f6b97fcd ("net/mlx5e: Support SRIOV TC encapsulation offloads for IPv6 tunnels") Acked-by: Guillaume Nault Signed-off-by: Matthias May --- v1 -> v2: - Fix spacing of "Fixes" tag. - Add missing CCs v2 -> v3: - Add the info from the cover to the actual patch message (Guillaume Nault) --- drivers/net/ethernet/mellanox/mlx5/core/en/tc_tun.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en/tc_tun.c b/drivers/net/ethernet/mellanox/mlx5/core/en/tc_tun.c index d87bbb0be7c8..e6f64d890fb3 100644 --- a/drivers/net/ethernet/mellanox/mlx5/core/en/tc_tun.c +++ b/drivers/net/ethernet/mellanox/mlx5/core/en/tc_tun.c @@ -506,7 +506,7 @@ int mlx5e_tc_tun_create_header_ipv6(struct mlx5e_priv *priv, int err; attr.ttl = tun_key->ttl; - attr.fl.fl6.flowlabel = ip6_make_flowinfo(RT_TOS(tun_key->tos), tun_key->label); + attr.fl.fl6.flowlabel = ip6_make_flowinfo(tun_key->tos, tun_key->label); attr.fl.fl6.daddr = tun_key->u.ipv6.dst; attr.fl.fl6.saddr = tun_key->u.ipv6.src; @@ -620,7 +620,7 @@ int mlx5e_tc_tun_update_header_ipv6(struct mlx5e_priv *priv, attr.ttl = tun_key->ttl; - attr.fl.fl6.flowlabel = ip6_make_flowinfo(RT_TOS(tun_key->tos), tun_key->label); + attr.fl.fl6.flowlabel = ip6_make_flowinfo(tun_key->tos, tun_key->label); attr.fl.fl6.daddr = tun_key->u.ipv6.dst; attr.fl.fl6.saddr = tun_key->u.ipv6.src; From patchwork Fri Aug 5 19:19:06 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Matthias May X-Patchwork-Id: 12937664 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 63985C25B07 for ; Fri, 5 Aug 2022 19:24:17 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S241303AbiHETYP (ORCPT ); Fri, 5 Aug 2022 15:24:15 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39934 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S241403AbiHETYH (ORCPT ); Fri, 5 Aug 2022 15:24:07 -0400 Received: from mx07-0057a101.pphosted.com (mx07-0057a101.pphosted.com [205.220.184.10]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id DBE6E6C118; Fri, 5 Aug 2022 12:24:05 -0700 (PDT) Received: from pps.filterd (m0214197.ppops.net [127.0.0.1]) by mx07-0057a101.pphosted.com (8.17.1.5/8.17.1.5) with ESMTP id 275Iw8pG020710; Fri, 5 Aug 2022 21:20:21 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=westermo.com; h=from : to : cc : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding : content-type; s=12052020; bh=NUqbJUEx5UEXY6K354sFjqPsxJuZMGKzADVaOWSqG+w=; b=4mlBd9c7zprNCj1pdF4xxLSa1XoT+DD3nlZ7If0G6naAVumv/PUr++kGu8lMYj2myyTX VSBDwp/buPCtEJ+v9f4ISPNR5Cpf/nFe0V+2F/SZsxfFzmX5Ck0AukhGrhNnUT+ZRtSt qCZX+hMZkOWq18cf7Ug3cGwu4Idz9tm93kgyBmw5p6TZMOVU5Mbh2QFeJ1+y2qvnz+xl vkuOPokfb2dVYfuUbE14VEE/MWjIJrRoWn/ednf/s4sMAiolhgMfy5yd1l4yTV+BAs6H 8DkVL5rFPO/gd0ISEbLfOYlIf/4svwDRPzGAZI34dsjWN/oWeUfzi4i4IIasKHLXO6Pe rg== Received: from mail.beijerelectronics.com ([195.67.87.131]) by mx07-0057a101.pphosted.com (PPS) with ESMTPS id 3hr3tdsntq-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Fri, 05 Aug 2022 21:20:21 +0200 Received: from Orpheus.nch.westermo.com (172.29.100.2) by EX01GLOBAL.beijerelectronics.com (10.101.10.25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.2375.17; Fri, 5 Aug 2022 21:20:18 +0200 From: Matthias May To: CC: , , , , , , , , , , , , , , , , , , , , , , , , , , , , , Matthias May Subject: [PATCH v3 net 4/4] ipv6: do not use RT_TOS for IPv6 flowlabel Date: Fri, 5 Aug 2022 21:19:06 +0200 Message-ID: <20220805191906.9323-5-matthias.may@westermo.com> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220805191906.9323-1-matthias.may@westermo.com> References: <20220805191906.9323-1-matthias.may@westermo.com> MIME-Version: 1.0 X-Originating-IP: [172.29.100.2] X-ClientProxiedBy: wsevst-s0023.westermo.com (192.168.130.120) To EX01GLOBAL.beijerelectronics.com (10.101.10.25) X-Proofpoint-GUID: U0umUy_MebB7pvhyoL7Q9LZEirAB7eaC X-Proofpoint-ORIG-GUID: U0umUy_MebB7pvhyoL7Q9LZEirAB7eaC Precedence: bulk List-ID: X-Mailing-List: linux-rdma@vger.kernel.org According to Guillaume Nault RT_TOS should never be used for IPv6. Quote: RT_TOS() is an old macro used to interprete IPv4 TOS as described in the obsolete RFC 1349. It's conceptually wrong to use it even in IPv4 code, although, given the current state of the code, most of the existing calls have no consequence. But using RT_TOS() in IPv6 code is always a bug: IPv6 never had a "TOS" field to be interpreted the RFC 1349 way. There's no historical compatibility to worry about. Fixes: 571912c69f0e ("net: UDP tunnel encapsulation module for tunnelling different protocols like MPLS, IP, NSH etc.") Acked-by: Guillaume Nault Signed-off-by: Matthias May --- v1 -> v2: - Fix spacing of "Fixes" tag. - Add missing CCs v2 -> v3: - Add the info from the cover to the actual patch message (Guillaume Nault) --- net/ipv6/ip6_output.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/net/ipv6/ip6_output.c b/net/ipv6/ip6_output.c index 77e3f5970ce4..ec62f472aa1c 100644 --- a/net/ipv6/ip6_output.c +++ b/net/ipv6/ip6_output.c @@ -1311,8 +1311,7 @@ struct dst_entry *ip6_dst_lookup_tunnel(struct sk_buff *skb, fl6.daddr = info->key.u.ipv6.dst; fl6.saddr = info->key.u.ipv6.src; prio = info->key.tos; - fl6.flowlabel = ip6_make_flowinfo(RT_TOS(prio), - info->key.label); + fl6.flowlabel = ip6_make_flowinfo(prio, info->key.label); dst = ipv6_stub->ipv6_dst_lookup_flow(net, sock->sk, &fl6, NULL);