1. 20 11月, 2017 2 次提交
  2. 19 11月, 2017 6 次提交
    • H
      r8169: use same RTL8111EVL green settings as in vendor driver · b399a394
      Heiner Kallweit 提交于
      Adjust the code to use the same green settings as in the latest
      vendor driver.
      Signed-off-by: NHeiner Kallweit <hkallweit1@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      b399a394
    • H
      r8169: fix RTL8111EVL EEE and green settings · 1814d6a8
      Heiner Kallweit 提交于
      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: NHeiner Kallweit <hkallweit1@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      1814d6a8
    • X
      tun: fix rcu_read_lock imbalance in tun_build_skb · 654d5738
      Xin Long 提交于
      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: NXin Long <lucien.xin@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      654d5738
    • N
      tcp: when scheduling TLP, time of RTO should account for current ACK · ed66dfaf
      Neal Cardwell 提交于
      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
      times.
      
      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)
                         tcp_rearm_rto(sk);
      
          2) In tcp_clean_rtx_queue(), update the RTO to now + RTO_interval:
                  if (flag & FLAG_ACKED) {
                         tcp_rearm_rto(sk);
      
          3) In tcp_ack() after tcp_fastretrans_alert() switch from RTO
             to TLP at now + RTO_interval:
                  if (icsk->icsk_pending == ICSK_TIME_RETRANS)
                         tcp_schedule_loss_probe(sk);
      
      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: NNeal Cardwell <ncardwell@google.com>
      Signed-off-by: NYuchung Cheng <ycheng@google.com>
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Acked-by: NSoheil Hassas Yeganeh <soheil@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      ed66dfaf
    • G
      usbnet: ipheth: fix potential null pointer dereference in ipheth_carrier_set · 61c59355
      Gustavo A. R. Silva 提交于
      _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
      checked.
      
      Addresses-Coverity-ID: 1462020
      Fixes: bb1b40c7 ("usbnet: ipheth: prevent TX queue timeouts when device not ready")
      Signed-off-by: NGustavo A. R. Silva <garsilva@embeddedor.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      61c59355
    • A
      gre6: use log_ecn_error module parameter in ip6_tnl_rcv() · 981542c5
      Alexey Kodanev 提交于
      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: NAlexey Kodanev <alexey.kodanev@oracle.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      981542c5
  3. 18 11月, 2017 32 次提交