1. 18 6月, 2013 3 次提交
  2. 15 6月, 2013 1 次提交
  3. 14 6月, 2013 3 次提交
    • R
      net/mlx4: Add VF link state support · 948e306d
      Rony Efraim 提交于
      Add support to change the link state of VF (vPort)
      Signed-off-by: NRony Efraim <ronye@mellanox.com>
      Signed-off-by: NOr Gerlitz <ogerlitz@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      948e306d
    • R
      net/core: Add VF link state control · 1d8faf48
      Rony Efraim 提交于
      Add netlink directives and ndo entry to allow for controling
      VF link, which can be in one of three states:
      
      Auto - VF link state reflects the PF link state (default)
      
      Up - VF link state is up, traffic from VF to VF works even if
      the actual PF link is down
      
      Down - VF link state is down, no traffic from/to this VF, can be of
      use while configuring the VF
      Signed-off-by: NRony Efraim <ronye@mellanox.com>
      Signed-off-by: NOr Gerlitz <ogerlitz@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      1d8faf48
    • W
      net-rps: fixes for rps flow limit · 5f121b9a
      Willem de Bruijn 提交于
      Caught by sparse:
      - __rcu: missing annotation to sd->flow_limit
      - __user: direct access in cpumask_scnprintf
      
      Also
      - add endline character when printing bitmap if room in buffer
      - avoid bucket overflow by reducing FLOW_LIMIT_HISTORY
      
      The last item warrants some explanation. The hashtable buckets are
      subject to overflow if FLOW_LIMIT_HISTORY is larger than or equal
      to bucket size, since all packets may end up in a single bucket. The
      current (rather arbitrary) history value of 256 happens to match the
      buffer size (u8).
      
      As a result, with a single flow, the first 128 packets are accepted
      (correct), the second 128 packets dropped (correct) and then the
      history[] array has filled, so that each subsequent new packet
      causes an increment in the bucket for new_flow plus a decrement
      for old_flow: a steady state.
      
      This is fine if packets are dropped, as the steady state goes away
      as soon as a mix of traffic reappears. But, because the 256th packet
      overflowed the bucket to 0: no packets are dropped.
      
      Instead of explicitly adding an overflow check, this patch changes
      FLOW_LIMIT_HISTORY to never be able to overflow a single bucket.
      Reported-by: NFengguang Wu <fengguang.wu@intel.com>
      (first item)
      Signed-off-by: NWillem de Bruijn <willemb@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      5f121b9a
  4. 13 6月, 2013 3 次提交
    • Y
      tcp: properly send new data in fast recovery in first RTT · 85f16525
      Yuchung Cheng 提交于
      Linux sends new unset data during disorder and recovery state if all
      (suspected) lost packets have been retransmitted ( RFC5681, section
      3.2 step 1 & 2, RFC3517 section 4, NexSeg() Rule 2).  One requirement
      is to keep the receive window about twice the estimated sender's
      congestion window (tcp_rcv_space_adjust()), assuming the fast
      retransmits repair the losses in the next round trip.
      
      But currently it's not the case on the first round trip in either
      normal or Fast Open connection, beucase the initial receive window
      is identical to (expected) sender's initial congestion window. The
      fix is to double it.
      Signed-off-by: NYuchung Cheng <ycheng@google.com>
      Acked-by: NNeal Cardwell <ncardwell@google.com>
      Acked-by: NEric Dumazet <edumazet@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      85f16525
    • J
      macvtap: slient sparse warnings · d9a90a31
      Jason Wang 提交于
      This patch silents the following sparse warnings:
      
      drivers/net/macvtap.c:98:9: warning: incorrect type in assignment (different
      address spaces)
      drivers/net/macvtap.c:98:9:    expected struct macvtap_queue *<noident>
      drivers/net/macvtap.c:98:9:    got struct macvtap_queue [noderef]
      <asn:4>*<noident>
      drivers/net/macvtap.c:120:9: warning: incorrect type in assignment (different
      address spaces)
      drivers/net/macvtap.c:120:9:    expected struct macvtap_queue *<noident>
      drivers/net/macvtap.c:120:9:    got struct macvtap_queue [noderef]
      <asn:4>*<noident>
      drivers/net/macvtap.c:151:22: error: incompatible types in comparison expression
      (different address spaces)
      drivers/net/macvtap.c:233:23: error: incompatible types in comparison expression
      (different address spaces)
      drivers/net/macvtap.c:243:23: error: incompatible types in comparison expression
      (different address spaces)
      drivers/net/macvtap.c:247:15: error: incompatible types in comparison expression
      (different address spaces)
        CC [M]  drivers/net/macvtap.o
      drivers/net/macvlan.c:232:24: error: incompatible types in comparison expression
      (different address spaces)
      Signed-off-by: NJason Wang <jasowang@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      d9a90a31
    • P
      tun: Report "persist" flag to userspace · 274038f8
      Pavel Emelyanov 提交于
      The TUN_PERSIST flag is not reported at all -- both TUNGETIFF, and sysfs
      "flags" attribute skip one. Knowing whether a device is persistent or not
      is critical for checkpoint-restore, thus I propose to add the read-only
      IFF_PERSIST one for this.
      
      Setting this new IFF_PERSIST is hardly possible, as TUNSETIFF doesn't check
      for unknown flags being zero and thus there can be trash.
      Signed-off-by: NPavel Emelyanov <xemul@parallels.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      274038f8
  5. 12 6月, 2013 7 次提交
  6. 11 6月, 2013 7 次提交
  7. 08 6月, 2013 5 次提交
  8. 07 6月, 2013 1 次提交
  9. 06 6月, 2013 1 次提交
    • P
      arch, mm: Remove tlb_fast_mode() · 29eb7782
      Peter Zijlstra 提交于
      Since the introduction of preemptible mmu_gather TLB fast mode has been
      broken. TLB fast mode relies on there being absolutely no concurrency;
      it frees pages first and invalidates TLBs later.
      
      However now we can get concurrency and stuff goes *bang*.
      
      This patch removes all tlb_fast_mode() code; it was found the better
      option vs trying to patch the hole by entangling tlb invalidation with
      the scheduler.
      
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Russell King <linux@arm.linux.org.uk>
      Cc: Tony Luck <tony.luck@intel.com>
      Reported-by: NMax Filippov <jcmvbkbc@gmail.com>
      Signed-off-by: NPeter Zijlstra <peterz@infradead.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      29eb7782
  10. 05 6月, 2013 6 次提交
  11. 04 6月, 2013 3 次提交