1. 23 6月, 2015 3 次提交
  2. 16 6月, 2015 1 次提交
    • S
      bridge: del external_learned fdbs from device on flush or ageout · b4ad7baa
      Scott Feldman 提交于
      We need to delete from offload the device externally learnded fdbs when any
      one of these events happen:
      
      1) Bridge ages out fdb.  (When bridge is doing ageing vs. device doing
      ageing.  If device is doing ageing, it would send SWITCHDEV_FDB_DEL
      directly).
      
      2) STP state change flushes fdbs on port.
      
      3) User uses sysfs interface to flush fdbs from bridge or bridge port:
      
      	echo 1 >/sys/class/net/BR_DEV/bridge/flush
      	echo 1 >/sys/class/net/BR_PORT/brport/flush
      
      4) Offload driver send event SWITCHDEV_FDB_DEL to delete fdb entry.
      
      For rocker, we can now get called to delete fdb entry in wait and nowait
      contexts, so set NOWAIT flag when deleting fdb entry.
      Signed-off-by: NScott Feldman <sfeldma@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      b4ad7baa
  3. 13 6月, 2015 1 次提交
  4. 12 6月, 2015 2 次提交
    • D
      iommu/vt-d: Only enable extended context tables if PASID is supported · c83b2f20
      David Woodhouse 提交于
      Although the extended tables are theoretically a completely orthogonal
      feature to PASID and anything else that *uses* the newly-available bits,
      some of the early hardware has problems even when all we do is enable
      them and use only the same bits that were in the old context tables.
      
      For now, there's no motivation to support extended tables unless we're
      going to use PASID support to do SVM. So just don't use them unless
      PASID support is advertised too. Also add a command-line bailout just in
      case later chips also have issues.
      
      The equivalent problem for PASID support has already been fixed with the
      upcoming VT-d spec update and commit bd00c606 ("iommu/vt-d: Change
      PASID support to bit 40 of Extended Capability Register"), because the
      problematic platforms use the old definition of the PASID-capable bit,
      which is now marked as reserved and meaningless.
      
      So with this change, we'll magically start using ECS again only when we
      see the new hardware advertising "hey, we have PASID support and we
      actually tested it this time" on bit 40.
      
      The VT-d hardware architect has promised that we are not going to have
      any reason to support ECS *without* PASID any time soon, and he'll make
      sure he checks with us before changing that.
      
      In the future, if hypothetical new features also use new bits in the
      context tables and can be seen on implementations *without* PASID support,
      we might need to add their feature bits to the ecs_enabled() macro.
      Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>
      c83b2f20
    • V
      NFC: nfcmrvl: add UART driver · e097dc62
      Vincent Cuissard 提交于
      Add support of Marvell NFC chip controlled over UART
      Signed-off-by: NVincent Cuissard <cuissard@marvell.com>
      Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>
      e097dc62
  5. 11 6月, 2015 1 次提交
  6. 10 6月, 2015 1 次提交
  7. 09 6月, 2015 3 次提交
  8. 04 6月, 2015 5 次提交
  9. 31 5月, 2015 3 次提交
  10. 30 5月, 2015 2 次提交
  11. 28 5月, 2015 1 次提交
    • E
      tcp/dccp: try to not exhaust ip_local_port_range in connect() · 07f4c900
      Eric Dumazet 提交于
      A long standing problem on busy servers is the tiny available TCP port
      range (/proc/sys/net/ipv4/ip_local_port_range) and the default
      sequential allocation of source ports in connect() system call.
      
      If a host is having a lot of active TCP sessions, chances are
      very high that all ports are in use by at least one flow,
      and subsequent bind(0) attempts fail, or have to scan a big portion of
      space to find a slot.
      
      In this patch, I changed the starting point in __inet_hash_connect()
      so that we try to favor even [1] ports, leaving odd ports for bind()
      users.
      
      We still perform a sequential search, so there is no guarantee, but
      if connect() targets are very different, end result is we leave
      more ports available to bind(), and we spread them all over the range,
      lowering time for both connect() and bind() to find a slot.
      
      This strategy only works well if /proc/sys/net/ipv4/ip_local_port_range
      is even, ie if start/end values have different parity.
      
      Therefore, default /proc/sys/net/ipv4/ip_local_port_range was changed to
      32768 - 60999 (instead of 32768 - 61000)
      
      There is no change on security aspects here, only some poor hashing
      schemes could be eventually impacted by this change.
      
      [1] : The odd/even property depends on ip_local_port_range values parity
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      07f4c900
  12. 27 5月, 2015 1 次提交
  13. 26 5月, 2015 1 次提交
  14. 23 5月, 2015 6 次提交
  15. 20 5月, 2015 1 次提交
    • D
      tcp: add rfc3168, section 6.1.1.1. fallback · 49213555
      Daniel Borkmann 提交于
      This work as a follow-up of commit f7b3bec6 ("net: allow setting ecn
      via routing table") and adds RFC3168 section 6.1.1.1. fallback for outgoing
      ECN connections. In other words, this work adds a retry with a non-ECN
      setup SYN packet, as suggested from the RFC on the first timeout:
      
        [...] A host that receives no reply to an ECN-setup SYN within the
        normal SYN retransmission timeout interval MAY resend the SYN and
        any subsequent SYN retransmissions with CWR and ECE cleared. [...]
      
      Schematic client-side view when assuming the server is in tcp_ecn=2 mode,
      that is, Linux default since 2009 via commit 255cac91 ("tcp: extend
      ECN sysctl to allow server-side only ECN"):
      
       1) Normal ECN-capable path:
      
          SYN ECE CWR ----->
                      <----- SYN ACK ECE
                  ACK ----->
      
       2) Path with broken middlebox, when client has fallback:
      
          SYN ECE CWR ----X crappy middlebox drops packet
                            (timeout, rtx)
                  SYN ----->
                      <----- SYN ACK
                  ACK ----->
      
      In case we would not have the fallback implemented, the middlebox drop
      point would basically end up as:
      
          SYN ECE CWR ----X crappy middlebox drops packet
                            (timeout, rtx)
          SYN ECE CWR ----X crappy middlebox drops packet
                            (timeout, rtx)
          SYN ECE CWR ----X crappy middlebox drops packet
                            (timeout, rtx)
      
      In any case, it's rather a smaller percentage of sites where there would
      occur such additional setup latency: it was found in end of 2014 that ~56%
      of IPv4 and 65% of IPv6 servers of Alexa 1 million list would negotiate
      ECN (aka tcp_ecn=2 default), 0.42% of these webservers will fail to connect
      when trying to negotiate with ECN (tcp_ecn=1) due to timeouts, which the
      fallback would mitigate with a slight latency trade-off. Recent related
      paper on this topic:
      
        Brian Trammell, Mirja Kühlewind, Damiano Boppart, Iain Learmonth,
        Gorry Fairhurst, and Richard Scheffenegger:
          "Enabling Internet-Wide Deployment of Explicit Congestion Notification."
          Proc. PAM 2015, New York.
        http://ecn.ethz.ch/ecn-pam15.pdf
      
      Thus, when net.ipv4.tcp_ecn=1 is being set, the patch will perform RFC3168,
      section 6.1.1.1. fallback on timeout. For users explicitly not wanting this
      which can be in DC use case, we add a net.ipv4.tcp_ecn_fallback knob that
      allows for disabling the fallback.
      
      tp->ecn_flags are not being cleared in tcp_ecn_clear_syn() on output, but
      rather we let tcp_ecn_rcv_synack() take that over on input path in case a
      SYN ACK ECE was delayed. Thus a spurious SYN retransmission will not prevent
      ECN being negotiated eventually in that case.
      
      Reference: https://www.ietf.org/proceedings/92/slides/slides-92-iccrg-1.pdf
      Reference: https://www.ietf.org/proceedings/89/slides/slides-89-tsvarea-1.pdfSigned-off-by: NDaniel Borkmann <daniel@iogearbox.net>
      Signed-off-by: NFlorian Westphal <fw@strlen.de>
      Signed-off-by: NMirja Kühlewind <mirja.kuehlewind@tik.ee.ethz.ch>
      Signed-off-by: NBrian Trammell <trammell@tik.ee.ethz.ch>
      Cc: Eric Dumazet <edumazet@google.com>
      Cc: Dave That <dave.taht@gmail.com>
      Acked-by: NEric Dumazet <edumazet@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      49213555
  16. 19 5月, 2015 1 次提交
  17. 18 5月, 2015 1 次提交
  18. 16 5月, 2015 4 次提交
  19. 15 5月, 2015 1 次提交
    • F
      of: mdio: Add a "broken-turn-around" property · ab6016e0
      Florian Fainelli 提交于
      Some Ethernet PHY devices/switches may not properly release the MDIO bus
      during turn-around time, and fail to drive it low, which can be seen by
      some controllers as a read failure, while the data clocked in is still
      correct.
      
      Add a boolean property "broken-turn-around" which is parsed by the
      generic MDIO bus probing code and will set the corresponding bit in the
      MDIO bus phy_ignore_ta_mask bitmask for MDIO bus drivers to utilize that
      information.
      Signed-off-by: NFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      ab6016e0
  20. 14 5月, 2015 1 次提交