litmus-rt.git/drivers/net/bonding, branch wip-default-clustering

bonding: fix WARN_ON when writing to bond_master sysfs file

2010-10-06T03:06:01+00:00

Fix a WARN_ON failure in bond_masters sysfs file

Got a report of this warning recently

bonding: bond0 is being created...
------------[ cut here ]------------
WARNING: at fs/proc/generic.c:590 proc_register+0x14d/0x185()
Hardware name: ProLiant BL465c G1
proc_dir_entry 'bonding/bond0' already registered
Modules linked in: bonding ipv6 tg3 bnx2 shpchp amd64_edac_mod edac_core
ipmi_si
ipmi_msghandler serio_raw i2c_piix4 k8temp edac_mce_amd hpwdt microcode hpsa
cc
iss radeon ttm drm_kms_helper drm i2c_algo_bit i2c_core [last unloaded:
scsi_wai
t_scan]
Pid: 935, comm: ifup-eth Not tainted 2.6.33.5-124.fc13.x86_64 #1
Call Trace:
[] warn_slowpath_common+0x77/0x8f
[] warn_slowpath_fmt+0x3c/0x3e
[] proc_register+0x14d/0x185
[] proc_create_data+0x87/0xa1
[] bond_create_proc_entry+0x55/0x95 [bonding]
[] bond_init+0x95/0xd0 [bonding]
[] register_netdevice+0xdd/0x29e
[] bond_create+0x8e/0xb8 [bonding]
[] bonding_store_bonds+0xb3/0x1c1 [bonding]
[] class_attr_store+0x27/0x29
[] sysfs_write_file+0x10f/0x14b
[] vfs_write+0xa9/0x106
[] sys_write+0x45/0x69
[] system_call_fastpath+0x16/0x1b
---[ end trace a677c3f7f8b16b1e ]---
bonding: Bond creation failed.

It happens because a user space writer to bond_master can try to
register an already existing bond interface name.  Fix it by teaching
bond_create to check for the existance of devices with that name first
in cases where a non-NULL name parameter has been passed in

Signed-off-by: Neil Horman 
Signed-off-by: David S. Miller

bonding: correctly process non-linear skbs

2010-09-14T21:25:32+00:00

It was recently brought to my attention that 802.3ad mode bonds would no
longer form when using some network hardware after a driver update.
After snooping around I realized that the particular hardware was using
page-based skbs and found that skb->data did not contain a valid LACPDU
as it was not stored there.  That explained the inability to form an
802.3ad-based bond.  For balance-alb mode bonds this was also an issue
as ARPs would not be properly processed.

This patch fixes the issue in my tests and should be applied to 2.6.36
and as far back as anyone cares to add it to stable.

Thanks to Alexander Duyck  and Jesse
Brandeburg  for the suggestions on this one.

Signed-off-by: Andy Gospodarek 
CC: Alexander Duyck 
CC: Jesse Brandeburg 
CC: stable@kerne.org
Signed-off-by: Jay Vosburgh 
Signed-off-by: David S. Miller

bonding: Fix jiffies overflow problems (again)

2010-09-07T20:57:20+00:00

The time_before_eq()/time_after_eq() functions operate on unsigned
long and only work if the difference between the two compared values
is smaller than half the range of unsigned long (31 bits on i386).

Some of the variables (slave->jiffies, dev->trans_start, dev->last_rx)
used by bonding store a copy of jiffies and may not be updated for a
long time. With HZ=1000, time_before_eq()/time_after_eq() will start
giving bad results after ~25 days.

jiffies will never be before slave->jiffies, dev->trans_start,
dev->last_rx by more than possibly a couple ticks caused by preemption
of this code. This allows us to detect/prevent these overflows by
replacing time_before_eq()/time_after_eq() with time_in_range().

Signed-off-by: Jiri Bohac 
Signed-off-by: Jean Delvare 
Signed-off-by: David S. Miller

bonding: prevent sysfs from allowing arp monitoring with alb/tlb

2010-07-31T06:27:57+00:00

When using module options arp monitoring and balance-alb/balance-tlb
are mutually exclusive options.  Anytime balance-alb/balance-tlb are
enabled mii monitoring is forced to 100ms if not set.  When configuring
via sysfs no checking is currently done.

Handling these cases with sysfs has to be done a bit differently because
we do not have all configuration information available at once.  This
patch will not allow a mode change to balance-alb/balance-tlb if
arp_interval is already non-zero.  It will also not allow the user to
set a non-zero arp_interval value if the mode is already set to
balance-alb/balance-tlb.  They are still mutually exclusive on a
first-come, first serve basis.

Tested with initscripts on Fedora and manual setting via sysfs.

Signed-off-by: Andy Gospodarek 
Signed-off-by: Jay Vosburgh 
Signed-off-by: David S. Miller

Merge branch 'master' of master.kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6

2010-07-28T04:01:35+00:00

Conflicts:
	drivers/net/bnx2x_main.c

Merge bnx2x bug fixes in by hand... :-/

Signed-off-by: David S. Miller

bonding: set device in RLB ARP packet handler

