1. 26 10月, 2019 6 次提交
    • J
      tcp: add TCP_INFO status for failed client TFO · 48027478
      Jason Baron 提交于
      The TCPI_OPT_SYN_DATA bit as part of tcpi_options currently reports whether
      or not data-in-SYN was ack'd on both the client and server side. We'd like
      to gather more information on the client-side in the failure case in order
      to indicate the reason for the failure. This can be useful for not only
      debugging TFO, but also for creating TFO socket policies. For example, if
      a middle box removes the TFO option or drops a data-in-SYN, we can
      can detect this case, and turn off TFO for these connections saving the
      extra retransmits.
      
      The newly added tcpi_fastopen_client_fail status is 2 bits and has the
      following 4 states:
      
      1) TFO_STATUS_UNSPEC
      
      Catch-all state which includes when TFO is disabled via black hole
      detection, which is indicated via LINUX_MIB_TCPFASTOPENBLACKHOLE.
      
      2) TFO_COOKIE_UNAVAILABLE
      
      If TFO_CLIENT_NO_COOKIE mode is off, this state indicates that no cookie
      is available in the cache.
      
      3) TFO_DATA_NOT_ACKED
      
      Data was sent with SYN, we received a SYN/ACK but it did not cover the data
      portion. Cookie is not accepted by server because the cookie may be invalid
      or the server may be overloaded.
      
      4) TFO_SYN_RETRANSMITTED
      
      Data was sent with SYN, we received a SYN/ACK which did not cover the data
      after at least 1 additional SYN was sent (without data). It may be the case
      that a middle-box is dropping data-in-SYN packets. Thus, it would be more
      efficient to not use TFO on this connection to avoid extra retransmits
      during connection establishment.
      
      These new fields do not cover all the cases where TFO may fail, but other
      failures, such as SYN/ACK + data being dropped, will result in the
      connection not becoming established. And a connection blackhole after
      session establishment shows up as a stalled connection.
      Signed-off-by: NJason Baron <jbaron@akamai.com>
      Cc: Eric Dumazet <edumazet@google.com>
      Cc: Neal Cardwell <ncardwell@google.com>
      Cc: Christoph Paasch <cpaasch@apple.com>
      Cc: Yuchung Cheng <ycheng@google.com>
      Acked-by: NYuchung Cheng <ycheng@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      48027478
    • D
      Merge branch 'phy-dp83867-enable-robust-auto-mdix' · 79f2056b
      David S. Miller 提交于
      Grygorii Strashko says:
      
      ====================
      net: phy: dp83867: enable robust auto-mdix
      
      Patch 1 - improves link detection when dp83867 PHY is configured in manual mode
      by enabling CFG3[9] Robust Auto-MDIX option.
      
      Patch 2 - is minor optimization.
      ====================
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      79f2056b
    • G
      net: phy: dp83867: move dt parsing to probe · ef87f7da
      Grygorii Strashko 提交于
      Move DT parsing code to probe dp83867_probe() as it's one time operation.
      Signed-off-by: NGrygorii Strashko <grygorii.strashko@ti.com>
      Reviewed-by: NAndrew Lunn <andrew@lunn.ch>
      Reviewed-by: NFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      ef87f7da
    • G
      net: phy: dp83867: enable robust auto-mdix · 5a7f08c2
      Grygorii Strashko 提交于
      The link detection timeouts can be observed (or link might not be detected
      at all) when dp83867 PHY is configured in manual mode (speed/duplex).
      
      CFG3[9] Robust Auto-MDIX option allows to significantly improve link detection
      in case dp83867 is configured in manual mode and reduce link detection
      time.
      As per DM: "If link partners are configured to operational modes that are
      not supported by normal Auto MDI/MDIX mode (like Auto-Neg versus Force
      100Base-TX or Force 100Base-TX versus Force 100Base-TX), this Robust Auto
      MDI/MDIX mode allows MDI/MDIX resolution and prevents deadlock."
      
      Hence, enable this option by default as there are no known reasons
      not to do so.
      Signed-off-by: NGrygorii Strashko <grygorii.strashko@ti.com>
      Reviewed-by: NAndrew Lunn <andrew@lunn.ch>
      Reviewed-by: NFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      5a7f08c2
    • V
      net: sch_generic: Use pfifo_fast as fallback scheduler for CAN hardware · 546b85bb
      Vincent Prince 提交于
      There is networking hardware that isn't based on Ethernet for layers 1 and 2.
      
      For example CAN.
      
      CAN is a multi-master serial bus standard for connecting Electronic Control
      Units [ECUs] also known as nodes. A frame on the CAN bus carries up to 8 bytes
      of payload. Frame corruption is detected by a CRC. However frame loss due to
      corruption is possible, but a quite unusual phenomenon.
      
      While fq_codel works great for TCP/IP, it doesn't for CAN. There are a lot of
      legacy protocols on top of CAN, which are not build with flow control or high
      CAN frame drop rates in mind.
      
      When using fq_codel, as soon as the queue reaches a certain delay based length,
      skbs from the head of the queue are silently dropped. Silently meaning that the
      user space using a send() or similar syscall doesn't get an error. However
      TCP's flow control algorithm will detect dropped packages and adjust the
      bandwidth accordingly.
      
      When using fq_codel and sending raw frames over CAN, which is the common use
      case, the user space thinks the package has been sent without problems, because
      send() returned without an error. pfifo_fast will drop skbs, if the queue
      length exceeds the maximum. But with this scheduler the skbs at the tail are
      dropped, an error (-ENOBUFS) is propagated to user space. So that the user
      space can slow down the package generation.
      
      On distributions, where fq_codel is made default via CONFIG_DEFAULT_NET_SCH
      during compile time, or set default during runtime with sysctl
      net.core.default_qdisc (see [1]), we get a bad user experience. In my test case
      with pfifo_fast, I can transfer thousands of million CAN frames without a frame
      drop. On the other hand with fq_codel there is more then one lost CAN frame per
      thousand frames.
      
      As pointed out fq_codel is not suited for CAN hardware, so this patch changes
      attach_one_default_qdisc() to use pfifo_fast for "ARPHRD_CAN" network devices.
      
      During transition of a netdev from down to up state the default queuing
      discipline is attached by attach_default_qdiscs() with the help of
      attach_one_default_qdisc(). This patch modifies attach_one_default_qdisc() to
      attach the pfifo_fast (pfifo_fast_ops) if the network device type is
      "ARPHRD_CAN".
      
      [1] https://github.com/systemd/systemd/issues/9194Suggested-by: NMarc Kleine-Budde <mkl@pengutronix.de>
      Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>
      Signed-off-by: NVincent Prince <vincent.prince.fr@gmail.com>
      Acked-by: NDave Taht <dave.taht@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      546b85bb
    • H
      r8152: check the pointer rtl_fw->fw before using it · 8e484ebb
      Hayes Wang 提交于
      Fix the pointer rtl_fw->fw would be used before checking in
      rtl8152_apply_firmware() that causes the following kernel oops.
      
      Unable to handle kernel NULL pointer dereference at virtual address 00000002
      pgd = (ptrval)
      [00000002] *pgd=00000000
      Internal error: Oops: 5 [#1] PREEMPT SMP ARM
      Modules linked in:
      CPU: 0 PID: 131 Comm: kworker/0:2 Not tainted
      5.4.0-rc1-00539-g9370f2d0 #6788
      Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
      Workqueue: events_long rtl_hw_phy_work_func_t
      PC is at rtl8152_apply_firmware+0x14/0x464
      LR is at r8153_hw_phy_cfg+0x24/0x17c
      pc : [<c064f4e4>]    lr : [<c064fa18>]    psr: a0000013
      sp : e75c9e60  ip : 60000013  fp : c11b7614
      r10: e883b91c  r9 : 00000000  r8 : fffffffe
      r7 : e883b640  r6 : fffffffe  r5 : fffffffe  r4 : e883b640
      r3 : 736cfe7c  r2 : 736cfe7c  r1 : 000052f8  r0 : e883b640
      Flags: NzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment none
      Control: 10c5387d  Table: 6640006a  DAC: 00000051
      Process kworker/0:2 (pid: 131, stack limit = 0x(ptrval))
      Stack: (0xe75c9e60 to 0xe75ca000)
      ...
      [<c064f4e4>] (rtl8152_apply_firmware) from [<c064fa18>]
      (r8153_hw_phy_cfg+0x24/0x17c)
      [<c064fa18>] (r8153_hw_phy_cfg) from [<c064e784>]
      (rtl_hw_phy_work_func_t+0x220/0x3e4)
      [<c064e784>] (rtl_hw_phy_work_func_t) from [<c0148a74>]
      (process_one_work+0x22c/0x7c8)
      [<c0148a74>] (process_one_work) from [<c0149054>] (worker_thread+0x44/0x520)
      [<c0149054>] (worker_thread) from [<c0150548>] (kthread+0x130/0x164)
      [<c0150548>] (kthread) from [<c01010b4>] (ret_from_fork+0x14/0x20)
      Exception stack(0xe75c9fb0 to 0xe75c9ff8)
      ...
      
      Fixes: 9370f2d0 ("r8152: support request_firmware for RTL8153")
      Reported-by: NMarek Szyprowski <m.szyprowski@samsung.com>
      Tested-by: NMarek Szyprowski <m.szyprowski@samsung.com>
      Signed-off-by: NHayes Wang <hayeswang@realtek.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      8e484ebb
  2. 25 10月, 2019 21 次提交
  3. 24 10月, 2019 9 次提交
  4. 23 10月, 2019 4 次提交