Skip to content
  1. Oct 19, 2011
    • John Fastabend's avatar
      net: allow vlan traffic to be received under bond · 2425717b
      John Fastabend authored 
      

The following configuration used to work as I expected. At least
we could use the fcoe interfaces to do MPIO and the bond0 iface
to do load balancing or failover.

       ---eth2.228-fcoe
       |
eth2 -----|
          |
          |---- bond0
          |
eth3 -----|
       |
       ---eth3.228-fcoe

This worked because of a change we added to allow inactive slaves
to rx 'exact' matches. This functionality was kept intact with the
rx_handler mechanism. However now the vlan interface attached to the
active slave never receives traffic because the bonding rx_handler
updates the skb->dev and goto's another_round. Previously, the
vlan_do_receive() logic was called before the bonding rx_handler.

Now by the time vlan_do_receive calls vlan_find_dev() the
skb->dev is set to bond0 and it is clear no vlan is attached
to this iface. The vlan lookup fails.

This patch moves the VLAN check above the rx_handler. A VLAN
tagged frame is now routed to the eth2.228-fcoe iface in the
above schematic. Untagged frames continue to the bond0 as
normal. This case also remains intact,

eth2 --> bond0 --> vlan.228

Here the skb is VLAN tagged but the vlan lookup fails on eth2
causing the bonding rx_handler to be called. On the second
pass the vlan lookup is on the bond0 iface and completes as
expected.

Putting a VLAN.228 on both the bond0 and eth2 device will
result in eth2.228 receiving the skb. I don't think this is
completely unexpected and was the result prior to the rx_handler
result.

Note, the same setup is also used for other storage traffic that
MPIO is used with eg. iSCSI and similar setups can be contrived
without storage protocols.

Signed-off-by: default avatarJohn Fastabend <john.r.fastabend@intel.com>
Acked-by: default avatarJesse Gross <jesse@nicira.com>
Reviewed-by: default avatarJiri Pirko <jpirko@redhat.com>
Tested-by: default avatarHans Schillstrom <hams.schillstrom@ericsson.com>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      2425717b
    • Jeff Kirsher's avatar
      cs89x0: Move the driver into the Cirrus dir · b340a207
      Jeff Kirsher authored 
      

The cs89x0 driver was initial placed in the apple/ when it
should have been placed in the cirrus/.  This resolves the
issue by moving the dirver and fixing up the respective
Kconfig(s) and Makefile(s).

Thanks to Sascha for reporting the issue.

-v2 Fix a config error that was introduced with v1 by removing
    the dependency on MACE for NET_VENDOR_APPLE.

CC: Russell Nelson <nelson@crynwr.com>
CC: Andrew Morton <akpm@linux-foundation.org>
Reported-by: default avatarSascha Hauer <s.hauer@pengutronix.de>
Signed-off-by: default avatarJeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      b340a207
    • Eric Dumazet's avatar
      l2tp: give proper headroom in pppol2tp_xmit() · 09df57ca
      Eric Dumazet authored 
      

pppol2tp_xmit() calls skb_cow_head(skb, 2) before calling
l2tp_xmit_skb()

Then l2tp_xmit_skb() calls again skb_cow_head(skb, large_headroom)

This patchs changes the first skb_cow_head() call to supply the needed
headroom to make sure at most one (expensive) pskb_expand_head() is
done.

Signed-off-by: default avatarEric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      09df57ca
    • Eric Dumazet's avatar
      macvlan: handle fragmented multicast frames · bc416d97
      Eric Dumazet authored 
      

Fragmented multicast frames are delivered to a single macvlan port,
because ip defrag logic considers other samples are redundant.

Implement a defrag step before trying to send the multicast frame.

Reported-by: default avatarBen Greear <greearb@candelatech.com>
Signed-off-by: default avatarEric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      bc416d97
  3. Oct 18, 2011
  5. Oct 17, 2011
  7. Oct 16, 2011
    • Bruce Allan's avatar
      e1000e: locking bug introduced by commit 67fd4fcb · a90b412c
      Bruce Allan authored 
      Commit 67fd4fcb

 (e1000e: convert to stats64) added the ability to update
statistics more accurately and on-demand through the net_device_ops
.ndo_get_stats64 hook, but introduced a locking bug on 82577/8/9 when
linked at half-duplex (seen on kernels with CONFIG_DEBUG_ATOMIC_SLEEP=y and
CONFIG_PROVE_LOCKING=y).  The commit introduced code paths that caused a
mutex to be locked in atomic contexts, e.g. an rcu_read_lock is held when
irqbalance reads the stats from /sys/class/net/ethX/statistics causing the
mutex to be locked to read the Phy half-duplex statistics registers.

The mutex was originally introduced to prevent concurrent accesses of
resources (the NVM and Phy) shared by the driver, firmware and hardware
a few years back when there was an issue with the NVM getting corrupted.
It was later split into two mutexes - one for the NVM and one for the Phy
when it was determined the NVM, unlike the Phy, should not be protected by
the software/firmware/hardware semaphore (arbitration of which is done in
part with the SWFLAG bit in the EXTCNF_CTRL register).  This latter
semaphore should be sufficient to prevent resource contention of the Phy in
the driver (i.e. the mutex for Phy accesses is not needed), but to be sure
the mutex is replaced with an atomic bit flag which will warn if any
contention is possible.

Also add additional debug output to help determine when the sw/fw/hw
semaphore is owned by the firmware or hardware.

Signed-off-by: default avatarBruce Allan <bruce.w.allan@intel.com>
Reported-by: default avatarFrancois Romieu <romieu@fr.zoreil.com>
Tested-by: default avatarJeff Pieper <jeffrey.e.pieper@intel.com>
      a90b412c
  9. Oct 15, 2011