From patchwork Wed Feb 13 19:51:02 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Zahari Doychev X-Patchwork-Id: 1041552 X-Patchwork-Delegate: davem@davemloft.net Return-Path: X-Original-To: patchwork-incoming-netdev@ozlabs.org Delivered-To: patchwork-incoming-netdev@ozlabs.org Authentication-Results: ozlabs.org; spf=none (mailfrom) smtp.mailfrom=vger.kernel.org (client-ip=209.132.180.67; helo=vger.kernel.org; envelope-from=netdev-owner@vger.kernel.org; receiver=) Authentication-Results: ozlabs.org; dmarc=none (p=none dis=none) header.from=linux.com Authentication-Results: ozlabs.org; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=googlemail.com header.i=@googlemail.com header.b="kMIieJdZ"; dkim-atps=neutral Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id 4409BG5zxFz9s7h for ; Thu, 14 Feb 2019 06:51:02 +1100 (AEDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1733249AbfBMTvB (ORCPT ); Wed, 13 Feb 2019 14:51:01 -0500 Received: from mail-ed1-f66.google.com ([209.85.208.66]:37124 "EHLO mail-ed1-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726362AbfBMTvA (ORCPT ); Wed, 13 Feb 2019 14:51:00 -0500 Received: by mail-ed1-f66.google.com with SMTP id m12so3012944edv.4 for ; Wed, 13 Feb 2019 11:50:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20161025; h=sender:from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=dp8fY7I/cUA9YKTm7Z0PYvdeVxhrHcb6x1m2fe9cmWU=; b=kMIieJdZas8PCq8eulzcYfD0E/uIyfFy2JEisZ0dwhXMrCxHdWRLN87IzEETAOmyA/ kit3xFHWHVeQGjPQHvR4OKl3jN2Kx0jHiJmRa2qofUhlpVVpskyAtHcpzOrAzmZ9+WhO 1PPXMXVImJNuUqmDP72fEDNQh7Ks1qwUlQVKSgw5xPPIvVu8aKIEvlWafT7lphYIjLIx AlzRjNGEhNwqlXwp+XD23ssJX1Va6YMetD9P+IznMjETUXfYuSH94QLwKS1cUGEhIUpE 8qwFJYTjxwpdglvsKzp2UrWvg86w2hN8BfvpDPAH+QQIyxjSbNHB/2IcPMRtjiUYTOBk DBhg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:to:cc:subject:date:message-id :mime-version:content-transfer-encoding; bh=dp8fY7I/cUA9YKTm7Z0PYvdeVxhrHcb6x1m2fe9cmWU=; b=tWZABczkwyiyHYWL6dx5ORstIsXzhX2aqLQ4ChLjjPFa29P1o5h4tPQ1mVak6T0usF pftmdwSPDk/Ivwdg9/kGF2SSCNfTWlSpx5LGCAFNpPF0W92r8lofMv73/1zSHYSoSoMc x75xsyyW6PsLb9O05WMP31uPmCg8XEZLuLgyqY4Tj482mRlQStOTMdk3CIQmAy0PeBND rdiiiimbHaUCuvYF8Ya6FQRM1c2LlxjryM3YSD6WM7AJJyaIrj4GVxXGAbnX7ZXYaADM 8jp1w/l9HHv9nm5LQKn3iprTZIVcrWQfIHTqJm/m58NXKk/FbEALRVXmvcDO6SGVoqPz 7/1A== X-Gm-Message-State: AHQUAuaYe+MqVNun9NZFUJICMVHK75dfaG0pycN1WZiK9JpC51TOumzx hWKEum6EiC4lLe1U8s6CyR+e8YsHlOI= X-Google-Smtp-Source: AHgI3Ibft2pCgBdI18xmRBL9o34LH+Ru8GXUWZ0cFGvoRUUbl4Bub7BgXLRA9pe0jg0YUKke3bJLug== X-Received: by 2002:a17:906:f43:: with SMTP id h3mr1553828ejj.179.1550087458573; Wed, 13 Feb 2019 11:50:58 -0800 (PST) Received: from tycho.fritz.box ([2a02:810d:1500:e01:ba85:84ff:febf:2b17]) by smtp.gmail.com with ESMTPSA id v20sm54762edm.29.2019.02.13.11.50.57 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 13 Feb 2019 11:50:57 -0800 (PST) From: Zahari Doychev To: netdev@vger.kernel.org, bridge@lists.linux-foundation.org, makita.toshiaki@lab.ntt.co.jp, nikolay@cumulusnetworks.com, roopa@cumulusnetworks.com, jhs@mojatatu.com, jiri@resnulli.us, xiyou.wangcong@gmail.com Cc: johannes@sipsolutions.net, zahari.doychev@linux.com Subject: [RFC PATCH] net act_vlan: use correct len in skb_pull Date: Wed, 13 Feb 2019 20:51:02 +0100 Message-Id: <20190213195102.1917-1-zahari.doychev@linux.com> X-Mailer: git-send-email 2.20.1 MIME-Version: 1.0 Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org The bridge and VLAN code expects that skb->data points to the start of the VLAN header instead of the next (network) header. Currently after tcf_vlan_act() on ingress filter skb->data points to the next network header. In this case the Linux bridge does not forward correctly double tagged VLAN packets added using tc vlan action as the outer vlan tag from the skb is inserted at the wrong offset after the vlan tag in the payload. Making skb->data to point to the VLAN header in tcf_vlan_act() by using ETH_HLEN in skb_pull_rcsum() fixes the problem. The following commands were used for testing: ip link add name br0 type bridge vlan_filtering 1 ip link set dev br0 up ip link set dev net0 up ip link set dev net0 master br0 ip link set dev net1 up ip link set dev net1 master br0 bridge vlan add dev net0 vid 100 master bridge vlan add dev br0 vid 100 self bridge vlan add dev net1 vid 100 master tc qdisc add dev net0 handle ffff: clsact tc qdisc add dev net1 handle ffff: clsact tc filter add dev net0 ingress pref 1 protocol all flower \ action vlan push id 10 pipe action vlan push id 100 tc filter add dev net0 egress pref 1 protocol 802.1q flower \ vlan_id 100 vlan_ethtype 802.1q cvlan_id 10 \ action vlan pop pipe action vlan pop Signed-off-by: Zahari Doychev --- net/sched/act_vlan.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/net/sched/act_vlan.c b/net/sched/act_vlan.c index 93fdaf707313..308d7d89f925 100644 --- a/net/sched/act_vlan.c +++ b/net/sched/act_vlan.c @@ -86,7 +86,7 @@ static int tcf_vlan_act(struct sk_buff *skb, const struct tc_action *a, out: if (skb_at_tc_ingress(skb)) - skb_pull_rcsum(skb, skb->mac_len); + skb_pull_rcsum(skb, ETH_HLEN); return action;