09 Dec, 2011

2 commits


05 Nov, 2011

1 commit

  • When implementing VRRP v2 using macvlan several problems were
    discovered. VRRP is weird in that all routers participating
    in a redundant group use the same virtual MAC address.
    Macvlan is a natural driver to use for this but it doesn't
    work. The problem is that packets with a macvlan device's
    source address are not received.

    The problem is actually a regression that date back almost 2 years now.
    The original problems started with:

    commit 618e1b7482f7a8a4c6c6e8ccbe140e4c331df4e9
    Author: Arnd Bergmann
    Date: Thu Nov 26 06:07:10 2009 +0000

    macvlan: implement bridge, VEPA and private mode

    This patches restores the original 2.6.32 behavior. Allowing multicast
    packets received with the VRRP source address to be received.

    Signed-off-by: Stephen Hemminger
    Signed-off-by: David S. Miller

    stephen hemminger
     

19 Oct, 2011

1 commit

  • 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: Ben Greear
    Signed-off-by: Eric Dumazet
    Signed-off-by: David S. Miller

    Eric Dumazet
     

08 Oct, 2011

1 commit


05 Oct, 2011

1 commit


16 Sep, 2011

1 commit

  • This patch does several things:
    - introduces __ethtool_get_settings which is called from ethtool code and
    from drivers as well. Put ASSERT_RTNL there.
    - dev_ethtool_get_settings() is replaced by __ethtool_get_settings()
    - changes calling in drivers so rtnl locking is respected. In
    iboe_get_rate was previously ->get_settings() called unlocked. This
    fixes it. Also prb_calc_retire_blk_tmo() in af_packet.c had the same
    problem. Also fixed by calling __dev_get_by_index() instead of
    dev_get_by_index() and holding rtnl_lock for both calls.
    - introduces rtnl_lock in bnx2fc_vport_create() and fcoe_vport_create()
    so bnx2fc_if_create() and fcoe_if_create() are called locked as they
    are from other places.
    - use __ethtool_get_settings() in bonding code

    Signed-off-by: Jiri Pirko

    v2->v3:
    -removed dev_ethtool_get_settings()
    -added ASSERT_RTNL into __ethtool_get_settings()
    -prb_calc_retire_blk_tmo - use __dev_get_by_index() and lock
    around it and __ethtool_get_settings() call
    v1->v2:
    add missing export_symbol
    Reviewed-by: Ben Hutchings [except FCoE bits]
    Acked-by: Ralf Baechle
    Signed-off-by: David S. Miller

    Jiri Pirko
     

18 Aug, 2011

1 commit


28 Jul, 2011

