14 Dec, 2011

1 commit

  • The original code generates a Sparse warning:
    net/8021q/vlan_core.c:336:9:
    error: incompatible types in comparison expression (different address spaces)

    It's ok to dereference __rcu pointers here because we are holding the
    RTNL lock. I've added some calls to rtnl_dereference() to silence the
    warning.

    Signed-off-by: Dan Carpenter
    Acked-by: Eric Dumazet
    Acked-by: Jiri Pirko
    Signed-off-by: David S. Miller

    Dan Carpenter
     

09 Dec, 2011

4 commits


04 Dec, 2011

1 commit


07 Nov, 2011

1 commit

  • * 'modsplit-Oct31_2011' of git://git.kernel.org/pub/scm/linux/kernel/git/paulg/linux: (230 commits)
    Revert "tracing: Include module.h in define_trace.h"
    irq: don't put module.h into irq.h for tracking irqgen modules.
    bluetooth: macroize two small inlines to avoid module.h
    ip_vs.h: fix implicit use of module_get/module_put from module.h
    nf_conntrack.h: fix up fallout from implicit moduleparam.h presence
    include: replace linux/module.h with "struct module" wherever possible
    include: convert various register fcns to macros to avoid include chaining
    crypto.h: remove unused crypto_tfm_alg_modname() inline
    uwb.h: fix implicit use of asm/page.h for PAGE_SIZE
    pm_runtime.h: explicitly requires notifier.h
    linux/dmaengine.h: fix implicit use of bitmap.h and asm/page.h
    miscdevice.h: fix up implicit use of lists and types
    stop_machine.h: fix implicit use of smp.h for smp_processor_id
    of: fix implicit use of errno.h in include/linux/of.h
    of_platform.h: delete needless include
    acpi: remove module.h include from platform/aclinux.h
    miscdevice.h: delete unnecessary inclusion of module.h
    device_cgroup.h: delete needless include
    net: sch_generic remove redundant use of
    net: inet_timewait_sock doesnt need
    ...

    Fix up trivial conflicts (other header files, and removal of the ab3550 mfd driver) in
    - drivers/media/dvb/frontends/dibx000_common.c
    - drivers/media/video/{mt9m111.c,ov6650.c}
    - drivers/mfd/ab3550-core.c
    - include/linux/dmaengine.h

    Linus Torvalds
     

01 Nov, 2011

1 commit


30 Oct, 2011

1 commit

  • commit 2425717b27eb (net: allow vlan traffic to be received under bond)
    broke ARP processing on vlan on top of bonding.

    +-------+
    eth0 --| bond0 |---bond0.103
    eth1 --| |
    +-------+

    52870.115435: skb_gro_reset_offset
    Reviewed-by: Jiri Pirko
    Signed-off-by: David S. Miller

    Eric Dumazet
     

19 Aug, 2011

1 commit

  • It's after all necessary to do reset headers here. The reason is we
    cannot depend that it gets reseted in __netif_receive_skb once skb is
    reinjected. For incoming vlanids without vlan_dev, vlan_do_receive()
    returns false with skb != NULL and __netif_reveive_skb continues, skb is
    not reinjected.

    This might be good material for 3.0-stable as well

    Reported-by: Mike Auty
    Signed-off-by: Jiri Pirko
    Signed-off-by: David S. Miller

    Jiri Pirko
     

22 Jul, 2011

3 commits


12 Jun, 2011

1 commit

  • Testing of VLAN_FLAG_REORDER_HDR does not belong in vlan_untag
    but rather in vlan_do_receive. Otherwise the vlan header
    will not be properly put on the packet in the case of
    vlan header accelleration.

    As we remove the check from vlan_check_reorder_header
    rename it vlan_reorder_header to keep the naming clean.

    Fix up the skb->pkt_type early so we don't look at the packet
    after adding the vlan tag, which guarantees we don't goof
    and look at the wrong field.

    Use a simple if statement instead of a complicated switch
    statement to decided that we need to increment rx_stats
    for a multicast packet.

    Hopefully at somepoint we will just declare the case where
    VLAN_FLAG_REORDER_HDR is cleared as unsupported and remove
    the code. Until then this keeps it working correctly.

    Signed-off-by: Eric W. Biederman
    Signed-off-by: Jiri Pirko
    Acked-by: Changli Gao
    Signed-off-by: David S. Miller

    Jiri Pirko
     

