1. 25 May, 2017 4 commits
    • Eric Dumazet's avatar
      tcp: better validation of received ack sequences · d0e1a1b5
      Eric Dumazet authored
      Paul Fiterau Brostean reported :
      
      <quote>
      Linux TCP stack we analyze exhibits behavior that seems odd to me.
      The scenario is as follows (all packets have empty payloads, no window
      scaling, rcv/snd window size should not be a factor):
      
             TEST HARNESS (CLIENT)                        LINUX SERVER
      
         1.  -                                          LISTEN (server listen,
      then accepts)
      
         2.  - --> <SEQ=100><CTL=SYN>               --> SYN-RECEIVED
      
         3.  - <-- <SEQ=300><ACK=101><CTL=SYN,ACK>  <-- SYN-RECEIVED
      
         4.  - --> <SEQ=101><ACK=301><CTL=ACK>      --> ESTABLISHED
      
         5.  - <-- <SEQ=301><ACK=101><CTL=FIN,ACK>  <-- FIN WAIT-1 (server
      opts to close the data connection calling "close" on the connection
      socket)
      
         6.  - --> <SEQ=101><ACK=99999><CTL=FIN,ACK> --> CLOSING (client sends
      FIN,ACK with not yet sent acknowledgement number)
      
         7.  - <-- <SEQ=302><ACK=102><CTL=ACK>      <-- CLOSING (ACK is 102
      instead of 101, why?)
      
      ... (silence from CLIENT)
      
         8.  - <-- <SEQ=301><ACK=102><CTL=FIN,ACK>  <-- CLOSING
      (retransmission, again ACK is 102)
      
      Now, note that packet 6 while having the expected sequence number,
      acknowledges something that wasn't sent by the server. So I would
      expect
      the packet to maybe prompt an ACK response from the server, and then be
      ignored. Yet it is not ignored and actually leads to an increase of the
      acknowledgement number in the server's retransmission of the FIN,ACK
      packet. The explanation I found is that the FIN  in packet 6 was
      processed, despite the acknowledgement number being unacceptable.
      Further experiments indeed show that the server processes this FIN,
      transitioning to CLOSING, then on receiving an ACK for the FIN it had
      send in packet 5, the server (or better said connection) transitions
      from CLOSING to TIME_WAIT (as signaled by netstat).
      
      </quote>
      
      Indeed, tcp_rcv_state_process() calls tcp_ack() but
      does not exploit the @acceptable status but for TCP_SYN_RECV
      state.
      
      What we want here is to send a challenge ACK, if not in TCP_SYN_RECV
      state. TCP_FIN_WAIT1 state is not the only state we should fix.
      
      Add a FLAG_NO_CHALLENGE_ACK so that tcp_rcv_state_process()
      can choose to send a challenge ACK and discard the packet instead
      of wrongly change socket state.
      
      With help from Neal Cardwell.
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Reported-by: default avatarPaul Fiterau Brostean <p.fiterau-brostean@science.ru.nl>
      Cc: Neal Cardwell <ncardwell@google.com>
      Cc: Yuchung Cheng <ycheng@google.com>
      Cc: Soheil Hassas Yeganeh <soheil@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      d0e1a1b5
    • WANG Cong's avatar
      net_sched: only create filter chains for new filters/actions · 367a8ce8
      WANG Cong authored
      tcf_chain_get() always creates a new filter chain if not found
      in existing ones. This is totally unnecessary when we get or
      delete filters, new chain should be only created for new filters
      (or new actions).
      
      Fixes: 5bc17018 ("net: sched: introduce multichain support for filters")
      Cc: Jamal Hadi Salim <jhs@mojatatu.com>
      Cc: Jiri Pirko <jiri@mellanox.com>
      Signed-off-by: default avatarCong Wang <xiyou.wangcong@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      367a8ce8
    • Jiri Pirko's avatar
      net: sched: cls_api: make reclassify return all the way back to the original tp · ee538dce
      Jiri Pirko authored
      With the introduction of chain goto action, the reclassification would
      cause the re-iteration of the actual chain. It makes more sense to restart
      the whole thing and re-iterate starting from the original tp - start
      of chain 0.
      Signed-off-by: default avatarJiri Pirko <jiri@mellanox.com>
      Reviewed-by: default avatarSimon Horman <simon.horman@netronome.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      ee538dce
    • David S. Miller's avatar
      Merge tag 'mlx5-update-2017-05-23' of git://git.kernel.org/pub/scm/linux/kernel/git/mellanox/linux · abc7a4ef
      David S. Miller authored
      Saeed Mahameed says:
      
      ====================
      mlx5-update-2017-05-23
      
      First patch from Leon, came to remove the redundant usage of mlx5_vzalloc,
      and directly use kvzalloc across all mlx5 drivers.
      
      2nd patch from Noa, adds new device IDs into the supported devices list.
      
      3rd and 4th patches from Ilan are adding the basic infrastructure and
      support for Mellanox's mlx5 FPGA.
      
      Last two patches from Tariq came to modify the outdated driver version
      reported in ethtool and in mlx5_ib to more reflect the current driver state
      and remove the redundant date string reported in the version.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      abc7a4ef
  2. 24 May, 2017 20 commits
  3. 23 May, 2017 10 commits
  4. 22 May, 2017 6 commits
    • Kees Cook's avatar
      efi-pstore: Fix write/erase id tracking · c10e8031
      Kees Cook authored
      Prior to the pstore interface refactoring, the "id" generated during
      a backend pstore_write() was only retained by the internal pstore
      inode tracking list. Additionally the "part" was ignored, so EFI
      would encode this in the id. This corrects the misunderstandings
      and correctly sets "id" during pstore_write(), and uses "part"
      directly during pstore_erase().
      Reported-by: default avatarMarta Lofstedt <marta.lofstedt@intel.com>
      Fixes: 76cc9580 ("pstore: Replace arguments for write() API")
      Fixes: a61072aa ("pstore: Replace arguments for erase() API")
      Signed-off-by: default avatarKees Cook <keescook@chromium.org>
      Tested-by: default avatarMarta Lofstedt <marta.lofstedt@intel.com>
      c10e8031
    • David S. Miller's avatar
      Merge branch 'dsa-distribute-switch-events' · 1db3a610
      David S. Miller authored
      Vivien Didelot says:
      
      ====================
      net: dsa: distribute switch events
      
      DSA is by nature the support for a switch fabric, which can be composed
      of a single, or multiple interconnected Ethernet switch chips.
      
      The current DSA core behavior is to identify the slave port targeted by
      a request (e.g. adding a VLAN entry), and program the switch chip to
      which it belongs accordingly.
      
      This is problematic in a multi-chip environment, since all chips of a
      fabric must be aware of most configuration changes. Here are some
      concrete examples in a 3-chip environment:
      
               [CPU].................... (mdio)
          (eth0) |   :       :          :
                _|_____    _______    _______
               [__sw0__]--[__sw1__]--[__sw2__]
                |  |  |    |  |  |    |  |  |
                v  v  v    v  v  v    v  v  v
                p1 p2 p3   p4 p5 p6   p7 p8 p9
      
      If you add a VLAN entry on p7, sw2 gets programmed, but frames won't
      reach the CPU interface in a VLAN filtered setup. sw0 and sw1 also need
      to be programmed. The same problem comes with MAC addresses (FDB, MDB),
      or ageing time changes for instance.
      
      This patch series uses the notification chain introduced for bridging,
      to notify not only bridge, but switchdev attributes and objects events
      to all switch chips of the fabric.
      
      An ugly debug message printing the ignored event and switch info in the
      code handling the switch VLAN events would give us:
      
          # bridge vlan add dev p7 vid 42
          sw0: ignoring DSA_NOTIFIER_VLAN_ADD for sw2 (prepare phase)
          sw1: ignoring DSA_NOTIFIER_VLAN_ADD for sw2 (prepare phase)
          sw0: ignoring DSA_NOTIFIER_VLAN_ADD for sw2 (commit phase)
          sw1: ignoring DSA_NOTIFIER_VLAN_ADD for sw2 (commit phase)
      
      To achieve that, patches 1-8 change the scope of the bridge and
      switchdev callbacks from the DSA slave device to the generic DSA port,
      so that the port-wide API can be used later for switch ports not exposed
      to userspace, such as CPU and DSA links.
      
      Patches 9-15 move the DSA port specific functions in a new port.c file.
      
      Patches 16-20 introduce new events to notify the fabric about switchdev
      attributes and objects manipulation.
      
      This patch series only adds the plumbing to support a distributed
      configuration, but for the moment, each switch chip ignores events from
      other chips of the fabric, to keep the current behavior.
      
      The next patch series will add support for cross-chip configuration of
      bridge ageing time, VLAN and MAC address databases operations, etc.
      ====================
      Tested-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      1db3a610
    • Vivien Didelot's avatar
      net: dsa: add VLAN notifier · d0c627b8
      Vivien Didelot authored
      Add two new DSA_NOTIFIER_VLAN_ADD and DSA_NOTIFIER_VLAN_DEL events to
      notify not only a single switch, but all switches of a the fabric when
      an VLAN entry is added or removed.
      
      For the moment, keep the current behavior and ignore other switches.
      Signed-off-by: default avatarVivien Didelot <vivien.didelot@savoirfairelinux.com>
      Reviewed-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      d0c627b8
    • Vivien Didelot's avatar
      net: dsa: add MDB notifier · 8ae5bcdc
      Vivien Didelot authored
      Add two new DSA_NOTIFIER_MDB_ADD and DSA_NOTIFIER_MDB_DEL events to
      notify not only a single switch, but all switches of a the fabric when
      an MDB entry is added or removed.
      
      For the moment, keep the current behavior and ignore other switches.
      Signed-off-by: default avatarVivien Didelot <vivien.didelot@savoirfairelinux.com>
      Reviewed-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      8ae5bcdc
    • Vivien Didelot's avatar
      net: dsa: add FDB notifier · 685fb6a4
      Vivien Didelot authored
      Add two new DSA_NOTIFIER_FDB_ADD and DSA_NOTIFIER_FDB_DEL events to
      notify not only a single switch, but all switches of a the fabric when
      an FDB entry is added or removed.
      
      For the moment, keep the current behavior and ignore other switches.
      Signed-off-by: default avatarVivien Didelot <vivien.didelot@savoirfairelinux.com>
      Reviewed-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      685fb6a4
    • Vivien Didelot's avatar
      net: dsa: add notifier for ageing time · 1faabf74
      Vivien Didelot authored
      This patch keeps the port-wide ageing time handling code in
      dsa_port_ageing_time, pushes the requested ageing time value in a new
      switch fabric notification, and moves the switch-wide ageing time
      handling code in dsa_switch_ageing_time.
      
      This has the effect that now not only the switch that the target port
      belongs to can be programmed, but all switches composing the switch
      fabric. For the moment, keep the current behavior and ignore other
      switches.
      Signed-off-by: default avatarVivien Didelot <vivien.didelot@savoirfairelinux.com>
      Reviewed-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      1faabf74