1. 30 4月, 2013 1 次提交
  2. 10 4月, 2013 5 次提交
  3. 27 3月, 2013 2 次提交
  4. 26 3月, 2013 2 次提交
  5. 25 3月, 2013 5 次提交
    • T
      SUNRPC: Add barriers to ensure read ordering in rpc_wake_up_task_queue_locked · 1166fde6
      Trond Myklebust 提交于
      We need to be careful when testing task->tk_waitqueue in
      rpc_wake_up_task_queue_locked, because it can be changed while we
      are holding the queue->lock.
      By adding appropriate memory barriers, we can ensure that it is safe to
      test task->tk_waitqueue for equality if the RPC_TASK_QUEUED bit is set.
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      Cc: stable@vger.kernel.org
      1166fde6
    • Y
      tcp: undo spurious timeout after SACK reneging · 7ebe183c
      Yuchung Cheng 提交于
      On SACK reneging the sender immediately retransmits and forces a
      timeout but disables Eifel (undo). If the (buggy) receiver does not
      drop any packet this can trigger a false slow-start retransmit storm
      driven by the ACKs of the original packets. This can be detected with
      undo and TCP timestamps.
      Signed-off-by: NYuchung Cheng <ycheng@google.com>
      Acked-by: NNeal Cardwell <ncardwell@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      7ebe183c
    • H
      bridge: fix crash when set mac address of br interface · 9b46922e
      Hong zhi guo 提交于
      When I tried to set mac address of a bridge interface to a mac
      address which already learned on this bridge, I got system hang.
      
      The cause is straight forward: function br_fdb_change_mac_address
      calls fdb_insert with NULL source nbp. Then an fdb lookup is
      performed. If an fdb entry is found and it's local, it's OK. But
      if it's not local, source is dereferenced for printk without NULL
      check.
      Signed-off-by: NHong Zhiguo <honkiko@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      9b46922e
    • C
      8021q: fix a potential use-after-free · 4a7df340
      Cong Wang 提交于
      vlan_vid_del() could possibly free ->vlan_info after a RCU grace
      period, however, we may still refer to the freed memory area
      by 'grp' pointer. Found by code inspection.
      
      This patch moves vlan_vid_del() as behind as possible.
      
      Cc: Patrick McHardy <kaber@trash.net>
      Cc: "David S. Miller" <davem@davemloft.net>
      Signed-off-by: NCong Wang <amwang@redhat.com>
      Acked-by: NEric Dumazet <edumazet@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      4a7df340
    • E
      net: remove a WARN_ON() in net_enable_timestamp() · 9979a55a
      Eric Dumazet 提交于
      The WARN_ON(in_interrupt()) in net_enable_timestamp() can get false
      positive, in socket clone path, run from softirq context :
      
      [ 3641.624425] WARNING: at net/core/dev.c:1532 net_enable_timestamp+0x7b/0x80()
      [ 3641.668811] Call Trace:
      [ 3641.671254]  <IRQ>  [<ffffffff80286817>] warn_slowpath_common+0x87/0xc0
      [ 3641.677871]  [<ffffffff8028686a>] warn_slowpath_null+0x1a/0x20
      [ 3641.683683]  [<ffffffff80742f8b>] net_enable_timestamp+0x7b/0x80
      [ 3641.689668]  [<ffffffff80732ce5>] sk_clone_lock+0x425/0x450
      [ 3641.695222]  [<ffffffff8078db36>] inet_csk_clone_lock+0x16/0x170
      [ 3641.701213]  [<ffffffff807ae449>] tcp_create_openreq_child+0x29/0x820
      [ 3641.707663]  [<ffffffff807d62e2>] ? ipt_do_table+0x222/0x670
      [ 3641.713354]  [<ffffffff807aaf5b>] tcp_v4_syn_recv_sock+0xab/0x3d0
      [ 3641.719425]  [<ffffffff807af63a>] tcp_check_req+0x3da/0x530
      [ 3641.724979]  [<ffffffff8078b400>] ? inet_hashinfo_init+0x60/0x80
      [ 3641.730964]  [<ffffffff807ade6f>] ? tcp_v4_rcv+0x79f/0xbe0
      [ 3641.736430]  [<ffffffff807ab9bd>] tcp_v4_do_rcv+0x38d/0x4f0
      [ 3641.741985]  [<ffffffff807ae14a>] tcp_v4_rcv+0xa7a/0xbe0
      
      Its safe at this point because the parent socket owns a reference
      on the netstamp_needed, so we cant have a 0 -> 1 transition, which
      requires to lock a mutex.
      
      Instead of refining the check, lets remove it, as all known callers
      are safe. If it ever changes in the future, static_key_slow_inc()
      will complain anyway.
      Reported-by: NLaurent Chavey <chavey@google.com>
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      9979a55a
  6. 22 3月, 2013 1 次提交
    • E
      tcp: preserve ACK clocking in TSO · f4541d60
      Eric Dumazet 提交于
      A long standing problem with TSO is the fact that tcp_tso_should_defer()
      rearms the deferred timer, while it should not.
      
      Current code leads to following bad bursty behavior :
      
      20:11:24.484333 IP A > B: . 297161:316921(19760) ack 1 win 119
      20:11:24.484337 IP B > A: . ack 263721 win 1117
      20:11:24.485086 IP B > A: . ack 265241 win 1117
      20:11:24.485925 IP B > A: . ack 266761 win 1117
      20:11:24.486759 IP B > A: . ack 268281 win 1117
      20:11:24.487594 IP B > A: . ack 269801 win 1117
      20:11:24.488430 IP B > A: . ack 271321 win 1117
      20:11:24.489267 IP B > A: . ack 272841 win 1117
      20:11:24.490104 IP B > A: . ack 274361 win 1117
      20:11:24.490939 IP B > A: . ack 275881 win 1117
      20:11:24.491775 IP B > A: . ack 277401 win 1117
      20:11:24.491784 IP A > B: . 316921:332881(15960) ack 1 win 119
      20:11:24.492620 IP B > A: . ack 278921 win 1117
      20:11:24.493448 IP B > A: . ack 280441 win 1117
      20:11:24.494286 IP B > A: . ack 281961 win 1117
      20:11:24.495122 IP B > A: . ack 283481 win 1117
      20:11:24.495958 IP B > A: . ack 285001 win 1117
      20:11:24.496791 IP B > A: . ack 286521 win 1117
      20:11:24.497628 IP B > A: . ack 288041 win 1117
      20:11:24.498459 IP B > A: . ack 289561 win 1117
      20:11:24.499296 IP B > A: . ack 291081 win 1117
      20:11:24.500133 IP B > A: . ack 292601 win 1117
      20:11:24.500970 IP B > A: . ack 294121 win 1117
      20:11:24.501388 IP B > A: . ack 295641 win 1117
      20:11:24.501398 IP A > B: . 332881:351881(19000) ack 1 win 119
      
      While the expected behavior is more like :
      
      20:19:49.259620 IP A > B: . 197601:202161(4560) ack 1 win 119
      20:19:49.260446 IP B > A: . ack 154281 win 1212
      20:19:49.261282 IP B > A: . ack 155801 win 1212
      20:19:49.262125 IP B > A: . ack 157321 win 1212
      20:19:49.262136 IP A > B: . 202161:206721(4560) ack 1 win 119
      20:19:49.262958 IP B > A: . ack 158841 win 1212
      20:19:49.263795 IP B > A: . ack 160361 win 1212
      20:19:49.264628 IP B > A: . ack 161881 win 1212
      20:19:49.264637 IP A > B: . 206721:211281(4560) ack 1 win 119
      20:19:49.265465 IP B > A: . ack 163401 win 1212
      20:19:49.265886 IP B > A: . ack 164921 win 1212
      20:19:49.266722 IP B > A: . ack 166441 win 1212
      20:19:49.266732 IP A > B: . 211281:215841(4560) ack 1 win 119
      20:19:49.267559 IP B > A: . ack 167961 win 1212
      20:19:49.268394 IP B > A: . ack 169481 win 1212
      20:19:49.269232 IP B > A: . ack 171001 win 1212
      20:19:49.269241 IP A > B: . 215841:221161(5320) ack 1 win 119
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Cc: Yuchung Cheng <ycheng@google.com>
      Cc: Van Jacobson <vanj@google.com>
      Cc: Neal Cardwell <ncardwell@google.com>
      Cc: Nandita Dukkipati <nanditad@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f4541d60
  7. 21 3月, 2013 16 次提交
  8. 20 3月, 2013 1 次提交
  9. 19 3月, 2013 5 次提交
    • H
      inet: limit length of fragment queue hash table bucket lists · 5a3da1fe
      Hannes Frederic Sowa 提交于
      This patch introduces a constant limit of the fragment queue hash
      table bucket list lengths. Currently the limit 128 is choosen somewhat
      arbitrary and just ensures that we can fill up the fragment cache with
      empty packets up to the default ip_frag_high_thresh limits. It should
      just protect from list iteration eating considerable amounts of cpu.
      
      If we reach the maximum length in one hash bucket a warning is printed.
      This is implemented on the caller side of inet_frag_find to distinguish
      between the different users of inet_fragment.c.
      
      I dropped the out of memory warning in the ipv4 fragment lookup path,
      because we already get a warning by the slab allocator.
      
      Cc: Eric Dumazet <eric.dumazet@gmail.com>
      Cc: Jesper Dangaard Brouer <jbrouer@redhat.com>
      Signed-off-by: NHannes Frederic Sowa <hannes@stressinduktion.org>
      Acked-by: NEric Dumazet <edumazet@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      5a3da1fe
    • J
      ipvs: remove extra rcu lock · bf93ad72
      Julian Anastasov 提交于
      In 3.7 we added code that uses ipv4_update_pmtu but after commit
      c5ae7d41 (ipv4: must use rcu protection while calling fib_lookup)
      the RCU lock is not needed.
      Signed-off-by: NJulian Anastasov <ja@ssi.bg>
      Signed-off-by: NSimon Horman <horms@verge.net.au>
      bf93ad72
    • J
      ipvs: add backup_only flag to avoid loops · 0c12582f
      Julian Anastasov 提交于
      Dmitry Akindinov is reporting for a problem where SYNs are looping
      between the master and backup server when the backup server is used as
      real server in DR mode and has IPVS rules to function as director.
      
      Even when the backup function is enabled we continue to forward
      traffic and schedule new connections when the current master is using
      the backup server as real server. While this is not a problem for NAT,
      for DR and TUN method the backup server can not determine if a request
      comes from client or from director.
      
      To avoid such loops add new sysctl flag backup_only. It can be needed
      for DR/TUN setups that do not need backup and director function at the
      same time. When the backup function is enabled we stop any forwarding
      and pass the traffic to the local stack (real server mode). The flag
      disables the director function when the backup function is enabled.
      
      For setups that enable backup function for some virtual services and
      director function for other virtual services there should be another
      more complex solution to support DR/TUN mode, may be to assign
      per-virtual service syncid value, so that we can differentiate the
      requests.
      Reported-by: NDmitry Akindinov <dimak@stalker.com>
      Tested-by: NGerman Myzovsky <lawyer@sipnet.ru>
      Signed-off-by: NJulian Anastasov <ja@ssi.bg>
      Signed-off-by: NSimon Horman <horms@verge.net.au>
      0c12582f
    • J
      ipvs: fix sctp chunk length order · cf2e3942
      Julian Anastasov 提交于
      Fix wrong but non-fatal access to chunk length.
      sch->length should be in network order, next chunk should
      be aligned to 4 bytes. Problem noticed in sparse output.
      Signed-off-by: NJulian Anastasov <ja@ssi.bg>
      Signed-off-by: NSimon Horman <horms@verge.net.au>
      cf2e3942
    • E
      tcp: dont handle MTU reduction on LISTEN socket · 0d4f0608
      Eric Dumazet 提交于
      When an ICMP ICMP_FRAG_NEEDED (or ICMPV6_PKT_TOOBIG) message finds a
      LISTEN socket, and this socket is currently owned by the user, we
      set TCP_MTU_REDUCED_DEFERRED flag in listener tsq_flags.
      
      This is bad because if we clone the parent before it had a chance to
      clear the flag, the child inherits the tsq_flags value, and next
      tcp_release_cb() on the child will decrement sk_refcnt.
      
      Result is that we might free a live TCP socket, as reported by
      Dormando.
      
      IPv4: Attempt to release TCP socket in state 1
      
      Fix this issue by testing sk_state against TCP_LISTEN early, so that we
      set TCP_MTU_REDUCED_DEFERRED on appropriate sockets (not a LISTEN one)
      
      This bug was introduced in commit 563d34d0
      (tcp: dont drop MTU reduction indications)
      Reported-by: Ndormando <dormando@rydia.net>
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      0d4f0608
  10. 18 3月, 2013 1 次提交
  11. 17 3月, 2013 1 次提交