1. 16 3月, 2021 2 次提交
    • O
      net: phylink: Fix phylink_err() function name error in phylink_major_config · d82c6c1a
      Ong Boon Leong 提交于
      if pl->mac_ops->mac_finish() failed, phylink_err should use
      "mac_finish" instead of "mac_prepare".
      
      Fixes: b7ad14c2 ("net: phylink: re-implement interface configuration with PCS")
      Signed-off-by: NOng Boon Leong <boon.leong.ong@intel.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      d82c6c1a
    • X
      net: hdlc_x25: Prevent racing between "x25_close" and "x25_xmit"/"x25_rx" · bf0ffea3
      Xie He 提交于
      "x25_close" is called by "hdlc_close" in "hdlc.c", which is called by
      hardware drivers' "ndo_stop" function.
      "x25_xmit" is called by "hdlc_start_xmit" in "hdlc.c", which is hardware
      drivers' "ndo_start_xmit" function.
      "x25_rx" is called by "hdlc_rcv" in "hdlc.c", which receives HDLC frames
      from "net/core/dev.c".
      
      "x25_close" races with "x25_xmit" and "x25_rx" because their callers race.
      
      However, we need to ensure that the LAPB APIs called in "x25_xmit" and
      "x25_rx" are called before "lapb_unregister" is called in "x25_close".
      
      This patch adds locking to ensure when "x25_xmit" and "x25_rx" are doing
      their work, "lapb_unregister" is not yet called in "x25_close".
      
      Reasons for not solving the racing between "x25_close" and "x25_xmit" by
      calling "netif_tx_disable" in "x25_close":
      1. We still need to solve the racing between "x25_close" and "x25_rx";
      2. The design of the HDLC subsystem assumes the HDLC hardware drivers
      have full control over the TX queue, and the HDLC protocol drivers (like
      this driver) have no control. Controlling the queue here in the protocol
      driver may interfere with hardware drivers' control of the queue.
      
      Fixes: 1da177e4 ("Linux-2.6.12-rc2")
      Signed-off-by: NXie He <xie.he.0141@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      bf0ffea3
  2. 15 3月, 2021 1 次提交
    • T
      net: arcnet: com20020 fix error handling · 6577b9a5
      Tong Zhang 提交于
      There are two issues when handling error case in com20020pci_probe()
      
      1. priv might be not initialized yet when calling com20020pci_remove()
      from com20020pci_probe(), since the priv is set at the very last but it
      can jump to error handling in the middle and priv remains NULL.
      2. memory leak - the net device is allocated in alloc_arcdev but not
      properly released if error happens in the middle of the big for loop
      
      [    1.529110] BUG: kernel NULL pointer dereference, address: 0000000000000008
      [    1.531447] RIP: 0010:com20020pci_remove+0x15/0x60 [com20020_pci]
      [    1.536805] Call Trace:
      [    1.536939]  com20020pci_probe+0x3f2/0x48c [com20020_pci]
      [    1.537226]  local_pci_probe+0x48/0x80
      [    1.539918]  com20020pci_init+0x3f/0x1000 [com20020_pci]
      Signed-off-by: NTong Zhang <ztong0001@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      6577b9a5
  3. 14 3月, 2021 1 次提交
  4. 13 3月, 2021 6 次提交
  5. 12 3月, 2021 13 次提交
  6. 11 3月, 2021 17 次提交