24 Feb, 2013

1 commit

  • There are two places to call vlan_set_encap_proto():
    vlan_untag() and __pop_vlan_tci().

    vlan_untag() assumes skb->data points after mac addr, otherwise
    the following code

    vhdr = (struct vlan_hdr *) skb->data;
    vlan_tci = ntohs(vhdr->h_vlan_TCI);
    __vlan_hwaccel_put_tag(skb, vlan_tci);

    skb_pull_rcsum(skb, VLAN_HLEN);

    won't be correct. But __pop_vlan_tci() assumes points _before_
    mac addr.

    In vlan_set_encap_proto(), it looks for some magic L2 value
    after mac addr:

    rawp = skb->data;
    if (*(unsigned short *) rawp == 0xFFFF)
    ...

    Therefore __pop_vlan_tci() is obviously wrong.

    A quick fix is avoiding using skb->data in vlan_set_encap_proto(),
    use 'vhdr+1' is always correct in both cases.

    Cc: David S. Miller
    Cc: Jesse Gross
    Signed-off-by: Cong Wang
    Acked-by: Jesse Gross
    Signed-off-by: David S. Miller

    Cong Wang
     

13 Oct, 2012

1 commit


09 Oct, 2012

1 commit

  • 6a32e4f9dd9219261f8856f817e6655114cfec2f made the vlan code skip marking
    vlan-tagged frames for not locally configured vlans as PACKET_OTHERHOST if
    there was an rx_handler, as the rx_handler could cause the frame to be received
    on a different (virtual) vlan-capable interface where that vlan might be
    configured.

    As rx_handlers do not necessarily return RX_HANDLER_ANOTHER, this could cause
    frames for unknown vlans to be delivered to the protocol stack as if they had
    been received untagged.

    For example, if an ipv6 router advertisement that's tagged for a locally not
    configured vlan is received on an interface with macvlan interfaces attached,
    macvlan's rx_handler returns RX_HANDLER_PASS after delivering the frame to the
    macvlan interfaces, which caused it to be passed to the protocol stack, leading
    to ipv6 addresses for the announced prefix being configured even though those
    are completely unusable on the underlying interface.

    The fix moves marking as PACKET_OTHERHOST after the rx_handler so the
    rx_handler, if there is one, sees the frame unchanged, but afterwards,
    before the frame is delivered to the protocol stack, it gets marked whether
    there is an rx_handler or not.

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

    Florian Zumbiehl
     

25 Aug, 2012

1 commit


25 Mar, 2012

