public inbox for netdev@vger.kernel.org
 help / color / mirror / Atom feed
From: Michal Soltys <soltys@ziu.info>
To: David Miller <davem@davemloft.net>
Cc: "Michal Soltys" <soltys@ziu.info>,
	"Maciej Żenczykowski" <zenczykowski@gmail.com>,
	"Jay Vosburgh" <jay.vosburgh@canonical.com>,
	"Vincent Bernat" <vincent@bernat.ch>,
	"Mahesh Bandewar" <maheshb@google.com>,
	"Chonggang Li" <chonggangli@google.com>,
	"Linux NetDev" <netdev@vger.kernel.org>
Subject: [PATCH v2] bonding: fix PACKET_ORIGDEV regression
Date: Mon, 18 Feb 2019 17:55:28 +0100	[thread overview]
Message-ID: <20190218165528.15575-1-soltys@ziu.info> (raw)
In-Reply-To: <CAHo-OoxoboVcn=MJj_XhaqeYkS_woGnuQ8vS9+BoDvdoae0YDA@mail.gmail.com>

This patch fixes a subtle PACKET_ORIGDEV regression which was a side
effect of fixes introduced by:

6a9e461f6fe4 bonding: pass link-local packets to bonding master also.

... to:

b89f04c61efe bonding: deliver link-local packets with skb->dev set to link that packets arrived on

While 6a9e461f6fe4 restored pre-b89f04c61efe presence of link-local
packets on bonding masters (which is required e.g. by linux bridges
participating in spanning tree or needed for lab-like setups created
with group_fwd_mask) it also caused the originating device
information to be lost due to cloning.

Maciej Żenczykowski proposed another solution that doesn't require
packet cloning and retains original device information - instead of
returning RX_HANDLER_PASS for all link-local packets it's now limited
only to packets from inactive slaves.

At the same time, packets passed to bonding masters retain correct
information about the originating device and PACKET_ORIGDEV can be used
to determine it.

This elegantly solves all issues so far:

- link-local packets that were removed from bonding masters
- LLDP daemons being forced to explicitly bind to slave interfaces
- PACKET_ORIGDEV having no effect on bond interfaces

Fixes: 6a9e461f6fe4 (bonding: pass link-local packets to bonding master also.)
Reported-by: Vincent Bernat <vincent@bernat.ch>
Signed-off-by: Michal Soltys <soltys@ziu.info>
---
 drivers/net/bonding/bond_main.c | 35 +++++++++++++--------------------
 1 file changed, 14 insertions(+), 21 deletions(-)

diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
index 485462d3087f..537c90c8eb0a 100644
--- a/drivers/net/bonding/bond_main.c
+++ b/drivers/net/bonding/bond_main.c
@@ -1183,29 +1183,22 @@ static rx_handler_result_t bond_handle_frame(struct sk_buff **pskb)
 		}
 	}
 
-	/* Link-local multicast packets should be passed to the
-	 * stack on the link they arrive as well as pass them to the
-	 * bond-master device. These packets are mostly usable when
-	 * stack receives it with the link on which they arrive
-	 * (e.g. LLDP) they also must be available on master. Some of
-	 * the use cases include (but are not limited to): LLDP agents
-	 * that must be able to operate both on enslaved interfaces as
-	 * well as on bonds themselves; linux bridges that must be able
-	 * to process/pass BPDUs from attached bonds when any kind of
-	 * STP version is enabled on the network.
+	/*
+	 * For packets determined by bond_should_deliver_exact_match() call to
+	 * be suppressed we want to make an exception for link-local packets.
+	 * This is necessary for e.g. LLDP daemons to be able to monitor
+	 * inactive slave links without being forced to bind to them
+	 * explicitly.
+	 *
+	 * At the same time, packets that are passed to the bonding master
+	 * (including link-local ones) can have their originating interface
+	 * determined via PACKET_ORIGDEV socket option.
 	 */
-	if (is_link_local_ether_addr(eth_hdr(skb)->h_dest)) {
-		struct sk_buff *nskb = skb_clone(skb, GFP_ATOMIC);
-
-		if (nskb) {
-			nskb->dev = bond->dev;
-			nskb->queue_mapping = 0;
-			netif_rx(nskb);
-		}
-		return RX_HANDLER_PASS;
-	}
-	if (bond_should_deliver_exact_match(skb, slave, bond))
+	if (bond_should_deliver_exact_match(skb, slave, bond)) {
+		if (is_link_local_ether_addr(eth_hdr(skb)->h_dest))
+			return RX_HANDLER_PASS;
 		return RX_HANDLER_EXACT;
+	}
 
 	skb->dev = bond->dev;
 
-- 
2.20.1


  reply	other threads:[~2019-02-18 16:56 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-07 16:29 [PATCH net 0/1] bonding: fix PACKET_ORIGDEV regression Michal Soltys
2019-01-07 16:29 ` [PATCH net 1/1] bonding: fix PACKET_ORIGDEV regression on bonding masters Michal Soltys
2019-01-07 17:12   ` David Miller
2019-01-08 13:46     ` Vincent Bernat
2019-01-13 23:03   ` David Miller
2019-01-14  2:01     ` Maciej Żenczykowski
2019-01-14  8:00       ` Vincent Bernat
2019-01-15  2:19         ` Mahesh Bandewar (महेश बंडेवार)
2019-01-16  2:58           ` Michal Soltys
2019-01-16  2:01       ` Michal Soltys
2019-01-18  0:27       ` Michal Soltys
2019-01-18  6:58         ` Maciej Żenczykowski
2019-01-29  1:47           ` Michal Soltys
2019-01-29  9:39             ` Maciej Żenczykowski
2019-02-18 16:55               ` Michal Soltys [this message]
2019-02-19  1:51                 ` [PATCH v2] bonding: fix PACKET_ORIGDEV regression David Ahern
2019-02-19  9:14                 ` Maciej Żenczykowski
2019-02-21 21:21                 ` David Miller

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190218165528.15575-1-soltys@ziu.info \
    --to=soltys@ziu.info \
    --cc=chonggangli@google.com \
    --cc=davem@davemloft.net \
    --cc=jay.vosburgh@canonical.com \
    --cc=maheshb@google.com \
    --cc=netdev@vger.kernel.org \
    --cc=vincent@bernat.ch \
    --cc=zenczykowski@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox