1. 24 2月, 2021 1 次提交
  2. 21 1月, 2021 1 次提交
  3. 05 12月, 2020 1 次提交
  4. 24 11月, 2020 2 次提交
  5. 18 11月, 2020 1 次提交
    • X
      net: wan: Delete the DLCI / SDLA drivers · f7365919
      Xie He 提交于
      The DLCI driver (dlci.c) implements the Frame Relay protocol. However,
      we already have another newer and better implementation of Frame Relay
      provided by the HDLC_FR driver (hdlc_fr.c).
      
      The DLCI driver's implementation of Frame Relay is used by only one
      hardware driver in the kernel - the SDLA driver (sdla.c).
      
      The SDLA driver provides Frame Relay support for the Sangoma S50x devices.
      However, the vendor provides their own driver (along with their own
      multi-WAN-protocol implementations including Frame Relay), called WANPIPE.
      I believe most users of the hardware would use the vendor-provided WANPIPE
      driver instead.
      
      (The WANPIPE driver was even once in the kernel, but was deleted in
      commit 8db60bcf ("[WAN]: Remove broken and unmaintained Sangoma
      drivers.") because the vendor no longer updated the in-kernel WANPIPE
      driver.)
      
      Cc: Mike McLagan <mike.mclagan@linux.org>
      Signed-off-by: NXie He <xie.he.0141@gmail.com>
      Link: https://lore.kernel.org/r/20201114150921.685594-1-xie.he.0141@gmail.comSigned-off-by: NJakub Kicinski <kuba@kernel.org>
      f7365919
  6. 03 10月, 2020 1 次提交
    • C
      net: add WARN_ONCE in kernel_sendpage() for improper zero-copy send · 7b62d31d
      Coly Li 提交于
      If a page sent into kernel_sendpage() is a slab page or it doesn't have
      ref_count, this page is improper to send by the zero copy sendpage()
      method. Otherwise such page might be unexpected released in network code
      path and causes impredictable panic due to kernel memory management data
      structure corruption.
      
      This path adds a WARN_ON() on the sending page before sends it into the
      concrete zero-copy sendpage() method, if the page is improper for the
      zero-copy sendpage() method, a warning message can be observed before
      the consequential unpredictable kernel panic.
      
      This patch does not change existing kernel_sendpage() behavior for the
      improper page zero-copy send, it just provides hint warning message for
      following potential panic due the kernel memory heap corruption.
      Signed-off-by: NColy Li <colyli@suse.de>
      Cc: Cong Wang <amwang@redhat.com>
      Cc: Christoph Hellwig <hch@lst.de>
      Cc: David S. Miller <davem@davemloft.net>
      Cc: Sridhar Samudrala <sri@us.ibm.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      7b62d31d
  7. 27 8月, 2020 1 次提交
  8. 25 8月, 2020 1 次提交
  9. 11 8月, 2020 1 次提交
  10. 09 8月, 2020 4 次提交
  11. 29 7月, 2020 1 次提交
  12. 25 7月, 2020 3 次提交
  13. 20 7月, 2020 4 次提交
  14. 14 7月, 2020 1 次提交
  15. 05 7月, 2020 1 次提交
  16. 30 5月, 2020 1 次提交
  17. 28 5月, 2020 1 次提交
  18. 19 5月, 2020 2 次提交
  19. 12 5月, 2020 1 次提交
    • C
      net: cleanly handle kernel vs user buffers for ->msg_control · 1f466e1f
      Christoph Hellwig 提交于
      The msg_control field in struct msghdr can either contain a user
      pointer when used with the recvmsg system call, or a kernel pointer
      when used with sendmsg.  To complicate things further kernel_recvmsg
      can stuff a kernel pointer in and then use set_fs to make the uaccess
      helpers accept it.
      
      Replace it with a union of a kernel pointer msg_control field, and
      a user pointer msg_control_user one, and allow kernel_recvmsg operate
      on a proper kernel pointer using a bitfield to override the normal
      choice of a user pointer for recvmsg.
      Signed-off-by: NChristoph Hellwig <hch@lst.de>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      1f466e1f
  20. 20 3月, 2020 1 次提交
  21. 10 3月, 2020 1 次提交
  22. 09 1月, 2020 1 次提交
  23. 13 12月, 2019 1 次提交
  24. 11 12月, 2019 1 次提交
  25. 07 12月, 2019 1 次提交
  26. 03 12月, 2019 2 次提交
  27. 27 11月, 2019 2 次提交
  28. 26 11月, 2019 1 次提交