1 commit

  • Pull cleanup from Paul Gortmaker:
    "The changes shown here are to unify linux's BUG support under the one
    file. Due to historical reasons, we have some BUG code
    in bug.h and some in kernel.h -- i.e. the support for BUILD_BUG in
    linux/kernel.h predates the addition of linux/bug.h, but old code in
    kernel.h wasn't moved to bug.h at that time. As a band-aid, kernel.h
    was including to pseudo link them.

    This has caused confusion[1] and general yuck/WTF[2] reactions. Here
    is an example that violates the principle of least surprise:

    CC lib/string.o
    lib/string.c: In function 'strlcat':
    lib/string.c:225:2: error: implicit declaration of function 'BUILD_BUG_ON'
    make[2]: *** [lib/string.o] Error 1
    $
    $ grep linux/bug.h lib/string.c
    #include
    $

    We've included for the BUG infrastructure and yet we
    still get a compile fail! [We've not kernel.h for BUILD_BUG_ON.] Ugh -
    very confusing for someone who is new to kernel development.

    With the above in mind, the goals of this changeset are:

    1) find and fix any include/*.h files that were relying on the
    implicit presence of BUG code.
    2) find and fix any C files that were consuming kernel.h and hence
    relying on implicitly getting some/all BUG code.
    3) Move the BUG related code living in kernel.h to
    4) remove the asm/bug.h from kernel.h to finally break the chain.

    During development, the order was more like 3-4, build-test, 1-2. But
    to ensure that git history for bisect doesn't get needless build
    failures introduced, the commits have been reorderd to fix the problem
    areas in advance.

    [1] https://lkml.org/lkml/2012/1/3/90
    [2] https://lkml.org/lkml/2012/1/17/414"

    Fix up conflicts (new radeon file, reiserfs header cleanups) as per Paul
    and linux-next.

    * tag 'bug-for-3.4' of git://git.kernel.org/pub/scm/linux/kernel/git/paulg/linux:
    kernel.h: doesn't explicitly use bug.h, so don't include it.
    bug: consolidate BUILD_BUG_ON with other bug code
    BUG: headers with BUG/BUG_ON etc. need linux/bug.h
    bug.h: add include of it to various implicit C users
    lib: fix implicit users of kernel.h for TAINT_WARN
    spinlock: macroize assert_spin_locked to avoid bug.h dependency
    x86: relocate get/set debugreg fcns to include/asm/debugreg.

    Linus Torvalds
     

20 Mar, 2012

1 commit


05 Mar, 2012

1 commit

  • If a header file is making use of BUG, BUG_ON, BUILD_BUG_ON, or any
    other BUG variant in a static inline (i.e. not in a #define) then
    that header really should be including and not just
    expecting it to be implicitly present.

    We can make this change risk-free, since if the files using these
    headers didn't have exposure to linux/bug.h already, they would have
    been causing compile failures/warnings.

    Signed-off-by: Paul Gortmaker

    Paul Gortmaker
     

09 Dec, 2011

4 commits


04 Dec, 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
     

22 Jul, 2011

6 commits


18 Jul, 2011

1 commit

  • there is only one user of vlan_find_dev outside of the actual vlan code:
    qlcnic uses it to iterate over some VLANs it knows.

    let's just make vlan_find_dev private to the VLAN code and have the
    iteration in qlcnic be a bit more direct. (a few rcu dereferences less
    too)

    Signed-off-by: David Lamparter
    Cc: Patrick McHardy
    Cc: Amit Kumar Salecha
    Cc: Anirban Chakraborty
    Cc: linux-driver@qlogic.com
    Signed-off-by: David S. Miller

    David Lamparter
     

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
     

26 May, 2011

1 commit


10 May, 2011

1 commit

  • At VLAN dismantle phase, unregister_vlan_dev() makes one
    synchronize_net() call after vlan_group_set_device(grp, vlan_id, NULL).

    This call can be safely removed because we are calling
    unregister_netdevice_queue() to queue device for deletion, and this
    process needs at least one rcu grace period to complete.

    Signed-off-by: Eric Dumazet
    Cc: Ben Greear
    Cc: Patrick McHardy
    Cc: Paul E. McKenney
    Cc: Jesse Gross
    Cc: Michał Mirosław
    Acked-by: Jesse Gross
    Signed-off-by: David S. Miller

    Eric Dumazet
     

13 Apr, 2011

2 commits

  • Reported-by: Stephen Rothwell
    Signed-off-by: David S. Miller

    David S. Miller
     
  • 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
     

13 Nov, 2010

1 commit

  • Depending on how a packet is vlan tagged (i.e. hardware accelerated or
    not), the encapsulated protocol is stored in different locations. This
    provides a consistent method of accessing that protocol, which is needed
    by drivers, security checks, etc.

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

    Hao Zheng
     

22 Oct, 2010

1 commit

  • It is now acceptable to receive vlan tagged packets at any time,
    even if CONFIG_VLAN_8021Q is not set. This means that calling
    vlan_hwaccel_do_receive() should not result in BUG() but rather just
    behave as if there were no vlan devices configured.

    Reported-by: Vladislav Zolotarov
    Signed-off-by: Jesse Gross
    Signed-off-by: David S. Miller

    Jesse Gross
     

21 Oct, 2010

3 commits

  • 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
     
  • A struct net_device always maps to zero or one vlan groups and we
    always know the device when we are looking up a group. We currently
    do a hash table lookup on the device to find the group but it is
    much simpler to just store a pointer.

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

    Jesse Gross
     
  • VLAN_GROUP_ARRAY_LEN is simply the number of possible vlan VIDs.
    Since vlan groups will soon be more of an implementation detail
    for vlan devices, rename the constant to be descriptive of its
    actual purpose.

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

    Jesse Gross
     

23 Aug, 2010

1 commit


27 Nov, 2009

1 commit

  • Currently the UP/DOWN state of VLANs is synchronized to the state of the
    underlying device, meaning all VLANs are set down once the underlying
    device is set down. This causes all routes to the VLAN devices to vanish.

    Add a flag to specify a "loose binding" mode, in which only the operstate
    is transfered, but the VLAN device state is independant.

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

    Patrick McHardy
     

30 Oct, 2009

1 commit


28 Oct, 2009

1 commit


27 Oct, 2009

1 commit

  • We currently use a 16 bit field (vlan_tci) to store VLAN ID/PRIO on a skb.

    Null value is used as a special value, meaning vlan tagging not enabled.
    This forbids use of null vlan ID.

    As pointed by David, some drivers use the 3 high order bits (PRIO)

    As VLAN ID is 12 bits, we can use the remaining bit (CFI) as a flag, and
    allow null VLAN ID.

    In case future code really wants to use VLAN_CFI_MASK, we'll have to use
    a bit outside of vlan_tci.

    #define VLAN_PRIO_MASK 0xe000 /* Priority Code Point */
    #define VLAN_PRIO_SHIFT 13
    #define VLAN_CFI_MASK 0x1000 /* Canonical Format Indicator */
    #define VLAN_TAG_PRESENT VLAN_CFI_MASK
    #define VLAN_VID_MASK 0x0fff /* VLAN Identifier */

    Reported-by: Gertjan Hofman
    Signed-off-by: Eric Dumazet
    Signed-off-by: David S. Miller

    Eric Dumazet
     

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
     

