1. 08 4月, 2015 9 次提交
  2. 07 4月, 2015 4 次提交
  3. 05 4月, 2015 9 次提交
  4. 04 4月, 2015 12 次提交
  5. 03 4月, 2015 6 次提交
    • W
      ip6mr: call del_timer_sync() in ip6mr_free_table() · 7ba0c47c
      WANG Cong 提交于
      We need to wait for the flying timers, since we
      are going to free the mrtable right after it.
      
      Cc: Hannes Frederic Sowa <hannes@stressinduktion.org>
      Signed-off-by: NCong Wang <xiyou.wangcong@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      7ba0c47c
    • W
      net: move fib_rules_unregister() under rtnl lock · 419df12f
      WANG Cong 提交于
      We have to hold rtnl lock for fib_rules_unregister()
      otherwise the following race could happen:
      
      fib_rules_unregister():	fib_nl_delrule():
      ...				...
      ...				ops = lookup_rules_ops();
      list_del_rcu(&ops->list);
      				list_for_each_entry(ops->rules) {
      fib_rules_cleanup_ops(ops);	  ...
        list_del_rcu();		  list_del_rcu();
      				}
      
      Note, net->rules_mod_lock is actually not needed at all,
      either upper layer netns code or rtnl lock guarantees
      we are safe.
      
      Cc: Alexander Duyck <alexander.h.duyck@redhat.com>
      Cc: Thomas Graf <tgraf@suug.ch>
      Signed-off-by: NCong Wang <xiyou.wangcong@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      419df12f
    • W
      ipv4: take rtnl_lock and mark mrt table as freed on namespace cleanup · ed785309
      WANG Cong 提交于
      This is the IPv4 part for commit 905a6f96
      (ipv6: take rtnl_lock and mark mrt6 table as freed on namespace cleanup).
      
      Cc: Hannes Frederic Sowa <hannes@stressinduktion.org>
      Acked-by: NHannes Frederic Sowa <hannes@stressinduktion.org>
      Signed-off-by: NCong Wang <xiyou.wangcong@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      ed785309
    • N
      tcp: fix FRTO undo on cumulative ACK of SACKed range · 666b8051
      Neal Cardwell 提交于
      On processing cumulative ACKs, the FRTO code was not checking the
      SACKed bit, meaning that there could be a spurious FRTO undo on a
      cumulative ACK of a previously SACKed skb.
      
      The FRTO code should only consider a cumulative ACK to indicate that
      an original/unretransmitted skb is newly ACKed if the skb was not yet
      SACKed.
      
      The effect of the spurious FRTO undo would typically be to make the
      connection think that all previously-sent packets were in flight when
      they really weren't, leading to a stall and an RTO.
      Signed-off-by: NNeal Cardwell <ncardwell@google.com>
      Signed-off-by: NYuchung Cheng <ycheng@google.com>
      Fixes: e33099f9 ("tcp: implement RFC5682 F-RTO")
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      666b8051
    • J
      tipc: simplify link mtu negotiation · ed193ece
      Jon Paul Maloy 提交于
      When a link is being established, the two endpoints advertise their
      respective interface MTU in the transmitted RESET and ACTIVATE messages.
      If there is any difference, the lower of the two MTUs will be selected
      for use by both endpoints.
      
      However, as a remnant of earlier attempts to introduce TIPC level
      routing. there also exists an MTU discovery mechanism. If an intermediate
      node has a lower MTU than the two endpoints, they will discover this
      through a bisectional approach, and finally adopt this MTU for common use.
      
      Since there is no TIPC level routing, and probably never will be,
      this mechanism doesn't make any sense, and only serves to make the
      link level protocol unecessarily complex.
      
      In this commit, we eliminate the MTU discovery algorithm,and fall back
      to the simple MTU advertising approach. This change is fully backwards
      compatible.
      Reviewed-by: NYing Xue <ying.xue@windriver.com>
      Signed-off-by: NJon Maloy <jon.maloy@ericsson.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      ed193ece
    • J
      tipc: eliminate delayed link deletion at link failover · dff29b1a
      Jon Paul Maloy 提交于
      When a bearer is disabled manually, all its links have to be reset
      and deleted. However, if there is a remaining, parallel link ready
      to take over a deleted link's traffic, we currently delay the delete
      of the removed link until the failover procedure is finished. This
      is because the remaining link needs to access state from the reset
      link, such as the last received packet number, and any partially
      reassembled buffer, in order to perform a successful failover.
      
      In this commit, we do instead move the state data over to the new
      link, so that it can fulfill the procedure autonomously, without
      accessing any data on the old link. This means that we can now
      proceed and delete all pertaining links immediately when a bearer
      is disabled. This saves us from some unnecessary complexity in such
      situations.
      
      We also choose to change the confusing definitions CHANGEOVER_PROTOCOL,
      ORIGINAL_MSG and DUPLICATE_MSG to the more descriptive TUNNEL_PROTOCOL,
      FAILOVER_MSG and SYNCH_MSG respectively.
      Reviewed-by: NYing Xue <ying.xue@windriver.com>
      Signed-off-by: NJon Maloy <jon.maloy@ericsson.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      dff29b1a