On Tue, Jun 25, 2013 at 09:45:31PM -0700, Greg KH wrote:
> On Tue, Jun 25, 2013 at 12:33:29PM -0700, Guenter Roeck wrote:
> > On Tue, Jun 25, 2013 at 12:25:26PM -0700, David Miller wrote:
> > > From: Guenter Roeck <linux@xxxxxxxxxxxx>
> > > Date: Tue, 25 Jun 2013 12:17:22 -0700
> > >
> > > > On Tue, Jun 25, 2013 at 12:07:40PM -0700, Greg Kroah-Hartman wrote:
> > > >> On Tue, Jun 25, 2013 at 11:42:46AM -0700, Guenter Roeck wrote:
> > > >> > On Tue, Jun 25, 2013 at 10:39:41AM -0700, Greg Kroah-Hartman wrote:
> > > >> > > On Tue, Jun 25, 2013 at 10:28:36AM -0700, Guenter Roeck wrote:
> > > >> > > > Hi Greg,
> > > >> > > >
> > > >> > > > your current (as of last night) stable patch queue for 3.4 generates
> > > >> > > > build errors for all but x86 platforms (at least all I tested).
> > > >> > > >
> > > >> > > > include/linux/etherdevice.h: In function 'ether_addr_equal_64bits':
> > > >> > > > include/linux/etherdevice.h:308:9: error: implicit declaration of function 'ether_addr_equal' [-Werror=implicit-function-declaration]
> > > >> > > >
> > > >> > > > Looks like this may be due to the folloing patch:
> > > >> > > > bonding-rlb-mode-of-bond-should-not-alter-arp-originating-via-bridge.patch
> > > >> > > >
> > > >> > > > [ Sorry if this is just noise for you. If so, please let me know. ]
> > > >> > >
> > > >> > > No, not noise at all for me. I just built this and I don't see this
> > > >> > > issue at all, can you send me the .config you used? I'm using an almost
> > > >> > > 'make allmodconfig', but tweaked in some ways to get it to actually boot
> > > >> > > on my boxes.
> > > >> > >
> > > >> > defconfig fails for arm, blackfin, m68k, mips, parisc, sparc, and xtensa.
> > > >> > x86 (both i386 and x86_64) build passes for all builds, and powerpc
> > > >> > defconfig passes (some builds fail for other reasons, but that is old).
> > > >> >
> > > >> > Let me know if any of those builds passes for you; if so, maybe something
> > > >> > is wrong in my build setup.
> > > >>
> > > >> I only test-build x86-64 here, and that's obviously passing. Perhaps we
> > > >> just need another .h file in etherdevice.h to pull in the proper
> > > >> declaration?
> > > >>
> > > > ether_addr_equal was introduced with commit a599b0f54 (etherdevice.h: Add
> > > > ether_addr_equal). I guess it does not exist in 3.4. Can you patch it in
> > > > or would that violate stable rules ?
> > >
> > > Can you at least look at the guilty bonding patch in question? It
> > > adds ether_addr_equal() to linux/etherdevice.h, specifically to deal
> > > with this issue.
> > >
> > Actually, I did. Maybe I am missing something, but the patch in Greg's
> > stable queue for 3.4, named
> > bonding-rlb-mode-of-bond-should-not-alter-arp-originating-via-bridge.patch
> > only adds ether_addr_equal_64bits(), not ether_addr_equal().
> > ether_addr_equal_64bits() in turn depends on ether_addr_equal()
> > if CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS is not defined.
>
> Ok, care to send me a fixed one?
>
Compile tested.
Guenter
---
>From 8f8cfb2ed5a5f6492c66e4eb56ef8360794948de Mon Sep 17 00:00:00 2001
From: Zheng Li <zheng.x.li@xxxxxxxxxx>
Date: Wed, 19 Jun 2013 00:53:47 -0700
Subject: [PATCH] bonding: rlb mode of bond should not alter ARP originating
via bridge
[ Upstream commit 567b871e503316b0927e54a3d7c86d50b722d955 ]
Do not modify or load balance ARP packets passing through balance-alb
mode (wherein the ARP did not originate locally, and arrived via a bridge).
Modifying pass-through ARP replies causes an incorrect MAC address
to be placed into the ARP packet, rendering peers unable to communicate
with the actual destination from which the ARP reply originated.
Load balancing pass-through ARP requests causes an entry to be
created for the peer in the rlb table, and bond_alb_monitor will
occasionally issue ARP updates to all peers in the table instrucing them
as to which MAC address they should communicate with; this occurs when
some event sets rx_ntt. In the bridged case, however, the MAC address
used for the update would be the MAC of the slave, not the actual source
MAC of the originating destination. This would render peers unable to
communicate with the destinations beyond the bridge.
Signed-off-by: Zheng Li <zheng.x.li@xxxxxxxxxx>
Signed-off-by: Jay Vosburgh <fubar@xxxxxxxxxx>
Signed-off-by: David S. Miller <davem@xxxxxxxxxxxxx>
Signed-off-by: Matthew O'Connor <liquidhorse@xxxxxxxxx>
Signed-off-by: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>
---
drivers/net/bonding/bond_alb.c | 6 ++++++
drivers/net/bonding/bonding.h | 13 +++++++++++++
2 files changed, 19 insertions(+)
diff --git a/drivers/net/bonding/bond_alb.c b/drivers/net/bonding/bond_alb.c
index 2e1f806..b6ed7e9 100644
--- a/drivers/net/bonding/bond_alb.c
+++ b/drivers/net/bonding/bond_alb.c
@@ -704,6 +704,12 @@ static struct slave *rlb_arp_xmit(struct sk_buff *skb, struct bonding *bond)
struct arp_pkt *arp = arp_pkt(skb);
struct slave *tx_slave = NULL;
+ /* Don't modify or load balance ARPs that do not originate locally
+ * (e.g.,arrive via a bridge).
+ */
+ if (!bond_slave_has_mac(bond, arp->mac_src))
+ return NULL;
+
if (arp->op_code == htons(ARPOP_REPLY)) {
/* the arp must be sent on the selected
* rx channel
diff --git a/drivers/net/bonding/bonding.h b/drivers/net/bonding/bonding.h
index 4581aa5..51f1766 100644
--- a/drivers/net/bonding/bonding.h
+++ b/drivers/net/bonding/bonding.h
@@ -18,6 +18,7 @@
#include <linux/timer.h>
#include <linux/proc_fs.h>
#include <linux/if_bonding.h>
+#include <linux/etherdevice.h>
#include <linux/cpumask.h>
#include <linux/in6.h>
#include <linux/netpoll.h>
@@ -450,6 +451,18 @@ static inline void bond_destroy_proc_dir(struct bond_net *bn)
}
#endif
+static inline struct slave *bond_slave_has_mac(struct bonding *bond,
+ const u8 *mac)
+{
+ int i = 0;
+ struct slave *tmp;
+
+ bond_for_each_slave(bond, tmp, i)
+ if (!compare_ether_addr_64bits(mac, tmp->dev->dev_addr))
+ return tmp;
+
+ return NULL;
+}
/* exported from bond_main.c */
extern int bond_net_id;
--
1.8.1.2
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html