13 Apr, 2011

1 commit

  • Now there are 2 paths for rx vlan frames. When rx-vlan-hw-accel is
    enabled, skb is untagged by NIC, vlan_tci is set and the skb gets into
    vlan code in __netif_receive_skb - vlan_hwaccel_do_receive.

    For non-rx-vlan-hw-accel however, tagged skb goes thru whole
    __netif_receive_skb, it's untagged in ptype_base hander and reinjected

    This incosistency is fixed by this patch. Vlan untagging happens early in
    __netif_receive_skb so the rest of code (ptype_all handlers, rx_handlers)
    see the skb like it was untagged by hw.

    Signed-off-by: Jiri Pirko

    v1->v2:
    remove "inline" from vlan_core.c functions
    Signed-off-by: David S. Miller

    Jiri Pirko
     

17 Nov, 2010

1 commit

  • vlan 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 vlan_rx_stats to vlan_pcpu_stats.

    Note : this partially reverts commit 2e59af3dcbdf (vlan: multiqueue vlan
    device)

    Signed-off-by: Eric Dumazet
    Cc: Patrick McHardy
    Signed-off-by: David S. Miller

    Eric Dumazet
     

21 Oct, 2010

1 commit

  • Currently each driver that is capable of vlan hardware acceleration
    must be aware of the vlan groups that are configured and then pass
    the stripped tag to a specialized receive function. This is

    different from other types of hardware offload in that it places a
    significant amount of knowledge in the driver itself rather keeping
    it in the networking core.

    This makes vlan offloading function more similarly to other forms
    of offloading (such as checksum offloading or TSO) by doing the
    following:
    * On receive, stripped vlans are passed directly to the network
    core, without attempting to check for vlan groups or reconstructing
    the header if no group
    * vlans are made less special by folding the logic into the main
    receive routines
    * On transmit, the device layer will add the vlan header in software
    if the hardware doesn't support it, instead of spreading that logic
    out in upper layers, such as bonding.

    There are a number of advantages to this:
    * Fixes all bugs with drivers incorrectly dropping vlan headers at once.
    * Avoids having to disable VLAN acceleration when in promiscuous mode
    (good for bridging since it always puts devices in promiscuous mode).
    * Keeps VLAN tag separate until given to ultimate consumer, which
    avoids needing to do header reconstruction as in tg3 unless absolutely
    necessary.
    * Consolidates common code in core networking.

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

    Jesse Gross
     

06 Oct, 2010

1 commit

  • In various situations, a device provides a packet to our stack and we
    drop it before it enters protocol stack :
    - softnet backlog full (accounted in /proc/net/softnet_stat)
    - bad vlan tag (not accounted)
    - unknown/unregistered protocol (not accounted)

    We can handle a per-device counter of such dropped frames at core level,
    and automatically adds it to the device provided stats (rx_dropped), so
    that standard tools can be used (ifconfig, ip link, cat /proc/net/dev)

    This is a generalization of commit 8990f468a (net: rx_dropped
    accounting), thus reverting it.

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

    Eric Dumazet
     

05 Oct, 2010

1 commit


01 Oct, 2010

1 commit

  • Roger Luethi noticed packets for unknown VLANs getting silently dropped
    even in promiscuous mode.

    Check for promiscuous mode in __vlan_hwaccel_rx() and vlan_gro_common()
    before drops.

    As suggested by Patrick, mark such packets to have skb->pkt_type set to
    PACKET_OTHERHOST to make sure they are dropped by IP stack.

    Reported-by: Roger Luethi
    Signed-off-by: Eric Dumazet
    CC: Patrick McHardy
    Signed-off-by: David S. Miller

    Eric Dumazet
     

24 Sep, 2010

1 commit


01 Sep, 2010

1 commit


27 Aug, 2010

