08 Mar, 2013

1 commit


14 Feb, 2013

4 commits


03 Nov, 2012

1 commit


30 Oct, 2012

1 commit


10 May, 2012

1 commit

  • Use the new bool function ether_addr_equal to add
    some clarity and reduce the likelihood for misuse
    of compare_ether_addr for sorting.

    Done via cocci script:

    $ cat compare_ether_addr.cocci
    @@
    expression a,b;
    @@
    - !compare_ether_addr(a, b)
    + ether_addr_equal(a, b)

    @@
    expression a,b;
    @@
    - compare_ether_addr(a, b)
    + !ether_addr_equal(a, b)

    @@
    expression a,b;
    @@
    - !ether_addr_equal(a, b) == 0
    + ether_addr_equal(a, b)

    @@
    expression a,b;
    @@
    - !ether_addr_equal(a, b) != 0
    + !ether_addr_equal(a, b)

    @@
    expression a,b;
    @@
    - ether_addr_equal(a, b) == 0
    + !ether_addr_equal(a, b)

    @@
    expression a,b;
    @@
    - ether_addr_equal(a, b) != 0
    + ether_addr_equal(a, b)

    @@
    expression a,b;
    @@
    - !!ether_addr_equal(a, b)
    + ether_addr_equal(a, b)

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

    Joe Perches
     

01 Nov, 2011

1 commit


07 Oct, 2011

1 commit

  • This is based on an earlier patch by Nick Carter with comments
    by David Lamparter but with some refinements. Thanks for their patience
    this is a confusing area with overlap of standards, user requirements,
    and compatibility with earlier releases.

    It adds a new sysfs attribute
    /sys/class/net/brX/bridge/group_fwd_mask
    that controls forwarding of frames with address of: 01-80-C2-00-00-0X
    The default setting has no forwarding to retain compatibility.

    One change from earlier releases is that forwarding of group
    addresses is not dependent on STP being enabled or disabled. This
    choice was made based on interpretation of tie 802.1 standards.
    I expect complaints will arise because of this, but better to follow
    the standard than continue acting incorrectly by default.

    The filtering mask is writeable, but only values that don't forward
    known control frames are allowed. It intentionally blocks attempts
    to filter control protocols. For example: writing a 8 allows
    forwarding 802.1X PAE addresses which is the most common request.

    Reported-by: David Lamparter
    Original-patch-by: Nick Carter
    Signed-off-by: Stephen Hemminger
    Tested-by: Benjamin Poirier
    Signed-off-by: David S. Miller

    stephen hemminger
     

06 Jul, 2011

1 commit

  • As is_multicast_ether_addr returns true on broadcast packets as
    well, we need to explicitly exclude broadcast packets so that
    they're always flooded. This wasn't an issue before as broadcast
    packets were considered to be an unregistered multicast group,
    which were always flooded. However, as we now only flood such
    packets to router ports, this is no longer acceptable.

    Reported-by: Michael Guntsche
    Signed-off-by: Herbert Xu
    Signed-off-by: David S. Miller

    Herbert Xu
     

27 Apr, 2011

1 commit


22 Apr, 2011

1 commit

  • This reverts commit 1e253c3b8a1aeed51eef6fc366812f219b97de65.

    It breaks 802.3ad bonding inside of a bridge.

    The commit was meant to support transport bridging, and specifically
    virtual machines bridged to an ethernet interface connected to a
    switch port wiht 802.1x enabled.

    But this isn't the way to do it, it breaks too many other things.

    Signed-off-by: David S. Miller

    David S. Miller
     

05 Apr, 2011

1 commit


17 Mar, 2011

1 commit


12 Feb, 2011

1 commit

  • As it turns out we never need to walk through the list of multicast
    groups subscribed by the bridge interface itself (the only time we'd
    want to do that is when we shut down the bridge, in which case we
    simply walk through all multicast groups), we don't really need to
    keep an hlist for mp->mglist.

    This means that we can replace it with just a single bit to indicate
    whether the bridge interface is subscribed to a group.

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

    Herbert Xu
     

16 Nov, 2010

1 commit


21 Oct, 2010

1 commit


23 Aug, 2010

