1. 26 Oct, 2019 2 commits
    • Vincent Prince's avatar
      net: sch_generic: Use pfifo_fast as fallback scheduler for CAN hardware · 546b85bb
      Vincent Prince authored
      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: default avatarMarc Kleine-Budde <mkl@pengutronix.de>
      Signed-off-by: default avatarMarc Kleine-Budde <mkl@pengutronix.de>
      Signed-off-by: default avatarVincent Prince <vincent.prince.fr@gmail.com>
      Acked-by: default avatarDave Taht <dave.taht@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      546b85bb
    • Hayes Wang's avatar
      r8152: check the pointer rtl_fw->fw before using it · 8e484ebb
      Hayes Wang authored
      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: default avatarMarek Szyprowski <m.szyprowski@samsung.com>
      Tested-by: default avatarMarek Szyprowski <m.szyprowski@samsung.com>
      Signed-off-by: default avatarHayes Wang <hayeswang@realtek.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      8e484ebb
  2. 24 Oct, 2019 30 commits
  3. 22 Oct, 2019 8 commits