1. 20 Nov, 2017 1 commit
    • Netanel Belgazal's avatar
      net: ena: fix race condition between device reset and link up setup · d18e4f68
      Netanel Belgazal authored
      In rare cases, ena driver would reset and re-start the device,
      for example, in case of misbehaving application that causes
      transmit timeout
      The first step in the reset procedure is to stop the Tx traffic by
      calling ena_carrier_off().
      After the driver have just started the device reset procedure, device
      happens to send an asynchronous notification (via AENQ) to the driver
      than there was a link change (to link-up state).
      This link change is mapped to a call to netif_carrier_on() which
      re-activates the Tx queues, violating the assumption of no tx traffic
      until device reset is completed, as the reset task might still be in
      the process of queues initialization, leading to an access to
      uninitialized memory.
      Signed-off-by: default avatarNetanel Belgazal <netanel@amazon.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
  2. 19 Nov, 2017 6 commits
    • Heiner Kallweit's avatar
      r8169: use same RTL8111EVL green settings as in vendor driver · b399a394
      Heiner Kallweit authored
      Adjust the code to use the same green settings as in the latest
      vendor driver.
      Signed-off-by: default avatarHeiner Kallweit <hkallweit1@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
    • Heiner Kallweit's avatar
      r8169: fix RTL8111EVL EEE and green settings · 1814d6a8
      Heiner Kallweit authored
      Name of functions rtl_w0w1_eri and rtl_w0w1_phy is somewhat misleading
      regarding order of arguments. One could assume that w0w1 means
      argument with bits to be reset comes before argument with bits to set.
      However this is not the case.
      So fix the order of arguments in several statements.
      In addition fix EEE advertisement. The current code resets the bits
      for 100BaseT and 1000BaseT EEE advertisement what is not what we want.
      I have a little of a hard time to find a proper "Fixes" line as the
      issue seems to have been there forever (at least it existed already
      when the driver was moved to the current place in 2011).
      The patch was tested on a Zotac Mini-PC with a RTL8111E-VL chip.
      Before the patch EEE was disabled, now it's properly advertised and
      works fine.
      Signed-off-by: default avatarHeiner Kallweit <hkallweit1@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
    • Xin Long's avatar
      tun: fix rcu_read_lock imbalance in tun_build_skb · 654d5738
      Xin Long authored
      rcu_read_lock in tun_build_skb is used to rcu_dereference tun->xdp_prog
      safely, rcu_read_unlock should be done in every return path.
      Now I could see one place missing it, where it returns NULL in switch-case
      XDP_REDIRECT,  another palce using rcu_read_lock wrongly, where it returns
      NULL in if (xdp_xmit) chunk.
      So fix both in this patch.
      Fixes: 761876c8 ("tap: XDP support")
      Signed-off-by: default avatarXin Long <lucien.xin@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
    • Neal Cardwell's avatar
      tcp: when scheduling TLP, time of RTO should account for current ACK · ed66dfaf
      Neal Cardwell authored
      Fix the TLP scheduling logic so that when scheduling a TLP probe, we
      ensure that the estimated time at which an RTO would fire accounts for
      the fact that ACKs indicating forward progress should push back RTO
      After the following fix:
      df92c839 ("tcp: fix xmit timer to only be reset if data ACKed/SACKed")
      we had an unintentional behavior change in the following kind of
      scenario: suppose the RTT variance has been very low recently. Then
      suppose we send out a flight of N packets and our RTT is 100ms:
      t=0: send a flight of N packets
      t=100ms: receive an ACK for N-1 packets
      The response before df92c839 that was:
        -> schedule a TLP for now + RTO_interval
      The response after df92c839 is:
        -> schedule a TLP for t=0 + RTO_interval
      Since RTO_interval = srtt + RTT_variance, this means that we have
      scheduled a TLP timer at a point in the future that only accounts for
      RTT_variance. If the RTT_variance term is small, this means that the
      timer fires soon.
      Before df92c839 this would not happen, because in that code, when
      we receive an ACK for a prefix of flight, we did:
          1) Near the top of tcp_ack(), switch from TLP timer to RTO
             at write_queue_head->paket_tx_time + RTO_interval:
                  if (icsk->icsk_pending == ICSK_TIME_LOSS_PROBE)
          2) In tcp_clean_rtx_queue(), update the RTO to now + RTO_interval:
                  if (flag & FLAG_ACKED) {
          3) In tcp_ack() after tcp_fastretrans_alert() switch from RTO
             to TLP at now + RTO_interval:
                  if (icsk->icsk_pending == ICSK_TIME_RETRANS)
      In df92c839 we removed that 3-phase dance, and instead directly
      set the TLP timer once: we set the TLP timer in cases like this to
      write_queue_head->packet_tx_time + RTO_interval. So if the RTT
      variance is small, then this means that this is setting the TLP timer
      to fire quite soon. This means if the ACK for the tail of the flight
      takes longer than an RTT to arrive (often due to delayed ACKs), then
      the TLP timer fires too quickly.
      Fixes: df92c839 ("tcp: fix xmit timer to only be reset if data ACKed/SACKed")
      Signed-off-by: default avatarNeal Cardwell <ncardwell@google.com>
      Signed-off-by: default avatarYuchung Cheng <ycheng@google.com>
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Acked-by: default avatarSoheil Hassas Yeganeh <soheil@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
    • Gustavo A. R. Silva's avatar
      usbnet: ipheth: fix potential null pointer dereference in ipheth_carrier_set · 61c59355
      Gustavo A. R. Silva authored
      _dev_ is being dereferenced before it is null checked, hence there
      is a potential null pointer dereference.
      Fix this by moving the pointer dereference after _dev_ has been null
      Addresses-Coverity-ID: 1462020
      Fixes: bb1b40c7 ("usbnet: ipheth: prevent TX queue timeouts when device not ready")
      Signed-off-by: default avatarGustavo A. R. Silva <garsilva@embeddedor.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
    • Alexey Kodanev's avatar
      gre6: use log_ecn_error module parameter in ip6_tnl_rcv() · 981542c5
      Alexey Kodanev authored
      After commit 308edfdf ("gre6: Cleanup GREv6 receive path, call
      common GRE functions") it's not used anywhere in the module, but
      previously was used in ip6gre_rcv().
      Fixes: 308edfdf ("gre6: Cleanup GREv6 receive path, call common GRE functions")
      Signed-off-by: default avatarAlexey Kodanev <alexey.kodanev@oracle.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
  3. 18 Nov, 2017 33 commits