1 commit

  • After the last patch, We are left in a state in which only drivers calling
    ether_setup have IFF_TX_SKB_SHARING set (we assume that drivers touching real
    hardware call ether_setup for their net_devices and don't hold any state in
    their skbs. There are a handful of drivers that violate this assumption of
    course, and need to be fixed up. This patch identifies those drivers, and marks
    them as not being able to support the safe transmission of skbs by clearning the
    IFF_TX_SKB_SHARING flag in priv_flags

    Signed-off-by: Neil Horman
    CC: Karsten Keil
    CC: "David S. Miller"
    CC: Jay Vosburgh
    CC: Andy Gospodarek
    CC: Patrick McHardy
    CC: Krzysztof Halasa
    CC: "John W. Linville"
    CC: Greg Kroah-Hartman
    CC: Marcel Holtmann
    CC: Johannes Berg
    Signed-off-by: David S. Miller

    Neil Horman
     

22 Jul, 2011

1 commit


07 Jun, 2011

1 commit


23 May, 2011

1 commit


21 May, 2011

2 commits

  • * git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next-2.6: (1446 commits)
    macvlan: fix panic if lowerdev in a bond
    tg3: Add braces around 5906 workaround.
    tg3: Fix NETIF_F_LOOPBACK error
    macvlan: remove one synchronize_rcu() call
    networking: NET_CLS_ROUTE4 depends on INET
    irda: Fix error propagation in ircomm_lmp_connect_response()
    irda: Kill set but unused variable 'bytes' in irlan_check_command_param()
    irda: Kill set but unused variable 'clen' in ircomm_connect_indication()
    rxrpc: Fix set but unused variable 'usage' in rxrpc_get_transport()
    be2net: Kill set but unused variable 'req' in lancer_fw_download()
    irda: Kill set but unused vars 'saddr' and 'daddr' in irlan_provider_connect_indication()
    atl1c: atl1c_resume() is only used when CONFIG_PM_SLEEP is defined.
    rxrpc: Fix set but unused variable 'usage' in rxrpc_get_peer().
    rxrpc: Kill set but unused variable 'local' in rxrpc_UDP_error_handler()
    rxrpc: Kill set but unused variable 'sp' in rxrpc_process_connection()
    rxrpc: Kill set but unused variable 'sp' in rxrpc_rotate_tx_window()
    pkt_sched: Kill set but unused variable 'protocol' in tc_classify()
    isdn: capi: Use pr_debug() instead of ifdefs.
    tg3: Update version to 3.119
    tg3: Apply rx_discards fix to 5719/5720
    ...

    Fix up trivial conflicts in arch/x86/Kconfig and net/mac80211/agg-tx.c
    as per Davem.

    Linus Torvalds
     
  • commit a35e2c1b6d905 (macvlan: use rx_handler_data pointer to store
    macvlan_port pointer V2) added a bug in macvlan_port_create()

    Steps to reproduce the bug:

    # ifenslave bond0 eth0 eth1

    # ip link add link eth0 up name eth0#1 type macvlan
    ->error EBUSY

    # ip link add link eth0 up name eth0#1 type macvlan
    ->panic

    Fix: Dont set IFF_MACVLAN_PORT in error case.

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

    Eric Dumazet
     

20 May, 2011

1 commit

  • When one macvlan device is dismantled, we can avoid one
    synchronize_rcu() call done after deletion from hash list, since caller
    will perform a synchronize_net() call after its ndo_stop() call.

    Add a new netdev->dismantle field to signal this dismantle intent.

    Reduces RTNL hold time.

    Signed-off-by: Eric Dumazet
    CC: Patrick McHardy
    CC: Ben Greear
    Signed-off-by: David S. Miller

    Eric Dumazet
     

10 May, 2011

1 commit

  • veth devices dont use the batched device unregisters yet.

    Since veth are a pair of devices, it makes sense to use a batch of two
    unregisters, this roughly divides dismantle time by two.

    Fix this by changing dellink() callers to always provide a non NULL
    head. (Idea from Michał Mirosław)

    This patch also handles macvlan case : We now dismantle all macvlans on
    top of a lower dev at once.

    Reported-by: Alex Bligh
    Signed-off-by: Eric Dumazet
    Cc: Michał Mirosław
    Cc: Jesse Gross
    Cc: Paul E. McKenney
    Cc: Ben Greear
    Signed-off-by: David S. Miller

    Eric Dumazet
     

08 May, 2011

1 commit


18 Apr, 2011

1 commit


22 Mar, 2011

1 commit

  • When the macvlan driver was extended to call unregisgter_netdevice_queue
    in 23289a37e2b127dfc4de1313fba15bb4c9f0cd5b, a use after free of struct
    macvlan_port was introduced. The code in dellink relied on unregister_netdevice
    actually unregistering the net device so it would be safe to free macvlan_port.

    Since unregister_netdevice_queue can just queue up the unregister instead of
    performing the unregiser immediately we free the macvlan_port too soon and
    then the code in macvlan_stop removes the macaddress for the set of macaddress
    to listen for and uses memory that has already been freed.

    To fix this add a reference count to track when it is safe to free the macvlan_port
    and move the call of macvlan_port_destroy into macvlan_uninit which is guaranteed
    to be called after the final macvlan_port_close.

    Signed-off-by: Eric W. Biederman
    Signed-off-by: David S. Miller

    Eric W. Biederman
     

17 Mar, 2011

1 commit


15 Mar, 2011

1 commit

  • When the lower device has offloading capabilities, the packets checksums
    are not computed. That leads to have any macvlan port in bridge mode to
    not work because the packets are dropped due to a bad checksum.

    If the macvlan is in bridge mode, the packet is forwarded to another
    macvlan port and reach the network stack where it looks for a checksum
    but this one was not computed due to the offloading of the lower device.
    In this case, we have to set the packet with CHECKSUM_UNNECESSARY
    when it is forwarded to a bridged port and restore the previous value of
    ip_summed when the packet goes to the lowerdev.

    Signed-off-by: Daniel Lezcano
    Cc: Patrick McHardy
    Cc: Andrian Nord
    Acked-by: Eric Dumazet
    Signed-off-by: David S. Miller

    Daniel Lezcano
     

23 Nov, 2010

1 commit

  • With the current default 'vepa' mode, a KVM guest using virtio with
    macvtap backend has the following limitations.
    - cannot change/add a mac address on the guest virtio-net
    - cannot create a vlan device on the guest virtio-net
    - cannot enable promiscuous mode on guest virtio-net

    To address these limitations, this patch introduces a new mode called
    'passthru' when creating a macvlan device which allows takeover of the
    underlying device and passing it to a guest using virtio with macvtap
    backend.

    Only one macvlan device is allowed in passthru mode and it inherits
    the mac address from the underlying device and sets it in promiscuous
    mode to receive and forward all the packets.

    Signed-off-by: Sridhar Samudrala

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

    Sridhar Samudrala
     

17 Nov, 2010

1 commit

  • macvlan is a stacked device, like tunnels. We should use the lockless
    mechanism we are using in tunnels and loopback.

    This patch completely removes locking in TX path.

    tx stat counters are added into existing percpu stat structure, renamed
    from rx_stats to pcpu_stats.

    Note : this reverts commit 2c11455321f37 (macvlan: add multiqueue
    capability)

    Note : rx_errors converted to a 32bit counter, like tx_dropped, since
    they dont need 64bit range.

    Signed-off-by: Eric Dumazet
    Cc: Patrick McHardy
    Cc: Ben Greear
    Cc: Ben Hutchings
    Acked-by: Patrick McHardy
    Signed-off-by: David S. Miller

    Eric Dumazet
     

18 Sep, 2010

1 commit

  • previously, if a vlan master device was moved from one network namespace
    to another, all 802.1q and macvlan slaves were deleted.

    we can use dev->reg_state to figure out whether dev_change_net_namespace
    is happening, since that won't set dev->reg_state NETREG_UNREGISTERING.
    so, this changes 8021q and macvlan to ignore NETDEV_UNREGISTER when
    reg_state is not NETREG_UNREGISTERING.

    Signed-off-by: David Lamparter
    Reviewed-by: "Eric W. Biederman"
    Acked-by: Daniel Lezcano
    Acked-by: Patrick McHardy
    Signed-off-by: David S. Miller

    David Lamparter
     

28 Jul, 2010

2 commits


23 Jul, 2010

1 commit

  • Mark Wagner reported OOM symptoms when sending UDP traffic over
    a macvtap link to a kvm receiver.

    This appears to be caused by the fact that macvtap packet queues
    are unlimited in length. This means that if the receiver can't
    keep up with the rate of flow, then we will hit OOM. Of course
    it gets worse if the OOM killer then decides to kill the receiver.

    This patch imposes a cap on the packet queue length, in the same
    way as the tuntap driver, using the device TX queue length.

    Please note that macvtap currently has no way of giving congestion
    notification, that means the software device TX queue cannot be
    used and packets will always be dropped once the macvtap driver
    queue fills up.

    This shouldn't be a great problem for the scenario where macvtap
    is used to feed a kvm receiver, as the traffic is most likely
    external in origin so congestion notification can't be applied
    anyway.

    Of course, if anybody decides to complain about guest-to-guest
    UDP packet loss down the track, then we may have to revisit this.

    Incidentally, this patch also fixes a real memory leak when
    macvtap_get_queue fails.

    Chris Wright noticed that for this patch to work, we need a
    non-zero TX queue length. This patch includes his work to change
    the default macvtap TX queue length to 500.

    Reported-by: Mark Wagner
    Signed-off-by: Herbert Xu
    Acked-by: Chris Wright
    Acked-by: Arnd Bergmann
    Signed-off-by: David S. Miller

    Herbert Xu
     

10 Jul, 2010

1 commit

  • In commit be1f3c2c027cc5ad735df6a45a542ed1db7ec48b "net: Enable 64-bit
    net device statistics on 32-bit architectures" I redefined struct
    net_device_stats so that it could be used in a union with struct
    rtnl_link_stats64, avoiding the need for explicit copying or
    conversion between the two. However, this is unsafe because there is
    no locking required and no lock consistently held around calls to
    dev_get_stats() and use of the statistics structure it returns.

    In commit 28172739f0a276eb8d6ca917b3974c2edb036da3 "net: fix 64 bit
    counters on 32 bit arches" Eric Dumazet dealt with that problem by
    requiring callers of dev_get_stats() to provide storage for the
    result. This means that the net_device::stats64 field and the padding
    in struct net_device_stats are now redundant, so remove them.

    Update the comment on net_device_ops::ndo_get_stats64 to reflect its
    new usage.

    Change dev_txq_stats_fold() to use struct rtnl_link_stats64, since
    that is what all its callers are really using and it is no longer
    going to be compatible with struct net_device_stats.

    Eric Dumazet suggested the separate function for the structure
    conversion.

    Signed-off-by: Ben Hutchings
    Acked-by: Eric Dumazet
    Signed-off-by: David S. Miller

    Ben Hutchings
     

08 Jul, 2010

1 commit

  • There is a small possibility that a reader gets incorrect values on 32
    bit arches. SNMP applications could catch incorrect counters when a
    32bit high part is changed by another stats consumer/provider.

    One way to solve this is to add a rtnl_link_stats64 param to all
    ndo_get_stats64() methods, and also add such a parameter to
    dev_get_stats().

    Rule is that we are not allowed to use dev->stats64 as a temporary
    storage for 64bit stats, but a caller provided area (usually on stack)

    Old drivers (only providing get_stats() method) need no changes.

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

    Eric Dumazet
     

29 Jun, 2010

1 commit


16 Jun, 2010

2 commits


08 Jun, 2010

1 commit


02 Jun, 2010

1 commit

  • What this patch does is it removes two receive frame hooks (for bridge and for
    macvlan) from __netif_receive_skb. These are replaced them with a single
    hook for both. It only supports one hook per device because it makes no
    sense to do bridging and macvlan on the same device.

    Then a network driver (of virtual netdev like macvlan or bridge) can register
    an rx_handler for needed net device.

    Signed-off-by: Jiri Pirko
    Signed-off-by: Stephen Hemminger
    Signed-off-by: David S. Miller

    Jiri Pirko
     

25 May, 2010

1 commit


16 May, 2010

2 commits


04 Apr, 2010

1 commit


19 Mar, 2010

1 commit

  • It's not desired for underlaying devices to change type. At the time,
    there is for example possible to have bond with changed type from
    Ethernet to Infiniband as a port of a bridge. This patch fixes this.

    Signed-off-by: Jiri Pirko
    Signed-off-by: Jay Vosburgh
    Signed-off-by: David S. Miller

    Jiri Pirko
     

04 Feb, 2010

1 commit

  • This makes it possible to hook into the macvlan driver
    from another kernel module. In particular, the goal is
    to extend it with the macvtap backend that provides
    a tun/tap compatible interface directly on the macvlan
    device.

    Signed-off-by: Arnd Bergmann
    Signed-off-by: David S. Miller

    Arnd Bergmann