31 May, 2019

1 commit

  • Based on 1 normalized pattern(s):

    this program is free software you can redistribute it and or modify
    it under the terms of the gnu general public license as published by
    the free software foundation either version 2 of the license or at
    your option any later version

    extracted by the scancode license scanner the SPDX license identifier

    GPL-2.0-or-later

    has been chosen to replace the boilerplate/reference in 3029 file(s).

    Signed-off-by: Thomas Gleixner
    Reviewed-by: Allison Randal
    Cc: linux-spdx@vger.kernel.org
    Link: https://lkml.kernel.org/r/20190527070032.746973796@linutronix.de
    Signed-off-by: Greg Kroah-Hartman

    Thomas Gleixner
     

03 Nov, 2017

1 commit


02 Nov, 2017

1 commit

  • Currently the bridge device doesn't generate any notifications upon vlan
    modifications on itself because it doesn't use the generic bridge
    notifications.
    With the recent changes we know if anything was modified in the vlan config
    thus we can generate a notification when necessary for the bridge device
    so add support to br_ifinfo_notify() similar to how other combined
    functions are done - if port is present it takes precedence, otherwise
    notify about the bridge. I've explicitly marked the locations where the
    notification should be always for the port by setting bridge to NULL.
    I've also taken the liberty to rearrange each modified function's local
    variables in reverse xmas tree as well.

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

    Nikolay Aleksandrov
     

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