1 commit

  • compare_ether_header() can have a special implementation on 64 bit
    arches if CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS is defined.

    __napi_gro_receive() and vlan_gro_common() can avoid a conditional
    branch to perform device match.

    On x86_64, __napi_gro_receive() has now 38 instructions instead of 53

    As gcc-4.4.3 still choose to not inline it, add inline keyword to this
    performance critical function.

    Signed-off-by: Eric Dumazet
    CC: Herbert Xu
    Signed-off-by: David S. Miller

    Eric Dumazet
     

23 Aug, 2010

1 commit


19 Jul, 2010

1 commit

  • - Without the 8021q module loaded in the kernel, all 802.1p packets
    (VLAN 0 but QoS tagging) are silently discarded (as expected, as
    the protocol is not loaded).

    - Without this patch in 8021q module, these packets are forwarded to
    the module, but they are discarded also if VLAN 0 is not configured,
    which should not be the default behaviour, as VLAN 0 is not really
    a VLANed packet but a 802.1p packet. Defining VLAN 0 makes it almost
    impossible to communicate with mixed 802.1p and non 802.1p devices on
    the same network due to arp table issues.

    - Changed logic to skip vlan specific code in vlan_skb_recv if VLAN
    is 0 and we have not defined a VLAN with ID 0, but we accept the
    packet with the encapsulated proto and pass it later to netif_rx.

    - In the vlan device event handler, added some logic to add VLAN 0
    to HW filter in devices that support it (this prevented any traffic
    in VLAN 0 to reach the stack in e1000e with HW filter under 2.6.35,
    and probably also with other HW filtered cards, so we fix it here).

    - In the vlan unregister logic, prevent the elimination of VLAN 0
    in devices with HW filter.

    - The default behaviour is to ignore the VLAN 0 tagging and accept
    the packet as if it was not tagged, but we can still define a
    VLAN 0 if desired (so it is backwards compatible).

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

    Pedro Garcia
     

29 Jun, 2010

1 commit


11 Jun, 2010

1 commit

  • Currently, the accelerated receive path for VLAN's will
    drop packets if the real device is an inactive slave and
    is not one of the special pkts tested for in
    skb_bond_should_drop(). This behavior is different then
    the non-accelerated path and for pkts over a bonded vlan.

    For example,

    vlanx -> bond0 -> ethx

    will be dropped in the vlan path and not delivered to any
    packet handlers at all. However,

    bond0 -> vlanx -> ethx

    and

    bond0 -> ethx

    will be delivered to handlers that match the exact dev,
    because the VLAN path checks the real_dev which is not a
    slave and netif_recv_skb() doesn't drop frames but only
    delivers them to exact matches.

    This patch adds a sk_buff flag which is used for tagging
    skbs that would previously been dropped and allows the
    skb to continue to skb_netif_recv(). Here we add
    logic to check for the deliver_no_wcard flag and if it
    is set only deliver to handlers that match exactly. This
    makes both paths above consistent and gives pkt handlers
    a way to identify skbs that come from inactive slaves.
    Without this patch in some configurations skbs will be
    delivered to handlers with exact matches and in others
    be dropped out right in the vlan path.

    I have tested the following 4 configurations in failover modes
    and load balancing modes.

    # bond0 -> ethx

    # vlanx -> bond0 -> ethx

    # bond0 -> vlanx -> ethx

    # bond0 -> ethx
    |
    vlanx -> --

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

    John Fastabend
     

18 May, 2010

1 commit


19 Mar, 2010

1 commit

  • When doing "ifenslave -d bond0 eth0", there is chance to get NULL
    dereference in netif_receive_skb(), because dev->master suddenly becomes
    NULL after we tested it.

    We should use ACCESS_ONCE() to avoid this (or rcu_dereference())

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

    Eric Dumazet
     

04 Jan, 2010