1 commit

  • While looking at using netdev_rx_handler_register for openvswitch Jesse
    Gross suggested that an unlikely() might be worthwhile in that code.
    I'm interested to see if its appropriate for the bridge code.

    Cc: Jesse Gross
    Signed-off-by: Simon Horman
    Signed-off-by: David S. Miller

    Simon Horman
     

03 Aug, 2010

1 commit


29 Jul, 2010

1 commit

  • Long ago, when bridge was converted to RCU, rcu lock was equivalent
    to having preempt disabled. RCU has changed a lot since then and
    bridge code was still assuming the since transmit was called with
    bottom half disabled, it was RCU safe.

    Signed-off-by: Stephen Hemminger
    Tested-by: Johannes Berg
    Signed-off-by: David S. Miller

    stephen hemminger
     

24 Jun, 2010

1 commit

  • Use u64_stats_sync infrastructure to provide 64bit rx/tx
    counters even on 32bit hosts.

    It is safe to use a single u64_stats_sync for rx and tx,
    because BH is disabled on both, and we use per_cpu data.

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

    Eric Dumazet
     

16 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
     

20 Apr, 2010

1 commit


12 Apr, 2010

1 commit


30 Mar, 2010

1 commit

  • …it slab.h inclusion from percpu.h

    percpu.h is included by sched.h and module.h and thus ends up being
    included when building most .c files. percpu.h includes slab.h which
    in turn includes gfp.h making everything defined by the two files
    universally available and complicating inclusion dependencies.

    percpu.h -> slab.h dependency is about to be removed. Prepare for
    this change by updating users of gfp and slab facilities include those
    headers directly instead of assuming availability. As this conversion
    needs to touch large number of source files, the following script is
    used as the basis of conversion.

    http://userweb.kernel.org/~tj/misc/slabh-sweep.py

    The script does the followings.

    * Scan files for gfp and slab usages and update includes such that
    only the necessary includes are there. ie. if only gfp is used,
    gfp.h, if slab is used, slab.h.

    * When the script inserts a new include, it looks at the include
    blocks and try to put the new include such that its order conforms
    to its surrounding. It's put in the include block which contains
    core kernel includes, in the same order that the rest are ordered -
    alphabetical, Christmas tree, rev-Xmas-tree or at the end if there
    doesn't seem to be any matching order.

    * If the script can't find a place to put a new include (mostly
    because the file doesn't have fitting include block), it prints out
    an error message indicating which .h file needs to be added to the
    file.

    The conversion was done in the following steps.

    1. The initial automatic conversion of all .c files updated slightly
    over 4000 files, deleting around 700 includes and adding ~480 gfp.h
    and ~3000 slab.h inclusions. The script emitted errors for ~400
    files.

    2. Each error was manually checked. Some didn't need the inclusion,
    some needed manual addition while adding it to implementation .h or
    embedding .c file was more appropriate for others. This step added
    inclusions to around 150 files.

    3. The script was run again and the output was compared to the edits
    from #2 to make sure no file was left behind.

    4. Several build tests were done and a couple of problems were fixed.
    e.g. lib/decompress_*.c used malloc/free() wrappers around slab
    APIs requiring slab.h to be added manually.

    5. The script was run on all .h files but without automatically
    editing them as sprinkling gfp.h and slab.h inclusions around .h
    files could easily lead to inclusion dependency hell. Most gfp.h
    inclusion directives were ignored as stuff from gfp.h was usually
    wildly available and often used in preprocessor macros. Each
    slab.h inclusion directive was examined and added manually as
    necessary.

    6. percpu.h was updated not to include slab.h.

    7. Build test were done on the following configurations and failures
    were fixed. CONFIG_GCOV_KERNEL was turned off for all tests (as my
    distributed build env didn't work with gcov compiles) and a few
    more options had to be turned off depending on archs to make things
    build (like ipr on powerpc/64 which failed due to missing writeq).

    * x86 and x86_64 UP and SMP allmodconfig and a custom test config.
    * powerpc and powerpc64 SMP allmodconfig
    * sparc and sparc64 SMP allmodconfig
    * ia64 SMP allmodconfig
    * s390 SMP allmodconfig
    * alpha SMP allmodconfig
    * um on x86_64 SMP allmodconfig

    8. percpu.h modifications were reverted so that it could be applied as
    a separate patch and serve as bisection point.

    Given the fact that I had only a couple of failures from tests on step
    6, I'm fairly confident about the coverage of this conversion patch.
    If there is a breakage, it's likely to be something in one of the arch
    headers which should be easily discoverable easily on most builds of
    the specific arch.

    Signed-off-by: Tejun Heo <tj@kernel.org>
    Guess-its-ok-by: Christoph Lameter <cl@linux-foundation.org>
    Cc: Ingo Molnar <mingo@redhat.com>
    Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>

    Tejun Heo
     

25 Mar, 2010

1 commit

  • The first argument to NF_HOOK* is an nfproto since quite some time.
    Commit v2.6.27-2457-gfdc9314 was the first to practically start using
    the new names. Do that now for the remaining NF_HOOK calls.

    The semantic patch used was:
    //
    @@
    @@
    (NF_HOOK
    |NF_HOOK_THRESH
    )(
    -PF_BRIDGE,
    +NFPROTO_BRIDGE,
    ...)

    @@
    @@
    NF_HOOK(
    -PF_INET6,
    +NFPROTO_IPV6,
    ...)

    @@
    @@
    NF_HOOK(
    -PF_INET,
    +NFPROTO_IPV4,
    ...)
    //

    Signed-off-by: Jan Engelhardt

    Jan Engelhardt
     

17 Mar, 2010

2 commits


16 Mar, 2010

1 commit

  • From: Michael Braun

    bridge: Fix br_forward crash in promiscuous mode

    It's a linux-next kernel from 2010-03-12 on an x86 system and it
    OOPs in the bridge module in br_pass_frame_up (called by
    br_handle_frame_finish) because brdev cannot be dereferenced (its set to
    a non-null value).

    Adding some BUG_ON statements revealed that
    BR_INPUT_SKB_CB(skb)->brdev == br-dev
    (as set in br_handle_frame_finish first)
    only holds until br_forward is called.
    The next call to br_pass_frame_up then fails.

    Digging deeper it seems that br_forward either frees the skb or passes
    it to NF_HOOK which will in turn take care of freeing the skb. The
    same is holds for br_pass_frame_ip. So it seems as if two independent
    skb allocations are required. As far as I can see, commit
    b33084be192ee1e347d98bb5c9e38a53d98d35e2 ("bridge: Avoid unnecessary
    clone on forward path") removed skb duplication and so likely causes
    this crash. This crash does not happen on 2.6.33.

    I've therefore modified br_forward the same way br_flood has been
    modified so that the skb is not freed if skb0 is going to be used
    and I can confirm that the attached patch resolves the issue for me.

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

    Michael Braun
     

28 Feb, 2010

4 commits

  • This patch finally hooks up the multicast snooping module to the
    data path. In particular, all multicast packets passing through
    the bridge are fed into the module and switched by it.

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

    Herbert Xu
     
  • When the packet is delivered to the local bridge device we may
    end up cloning it unnecessarily if no bridge port can receive
    the packet in br_flood.

    This patch avoids this by moving the skb_clone into br_flood.

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

    Herbert Xu
     
  • This patch allows tail-call on the call to br_pass_frame_up
    in br_handle_frame_finish. This is now possible because of the
    previous patch to call br_pass_frame_up last.

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

    Herbert Xu
     
  • At the moment we deliver to the local bridge port via the function
    br_pass_frame_up before all other ports. There is no requirement
    for this.

    For the purpose of IGMP snooping, it would be more convenient if
    we did the local port last. Therefore this patch rearranges the
    bridge input processing so that the local bridge port gets to see
    the packet last (if at all).

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

    Herbert Xu
     

18 May, 2009

1 commit

  • Currently the bridge catches all STP packets; even if STP is turned
    off. This prevents other systems (which do have STP turned on)
    from being able to detect loops in the network.

    With this patch, if STP is off, then any packet sent to the STP
    multicast group address is forwarded to all ports.

    Based on earlier patch by Joakim Tjernlund with changes
    to go through forwarding (not local chain), and optimization
    that only last octet needs to be checked.

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

    Stephen Hemminger
     

18 Jun, 2008

1 commit

  • Any frame addressed to link-local addresses should be processed by local
    receive path. The earlier code would process them only if STP was enabled.
    Since there are other frames like LACP for bonding, we should always
    process them.

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

    Stephen Hemminger
     

12 Jun, 2008

1 commit


22 May, 2008

1 commit


29 Jan, 2008

1 commit