19 Feb, 2009

1 commit


07 Jan, 2009

1 commit

  • This patch adds GRO interfaces for hardware-assisted VLAN reception.
    With this in place we're now at parity with LRO as far as the
    interface is concerned. That is, you can now take any LRO driver
    and convert it over to GRO.

    As the CB memory clashes with GRO's use of CB, I've removed it
    entirely by storing dev in skb->dev. This is OK because VLAN
    gets called first thing in netif_receive_skb and skb->dev is
    not used in between us calling netif_rx and netif_receive_skb
    getting called.

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

    Herbert Xu
     

05 Nov, 2008

1 commit

  • The changes to deliver hardware accelerated VLAN packets to packet
    sockets (commit bc1d0411) caused a warning for non-NAPI drivers.
    The __vlan_hwaccel_rx() function is called directly from the drivers
    RX function, for non-NAPI drivers that means its still in RX IRQ
    context:

    [ 27.779463] ------------[ cut here ]------------
    [ 27.779509] WARNING: at kernel/softirq.c:136 local_bh_enable+0x37/0x81()
    ...
    [ 27.782520] [] netif_nit_deliver+0x5b/0x75
    [ 27.782590] [] __vlan_hwaccel_rx+0x79/0x162
    [ 27.782664] [] atl1_intr+0x9a9/0xa7c [atl1]
    [ 27.782738] [] handle_IRQ_event+0x23/0x51
    [ 27.782808] [] handle_edge_irq+0xc2/0x102
    [ 27.782878] [] do_IRQ+0x4d/0x64

    Split hardware accelerated VLAN reception into two parts to fix this:

    - __vlan_hwaccel_rx just stores the VLAN TCI and performs the VLAN
    device lookup, then calls netif_receive_skb()/netif_rx()

    - vlan_hwaccel_do_receive(), which is invoked by netif_receive_skb()
    in softirq context, performs the real reception and delivery to
    packet sockets.

    Reported-and-tested-by: Ramon Casellas
    Signed-off-by: Patrick McHardy
    Signed-off-by: David S. Miller

    Patrick McHardy
     

15 Jul, 2008

1 commit

  • Use a real skb member to store the skb to avoid clashes with qdiscs,
    which are allowed to use the cb area themselves. As currently only real
    devices that consume the skb set the NETIF_F_HW_VLAN_TX flag, no explicit
    invalidation is neccessary.

    The new member fills a hole on 64 bit, the skb layout changes from:

    __u32 mark; /* 172 4 */
    sk_buff_data_t transport_header; /* 176 4 */
    sk_buff_data_t network_header; /* 180 4 */
    sk_buff_data_t mac_header; /* 184 4 */
    sk_buff_data_t tail; /* 188 4 */
    /* --- cacheline 3 boundary (192 bytes) --- */
    sk_buff_data_t end; /* 192 4 */

    /* XXX 4 bytes hole, try to pack */

    to

    __u32 mark; /* 172 4 */
    __u16 vlan_tci; /* 176 2 */

    /* XXX 2 bytes hole, try to pack */

    sk_buff_data_t transport_header; /* 180 4 */
    sk_buff_data_t network_header; /* 184 4 */

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

    Patrick McHardy