22 May, 2017

1 commit

  • Since commit 76b91c32dd86 ("bridge: stp: when using userspace stp stop
    kernel hello and hold timers"), bridge would not start hello_timer if
    stp_enabled is not KERNEL_STP when br_dev_open.

    The problem is even if users set stp_enabled with KERNEL_STP later,
    the timer will still not be started. It causes that KERNEL_STP can
    not really work. Users have to re-ifup the bridge to avoid this.

    This patch is to fix it by starting br->hello_timer when enabling
    KERNEL_STP in br_stp_start.

    As an improvement, it's also to start hello_timer again only when
    br->stp_enabled is KERNEL_STP in br_hello_timer_expired, there is
    no reason to start the timer again when it's NO_STP.

    Fixes: 76b91c32dd86 ("bridge: stp: when using userspace stp stop kernel hello and hold timers")
    Reported-by: Haidong Li
    Signed-off-by: Xin Long
    Acked-by: Nikolay Aleksandrov
    Reviewed-by: Ivan Vecera
    Signed-off-by: David S. Miller

    Xin Long
     

07 Feb, 2017

1 commit

  • Move the fdb garbage collector to a workqueue which fires at least 10
    milliseconds apart and cleans chain by chain allowing for other tasks
    to run in the meantime. When having thousands of fdbs the system is much
    more responsive. Most importantly remove the need to check if the
    matched entry has expired in __br_fdb_get that causes false-sharing and
    is completely unnecessary if we cleanup entries, at worst we'll get 10ms
    of traffic for that entry before it gets deleted.

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

    Nikolay Aleksandrov
     

11 Dec, 2016

1 commit


19 Feb, 2016

1 commit


29 Jul, 2015

1 commit

  • These should be handled only by the respective STP which is in control.
    They become problematic for devices with limited resources with many
    ports because the hold_timer is per port and fires each second and the
    hello timer fires each 2 seconds even though it's global. While in
    user-space STP mode these timers are completely unnecessary so it's better
    to keep them off.
    Also ensure that when the bridge is up these timers are started only when
    running with kernel STP.

    Signed-off-by: Satish Ashok
    Signed-off-by: Nikolay Aleksandrov
    Signed-off-by: David S. Miller

    Nikolay Aleksandrov
     

23 May, 2015

1 commit

  • Following lockdep splat was reported :

    [ 29.382286] ===============================
    [ 29.382315] [ INFO: suspicious RCU usage. ]
    [ 29.382344] 4.1.0-0.rc0.git11.1.fc23.x86_64 #1 Not tainted
    [ 29.382380] -------------------------------
    [ 29.382409] net/bridge/br_private.h:626 suspicious
    rcu_dereference_check() usage!
    [ 29.382455]
    other info that might help us debug this:

    [ 29.382507]
    rcu_scheduler_active = 1, debug_locks = 0
    [ 29.382549] 2 locks held by swapper/0/0:
    [ 29.382576] #0: (((&p->forward_delay_timer))){+.-...}, at:
    [] call_timer_fn+0x5/0x4f0
    [ 29.382660] #1: (&(&br->lock)->rlock){+.-...}, at:
    [] br_forward_delay_timer_expired+0x31/0x140
    [bridge]
    [ 29.382754]
    stack backtrace:
    [ 29.382787] CPU: 0 PID: 0 Comm: swapper/0 Not tainted
    4.1.0-0.rc0.git11.1.fc23.x86_64 #1
    [ 29.382838] Hardware name: LENOVO 422916G/LENOVO, BIOS A1KT53AUS 04/07/2015
    [ 29.382882] 0000000000000000 3ebfc20364115825 ffff880666603c48
    ffffffff81892d4b
    [ 29.382943] 0000000000000000 ffffffff81e124e0 ffff880666603c78
    ffffffff8110bcd7
    [ 29.383004] ffff8800785c9d00 ffff88065485ac58 ffff880c62002800
    ffff880c5fc88ac0
    [ 29.383065] Call Trace:
    [ 29.383084] [] dump_stack+0x4c/0x65
    [ 29.383130] [] lockdep_rcu_suspicious+0xe7/0x120
    [ 29.383178] [] br_fill_ifinfo+0x4a9/0x6a0 [bridge]
    [ 29.383225] [] br_ifinfo_notify+0x11b/0x4b0 [bridge]
    [ 29.383271] [] ? br_hold_timer_expired+0x70/0x70 [bridge]
    [ 29.383320] []
    br_forward_delay_timer_expired+0x58/0x140 [bridge]
    [ 29.383371] [] ? br_hold_timer_expired+0x70/0x70 [bridge]
    [ 29.383416] [] call_timer_fn+0xc3/0x4f0
    [ 29.383454] [] ? call_timer_fn+0x5/0x4f0
    [ 29.383493] [] ? lock_release_holdtime.part.29+0xf/0x200
    [ 29.383541] [] ? br_hold_timer_expired+0x70/0x70 [bridge]
    [ 29.383587] [] run_timer_softirq+0x244/0x490
    [ 29.383629] [] __do_softirq+0xec/0x670
    [ 29.383666] [] irq_exit+0x145/0x150
    [ 29.383703] [] smp_apic_timer_interrupt+0x46/0x60
    [ 29.383744] [] apic_timer_interrupt+0x73/0x80
    [ 29.383782] [] ? cpuidle_enter_state+0x5f/0x2f0
    [ 29.383832] [] ? cpuidle_enter_state+0x5b/0x2f0

    Problem here is that br_forward_delay_timer_expired() is a timer
    handler, calling br_ifinfo_notify() which assumes either rcu_read_lock()
    or RTNL are held.

    Simplest fix seems to add rcu read lock section.

    Signed-off-by: Eric Dumazet
    Reported-by: Josh Boyer
    Reported-by: Dominick Grift
    Cc: Vlad Yasevich
    Signed-off-by: David S. Miller

    Eric Dumazet
     

02 Oct, 2014

1 commit

  • In preparation for being able to propagate port states to e.g: notifiers
    or other kernel parts, do not manipulate the port state directly, but
    instead use a helper function which will allow us to do a bit more than
    just setting the state.

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

    Florian Fainelli
     

20 Dec, 2013

1 commit


04 May, 2013

1 commit

  • A bridge should only send topology change notice if it is not
    the root bridge. It is possible for message age timer to elect itself
    as a new root bridge, and still have a topology change timer running
    but waiting for bridge lock on other CPU.

    Solve the race by checking if we are root bridge before continuing.
    This was the root cause of the cases where br_send_tcn_bpdu would OOPS.

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

    stephen hemminger
     

10 Aug, 2012

1 commit

  • Various /proc/net files sometimes report crazy timer values, expressed
    in clock_t units.

    This happens when an expired timer delta (expires - jiffies) is passed
    to jiffies_to_clock_t().

    This function has an overflow in :

    return div_u64((u64)x * TICK_NSEC, NSEC_PER_SEC / USER_HZ);

    commit cbbc719fccdb8cb (time: Change jiffies_to_clock_t() argument type
    to unsigned long) only got around the problem.

    As we cant output negative values in /proc/net/tcp without breaking
    various tools, I suggest adding a jiffies_delta_to_clock_t() wrapper
    that caps the negative delta to a 0 value.

    Signed-off-by: Eric Dumazet
    Reported-by: Maciej Żenczykowski
    Cc: Thomas Gleixner
    Cc: Paul Gortmaker
    Cc: Andrew Morton
    Cc: hank
    Signed-off-by: David S. Miller

    Eric Dumazet
     

16 Apr, 2012

1 commit


23 Jul, 2011

1 commit


15 Mar, 2011

1 commit

  • This makes the bridge device behave like a physical device.
    In earlier releases the bridge always asserted carrier. This
    changes the behavior so that bridge device carrier is on only
    if one or more ports are in the forwarding state. This
    should help IPv6 autoconfiguration, DHCP, and routing daemons.

    I did brief testing with Network and Virt manager and they
    seem fine, but since this changes behavior of bridge, it should
    wait until net-next (2.6.39).

    Signed-off-by: Stephen Hemminger
    Reviewed-by: Nicolas de Pesloüan
    Tested-By: Adam Majer
    Signed-off-by: David S. Miller

    stephen hemminger
     

16 May, 2010

1 commit


12 Jun, 2008

1 commit


31 May, 2007

1 commit


09 May, 2007

1 commit


11 Feb, 2007

1 commit


21 Mar, 2006

2 commits


17 Apr, 2005

1 commit

  • Initial git repository build. I'm not bothering with the full history,
    even though we have it. We can create a separate "historical" git
    archive of that later if we want to, and in the meantime it's about
    3.2GB when imported into git - space that would just make the early
    git days unnecessarily complicated, when we don't have a lot of good
    infrastructure for it.

    Let it rip!

    Linus Torvalds