1. 16 9月, 2013 2 次提交
  2. 13 9月, 2013 2 次提交
    • H
      bridge: Clamp forward_delay when enabling STP · be4f154d
      Herbert Xu 提交于
      At some point limits were added to forward_delay.  However, the
      limits are only enforced when STP is enabled.  This created a
      scenario where you could have a value outside the allowed range
      while STP is disabled, which then stuck around even after STP
      is enabled.
      
      This patch fixes this by clamping the value when we enable STP.
      
      I had to move the locking around a bit to ensure that there is
      no window where someone could insert a value outside the range
      while we're in the middle of enabling STP.
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      
      Cheers,
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      be4f154d
    • C
      resubmit bridge: fix message_age_timer calculation · 9a062013
      Chris Healy 提交于
      This changes the message_age_timer calculation to use the BPDU's max age as
      opposed to the local bridge's max age.  This is in accordance with section
      8.6.2.3.2 Step 2 of the 802.1D-1998 sprecification.
      
      With the current implementation, when running with very large bridge
      diameters, convergance will not always occur even if a root bridge is
      configured to have a longer max age.
      
      Tested successfully on bridge diameters of ~200.
      Signed-off-by: NChris Healy <cphealy@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      9a062013
  3. 06 9月, 2013 2 次提交
  4. 05 9月, 2013 1 次提交
  5. 31 8月, 2013 2 次提交
    • D
      net: bridge: convert MLDv2 Query MRC into msecs_to_jiffies for max_delay · 2d98c29b
      Daniel Borkmann 提交于
      While looking into MLDv1/v2 code, I noticed that bridging code does
      not convert it's max delay into jiffies for MLDv2 messages as we do
      in core IPv6' multicast code.
      
      RFC3810, 5.1.3. Maximum Response Code says:
      
        The Maximum Response Code field specifies the maximum time allowed
        before sending a responding Report. The actual time allowed, called
        the Maximum Response Delay, is represented in units of milliseconds,
        and is derived from the Maximum Response Code as follows: [...]
      
      As we update timers that work with jiffies, we need to convert it.
      Signed-off-by: NDaniel Borkmann <dborkman@redhat.com>
      Cc: Linus Lüssing <linus.luessing@web.de>
      Cc: Hannes Frederic Sowa <hannes@stressinduktion.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      2d98c29b
    • L
      bridge: separate querier and query timer into IGMP/IPv4 and MLD/IPv6 ones · cc0fdd80
      Linus Lüssing 提交于
      Currently we would still potentially suffer multicast packet loss if there
      is just either an IGMP or an MLD querier: For the former case, we would
      possibly drop IPv6 multicast packets, for the latter IPv4 ones. This is
      because we are currently assuming that if either an IGMP or MLD querier
      is present that the other one is present, too.
      
      This patch makes the behaviour and fix added in
      "bridge: disable snooping if there is no querier" (b00589af)
      to also work if there is either just an IGMP or an MLD querier on the
      link: It refines the deactivation of the snooping to be protocol
      specific by using separate timers for the snooped IGMP and MLD queries
      as well as separate timers for our internal IGMP and MLD queriers.
      Signed-off-by: NLinus Lüssing <linus.luessing@web.de>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      cc0fdd80
  6. 30 8月, 2013 1 次提交
  7. 21 8月, 2013 1 次提交
  8. 08 8月, 2013 1 次提交
  9. 06 8月, 2013 1 次提交
  10. 05 8月, 2013 1 次提交
  11. 01 8月, 2013 1 次提交
    • L
      bridge: disable snooping if there is no querier · b00589af
      Linus Lüssing 提交于
      If there is no querier on a link then we won't get periodic reports and
      therefore won't be able to learn about multicast listeners behind ports,
      potentially leading to lost multicast packets, especially for multicast
      listeners that joined before the creation of the bridge.
      
      These lost multicast packets can appear since c5c23260
      ("bridge: Add multicast_querier toggle and disable queries by default")
      in particular.
      
      With this patch we are flooding multicast packets if our querier is
      disabled and if we didn't detect any other querier.
      
      A grace period of the Maximum Response Delay of the querier is added to
      give multicast responses enough time to arrive and to be learned from
      before disabling the flooding behaviour again.
      Signed-off-by: NLinus Lüssing <linus.luessing@web.de>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      b00589af
  12. 27 7月, 2013 1 次提交
  13. 24 7月, 2013 1 次提交
  14. 20 7月, 2013 1 次提交
  15. 15 7月, 2013 1 次提交
  16. 07 7月, 2013 1 次提交
    • C
      bridge: fix some kernel warning in multicast timer · c7e8e8a8
      Cong Wang 提交于
      Several people reported the warning: "kernel BUG at kernel/timer.c:729!"
      and the stack trace is:
      
      	#7 [ffff880214d25c10] mod_timer+501 at ffffffff8106d905
      	#8 [ffff880214d25c50] br_multicast_del_pg.isra.20+261 at ffffffffa0731d25 [bridge]
      	#9 [ffff880214d25c80] br_multicast_disable_port+88 at ffffffffa0732948 [bridge]
      	#10 [ffff880214d25cb0] br_stp_disable_port+154 at ffffffffa072bcca [bridge]
      	#11 [ffff880214d25ce8] br_device_event+520 at ffffffffa072a4e8 [bridge]
      	#12 [ffff880214d25d18] notifier_call_chain+76 at ffffffff8164aafc
      	#13 [ffff880214d25d50] raw_notifier_call_chain+22 at ffffffff810858f6
      	#14 [ffff880214d25d60] call_netdevice_notifiers+45 at ffffffff81536aad
      	#15 [ffff880214d25d80] dev_close_many+183 at ffffffff81536d17
      	#16 [ffff880214d25dc0] rollback_registered_many+168 at ffffffff81537f68
      	#17 [ffff880214d25de8] rollback_registered+49 at ffffffff81538101
      	#18 [ffff880214d25e10] unregister_netdevice_queue+72 at ffffffff815390d8
      	#19 [ffff880214d25e30] __tun_detach+272 at ffffffffa074c2f0 [tun]
      	#20 [ffff880214d25e88] tun_chr_close+45 at ffffffffa074c4bd [tun]
      	#21 [ffff880214d25ea8] __fput+225 at ffffffff8119b1f1
      	#22 [ffff880214d25ef0] ____fput+14 at ffffffff8119b3fe
      	#23 [ffff880214d25f00] task_work_run+159 at ffffffff8107cf7f
      	#24 [ffff880214d25f30] do_notify_resume+97 at ffffffff810139e1
      	#25 [ffff880214d25f50] int_signal+18 at ffffffff8164f292
      
      this is due to I forgot to check if mp->timer is armed in
      br_multicast_del_pg(). This bug is introduced by
      commit 9f00b2e7 (bridge: only expire the mdb entry
      when query is received).
      
      Same for __br_mdb_del().
      Tested-by: Npoma <pomidorabelisima@gmail.com>
      Reported-by: NLiYonghua <809674045@qq.com>
      Reported-by: NRobert Hancock <hancockrwd@gmail.com>
      Cc: Herbert Xu <herbert@gondor.apana.org.au>
      Cc: Stephen Hemminger <stephen@networkplumber.org>
      Cc: "David S. Miller" <davem@davemloft.net>
      Signed-off-by: NCong Wang <amwang@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      c7e8e8a8
  17. 26 6月, 2013 1 次提交
  18. 24 6月, 2013 1 次提交
  19. 18 6月, 2013 1 次提交
  20. 13 6月, 2013 1 次提交
  21. 11 6月, 2013 2 次提交
  22. 29 5月, 2013 1 次提交
  23. 24 5月, 2013 1 次提交
  24. 23 5月, 2013 5 次提交
  25. 15 5月, 2013 1 次提交
  26. 04 5月, 2013 1 次提交
  27. 01 5月, 2013 1 次提交
  28. 29 4月, 2013 1 次提交
  29. 20 4月, 2013 3 次提交