linux-toradex.git/net/bridge/br_stp_timer.c, branch v4.4.78

bridge: start hello_timer when enabling KERNEL_STP in br_stp_start

2017-06-07T10:05:58+00:00

[ Upstream commit 6d18c732b95c0a9d35e9f978b4438bba15412284 ]

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 
Signed-off-by: Greg Kroah-Hartman

bridge: stp: when using userspace stp stop kernel hello and hold timers

2015-07-29T06:33:20+00:00

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

bridge: fix lockdep splat

2015-05-22T20:23:56+00:00

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

net: bridge: add a br_set_state helper function

2014-10-02T02:03:50+00:00

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

bridge: add space before '(/{', after ',', etc.

2013-12-20T00:27:26+00:00

Spaces required before the open parenthesis '(', before the open
brace '{', after that ',' and around that '?/:'.

Signed-off-by: Tan Xiaojun 
Signed-off-by: David S. Miller

bridge: fix race with topology change timer

2013-05-03T20:08:58+00:00

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

time: jiffies_delta_to_clock_t() helper to the rescue

2012-08-09T23:17:03+00:00

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

net: cleanup unsigned to unsigned int

2012-04-15T16:44:40+00:00

Use of "unsigned int" is preferred to bare "unsigned" in net tree.

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

bridge: add notification over netlink when STP changes state

2011-07-23T00:01:12+00:00

When STP changes state of interface need to send a new link
message to reflect that change.

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

bridge: control carrier based on ports online

2011-03-14T21:29:02+00:00

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