2010-07-25T03:37:48+00:00

After:

commit 6146b1a4da98377e4abddc91ba5856bef8f23f1e
Author: Jay Vosburgh 
Date:   Tue Nov 4 17:51:15 2008 -0800

    bonding: Fix ALB mode to balance traffic on VLANs

the dev field in the RLB ARP packet handler was set to NULL to wildcard
and accommodate balancing VLANs on top of bonds.

This has the side-effect of the packet handler being called against
other, non RLB-enabled bonds, and a kernel oops results when it tries to
dereference rx_hashtbl in rlb_update_entry_from_arp(), which won't be
set for those bonds, e.g. active-backup.

With the __netif_receive_skb() changes from:

commit 1f3c8804acba841b5573b953f5560d2683d2db0d
Author: Andy Gospodarek 
Date:   Mon Dec 14 10:48:58 2009 +0000

    bonding: allow arp_ip_targets on separate vlans to use arp validation

frames received on VLANs correctly make their way to the bond's handler,
so we no longer need to wildcard the device.

The oops can be reproduced by:

modprobe bonding

echo active-backup > /sys/class/net/bond0/bonding/mode
echo 100 > /sys/class/net/bond0/bonding/miimon
ifconfig bond0 xxx.xxx.xxx.xxx netmask xxx.xxx.xxx.xxx
echo +eth0 > /sys/class/net/bond0/bonding/slaves
echo +eth1 > /sys/class/net/bond0/bonding/slaves

echo +bond1 > /sys/class/net/bonding_masters
echo balance-alb > /sys/class/net/bond1/bonding/mode
echo 100 > /sys/class/net/bond1/bonding/miimon
ifconfig bond1 xxx.xxx.xxx.xxx netmask xxx.xxx.xxx.xxx
echo +eth2 > /sys/class/net/bond1/bonding/slaves
echo +eth3 > /sys/class/net/bond1/bonding/slaves

Pass some traffic on bond0.  Boom.

[ Tested, behaves as advertised.  I do not believe a test of the bonding
mode is necessary, as there is no race between the packet handler and
the bonding mode changing (the mode can only change when the device is
closed).  Also updated the log message to include the reproduction and
full commit ids.  -J ]

Signed-off-by: Greg Edwards 
Signed-off-by: Jay Vosburgh 
Acked-by: Andy Gospodarek 
Signed-off-by: David S. Miller

bonding: don't lock when copying/clearing VLAN list on slave

2010-07-22T21:14:47+00:00

When copying VLAN information to or removing from a slave
during slave addition or removal, the bonding code currently holds
the bond->lock for write to prevent concurrent modification of the
vlan_list / vlgrp.

	This is unnecessary, as all of these operations occur under
RTNL.  Holding the bond->lock also caused might_sleep issues for
some drivers' ndo_vlan_* functions.  This patch removes the extra
locking.

	Problem reported by Michael Chan 

Signed-off-by: Jay Vosburgh 
Cc: Michael Chan 
Signed-off-by: David S. Miller

bonding: change test for presence of VLANs

2010-07-22T21:14:46+00:00

After commit ad1afb00393915a51c21b1ae8704562bf036855f
("vlan_dev: VLAN 0 should be treated as "no vlan tag" (802.1p packet)")
it is now regular practice for a VLAN "add vid" for VLAN 0 to
arrive prior to any VLAN registration or creation of a vlan_group.

	This patch updates the bonding code that tests for the presence
of VLANs configured above bonding.  The new logic tests for bond->vlgrp
to determine if a registration has occured, instead of testing that
bonding's internal vlan_list is empty.

	The old code would panic when vlan_list was not empty, but
vlgrp was still NULL (because only an "add vid" for VLAN 0 had occured).

	Bonding still adds VLAN 0 to its internal list so that 802.1p
frames are handled correctly on transmit when non-VLAN accelerated
slaves are members of the bond.  The test against bond->vlan_list
remains in bond_dev_queue_xmit for this reason.

	Modification to the bond->vlgrp now occurs under lock (in
addition to RTNL), because not all inspections of it occur under RTNL.

	Additionally, because 8021q will never issue a "kill vid" for
VLAN 0, there is now logic in bond_uninit to release any remaining
entries from vlan_list.

Signed-off-by: Jay Vosburgh 
Cc: Pedro Garcia 
Cc: Patrick McHardy 
Signed-off-by: David S. Miller

bonding: avoid a warning

2010-07-19T20:34:16+00:00

drivers/net/bonding/bond_main.c:179:12: warning: ‘disable_netpoll’
defined but not used

Signed-off-by: Eric Dumazet 
Signed-off-by: David S. Miller

bonding: fix bond_inet6addr_event()

2010-07-19T16:34:31+00:00

After commit ad1afb0039391 (vlan_dev: VLAN 0 should be treated
as "no vlan tag" (802.1p packet)),
bond_inet6addr_event() might be called with a NULL bond->vlgrp pointer, and
a non empty bond->vlan_list. vlan_group_get_device() is dereferencing a NULL pointer.

Signed-off-by: Eric Dumazet 
Signed-off-by: David S. Miller