1 commit

  • This allows a bond device to specify an arp_ip_target as a host that is
    not on the same vlan as the base bond device and still use arp
    validation. A configuration like this, now works:

    BONDING_OPTS="mode=active-backup arp_interval=1000 arp_ip_target=10.0.100.1 arp_validate=3"

    1: lo: mtu 16436 qdisc noqueue
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
    inet6 ::1/128 scope host
    valid_lft forever preferred_lft forever
    2: eth1: mtu 1500 qdisc pfifo_fast master bond0 qlen 1000
    link/ether 00:13:21:be:33:e9 brd ff:ff:ff:ff:ff:ff
    3: eth0: mtu 1500 qdisc pfifo_fast master bond0 qlen 1000
    link/ether 00:13:21:be:33:e9 brd ff:ff:ff:ff:ff:ff
    8: bond0: mtu 1500 qdisc noqueue
    link/ether 00:13:21:be:33:e9 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::213:21ff:febe:33e9/64 scope link
    valid_lft forever preferred_lft forever
    9: bond0.100@bond0: mtu 1500 qdisc noqueue
    link/ether 00:13:21:be:33:e9 brd ff:ff:ff:ff:ff:ff
    inet 10.0.100.2/24 brd 10.0.100.255 scope global bond0.100
    inet6 fe80::213:21ff:febe:33e9/64 scope link
    valid_lft forever preferred_lft forever

    Ethernet Channel Bonding Driver: v3.6.0 (September 26, 2009)

    Bonding Mode: fault-tolerance (active-backup)
    Primary Slave: None
    Currently Active Slave: eth1
    MII Status: up
    MII Polling Interval (ms): 0
    Up Delay (ms): 0
    Down Delay (ms): 0
    ARP Polling Interval (ms): 1000
    ARP IP target/s (n.n.n.n form): 10.0.100.1

    Slave Interface: eth1
    MII Status: up
    Link Failure Count: 1
    Permanent HW addr: 00:40:05:30:ff:30

    Slave Interface: eth0
    MII Status: up
    Link Failure Count: 0
    Permanent HW addr: 00:13:21:be:33:e9

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

    Andy Gospodarek
     

18 Nov, 2009

1 commit

  • With multi queue devices, its possible that several cpus call
    vlan RX routines simultaneously for the same vlan device.

    We update RX stats counter without any locking, so we can
    get slightly wrong counters.

    One possible fix is to use percpu counters, to get precise
    accounting and also get guarantee of no cache line ping pongs
    between cpus.

    Note: this adds 16 bytes (32 bytes on 64bit arches) of percpu
    data per vlan device.

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

    Eric Dumazet
     

16 Nov, 2009

1 commit


30 Oct, 2009

2 commits


17 Apr, 2009

1 commit


16 Apr, 2009

1 commit

  • It turns out that copying a 16-byte area at ~800k times a second
    can be really expensive :) This patch redesigns the frags GRO
    interface to avoid copying that area twice.

    The two disciples of the frags interface have been converted.

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

    Herbert Xu
     

14 Apr, 2009

1 commit

  • Hi:

    gro: Normalise skb before bypassing GRO on netpoll VLAN path

    When we detect netpoll RX on the GRO VLAN path we bail out and
    call the normal VLAN receive handler. However, the packet needs
    to be normalised by calling eth_type_trans since that's what the
    normal path expects (normally the GRO path does the fixup).

    This patch adds the necessary call to vlan_gro_frags.

    Signed-off-by: Herbert Xu

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

    Herbert Xu
     

18 Mar, 2009

1 commit

  • Jarek Poplawski pointed out that my previous fix is broken for
    VLAN+netpoll as if netpoll is enabled we'd end up in the normal
    receive path instead of the VLAN receive path.

    This patch fixes it by calling the VLAN receive hook.

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

    Herbert Xu
     

17 Mar, 2009

1 commit

  • As my netpoll fix for net doesn't really work for net-next, we
    need this update to move the checks into the right place. As it
    stands we may pass freed skbs to netpoll_receive_skb.

    This patch also introduces a netpoll_rx_on function to avoid GRO
    completely if we're invoked through netpoll. This might seem
    paranoid but as netpoll may have an external receive hook it's
    better to be safe than sorry. I don't think we need this for
    2.6.29 though since there's nothing immediately broken by it.

    This patch also moves the GRO_* return values to netdevice.h since
    VLAN needs them too (I tried to avoid this originally but alas
    this seems to be the easiest way out). This fixes a bug in VLAN
    where it continued to use the old return value 2 instead of the
    correct GRO_DROP.

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

    Herbert Xu
     

02 Mar, 2009

1 commit