1. 01 11月, 2017 1 次提交
  2. 05 8月, 2017 1 次提交
  3. 04 8月, 2017 1 次提交
  4. 12 7月, 2017 1 次提交
  5. 08 7月, 2017 1 次提交
    • Y
      net: hns: Fix a skb used after free bug · 27463ad9
      Yunsheng Lin 提交于
      skb maybe freed in hns_nic_net_xmit_hw() and return NETDEV_TX_OK,
      which cause hns_nic_net_xmit to use a freed skb.
      
      BUG: KASAN: use-after-free in hns_nic_net_xmit_hw+0x62c/0x940...
      	[17659.112635]      alloc_debug_processing+0x18c/0x1a0
      	[17659.117208]      __slab_alloc+0x52c/0x560
      	[17659.120909]      kmem_cache_alloc_node+0xac/0x2c0
      	[17659.125309]      __alloc_skb+0x6c/0x260
      	[17659.128837]      tcp_send_ack+0x8c/0x280
      	[17659.132449]      __tcp_ack_snd_check+0x9c/0xf0
      	[17659.136587]      tcp_rcv_established+0x5a4/0xa70
      	[17659.140899]      tcp_v4_do_rcv+0x27c/0x620
      	[17659.144687]      tcp_prequeue_process+0x108/0x170
      	[17659.149085]      tcp_recvmsg+0x940/0x1020
      	[17659.152787]      inet_recvmsg+0x124/0x180
      	[17659.156488]      sock_recvmsg+0x64/0x80
      	[17659.160012]      SyS_recvfrom+0xd8/0x180
      	[17659.163626]      __sys_trace_return+0x0/0x4
      	[17659.167506] INFO: Freed in kfree_skbmem+0xa0/0xb0 age=23 cpu=1 pid=13
      	[17659.174000]      free_debug_processing+0x1d4/0x2c0
      	[17659.178486]      __slab_free+0x240/0x390
      	[17659.182100]      kmem_cache_free+0x24c/0x270
      	[17659.186062]      kfree_skbmem+0xa0/0xb0
      	[17659.189587]      __kfree_skb+0x28/0x40
      	[17659.193025]      napi_gro_receive+0x168/0x1c0
      	[17659.197074]      hns_nic_rx_up_pro+0x58/0x90
      	[17659.201038]      hns_nic_rx_poll_one+0x518/0xbc0
      	[17659.205352]      hns_nic_common_poll+0x94/0x140
      	[17659.209576]      net_rx_action+0x458/0x5e0
      	[17659.213363]      __do_softirq+0x1b8/0x480
      	[17659.217062]      run_ksoftirqd+0x64/0x80
      	[17659.220679]      smpboot_thread_fn+0x224/0x310
      	[17659.224821]      kthread+0x150/0x170
      	[17659.228084]      ret_from_fork+0x10/0x40
      
      	BUG: KASAN: use-after-free in hns_nic_net_xmit+0x8c/0xc0...
      	[17751.080490]      __slab_alloc+0x52c/0x560
      	[17751.084188]      kmem_cache_alloc+0x244/0x280
      	[17751.088238]      __build_skb+0x40/0x150
      	[17751.091764]      build_skb+0x28/0x100
      	[17751.095115]      __alloc_rx_skb+0x94/0x150
      	[17751.098900]      __napi_alloc_skb+0x34/0x90
      	[17751.102776]      hns_nic_rx_poll_one+0x180/0xbc0
      	[17751.107097]      hns_nic_common_poll+0x94/0x140
      	[17751.111333]      net_rx_action+0x458/0x5e0
      	[17751.115123]      __do_softirq+0x1b8/0x480
      	[17751.118823]      run_ksoftirqd+0x64/0x80
      	[17751.122437]      smpboot_thread_fn+0x224/0x310
      	[17751.126575]      kthread+0x150/0x170
      	[17751.129838]      ret_from_fork+0x10/0x40
      	[17751.133454] INFO: Freed in kfree_skbmem+0xa0/0xb0 age=19 cpu=7 pid=43
      	[17751.139951]      free_debug_processing+0x1d4/0x2c0
      	[17751.144436]      __slab_free+0x240/0x390
      	[17751.148051]      kmem_cache_free+0x24c/0x270
      	[17751.152014]      kfree_skbmem+0xa0/0xb0
      	[17751.155543]      __kfree_skb+0x28/0x40
      	[17751.159022]      napi_gro_receive+0x168/0x1c0
      	[17751.163074]      hns_nic_rx_up_pro+0x58/0x90
      	[17751.167041]      hns_nic_rx_poll_one+0x518/0xbc0
      	[17751.171358]      hns_nic_common_poll+0x94/0x140
      	[17751.175585]      net_rx_action+0x458/0x5e0
      	[17751.179373]      __do_softirq+0x1b8/0x480
      	[17751.183076]      run_ksoftirqd+0x64/0x80
      	[17751.186691]      smpboot_thread_fn+0x224/0x310
      	[17751.190826]      kthread+0x150/0x170
      	[17751.194093]      ret_from_fork+0x10/0x40
      
      Fixes: 13ac695e ("net:hns: Add support of Hip06 SoC to the Hislicon Network Subsystem")
      Signed-off-by: NYunsheng Lin <linyunsheng@huawei.com>
      Signed-off-by: Nlipeng <lipeng321@huawei.com>
      Reported-by: NJun He <hjat2005@huawei.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      27463ad9
  6. 04 4月, 2017 5 次提交
  7. 11 2月, 2017 1 次提交
  8. 04 2月, 2017 1 次提交
    • A
      hns_enet: use cpumask_var_t for on-stack mask · ff3edc9b
      Arnd Bergmann 提交于
      On large SMP builds, we can run into a build warning:
      
      drivers/net/ethernet/hisilicon/hns/hns_enet.c: In function 'hns_set_irq_affinity.isra.27':
      drivers/net/ethernet/hisilicon/hns/hns_enet.c:1242:1: warning: the frame size of 1032 bytes is larger than 1024 bytes [-Wframe-larger-than=]
      
      The solution here is to use cpumask_var_t, which can use dynamic
      allocation when CONFIG_CPUMASK_OFFSTACK is enabled.
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      ff3edc9b
  9. 19 1月, 2017 1 次提交
    • T
      net: Remove usage of net_device last_rx member · 4a7c9726
      Tobias Klauser 提交于
      The network stack no longer uses the last_rx member of struct net_device
      since the bonding driver switched to use its own private last_rx in
      commit 9f242738 ("bonding: use last_arp_rx in slave_last_rx()").
      
      However, some drivers still (ab)use the field for their own purposes and
      some driver just update it without actually using it.
      
      Previously, there was an accompanying comment for the last_rx member
      added in commit 4dc89133 ("net: add a comment on netdev->last_rx")
      which asked drivers not to update is, unless really needed. However,
      this commend was removed in commit f8ff080d ("bonding: remove
      useless updating of slave->dev->last_rx"), so some drivers added later
      on still did update last_rx.
      
      Remove all usage of last_rx and switch three drivers (sky2, atp and
      smc91c92_cs) which actually read and write it to use their own private
      copy in netdev_priv.
      
      Compile-tested with allyesconfig and allmodconfig on x86 and arm.
      
      Cc: Eric Dumazet <eric.dumazet@gmail.com>
      Cc: Jay Vosburgh <j.vosburgh@gmail.com>
      Cc: Veaceslav Falico <vfalico@gmail.com>
      Cc: Andy Gospodarek <andy@greyhouse.net>
      Cc: Mirko Lindner <mlindner@marvell.com>
      Cc: Stephen Hemminger <stephen@networkplumber.org>
      Signed-off-by: NTobias Klauser <tklauser@distanz.ch>
      Acked-by: NEric Dumazet <edumazet@google.com>
      Reviewed-by: NJay Vosburgh <jay.vosburgh@canonical.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      4a7c9726
  10. 09 1月, 2017 1 次提交
  11. 07 12月, 2016 1 次提交
    • S
      net: hns: Fix to conditionally convey RX checksum flag to stack · 862b3d20
      Salil 提交于
      This patch introduces the RX checksum function to check the
      status of the hardware calculated checksum and its error and
      appropriately convey status to the upper stack in skb->ip_summed
      field.
      
      In hardware, we only support checksum for the following
      protocols:
      1) IPv4,
      2) TCP(over IPv4 or IPv6),
      3) UDP(over IPv4 or IPv6),
      4) SCTP(over IPv4 or IPv6)
      but we support many L3(IPv4, IPv6, MPLS, PPPoE etc) and
      L4(TCP, UDP, GRE, SCTP, IGMP, ICMP etc.) protocols.
      
      Hardware limitation:
      Our present hardware RX Descriptor lacks L3/L4 checksum
      "Status & Error" bit (which usually can be used to indicate whether
      checksum was calculated by the hardware and if there was any error
      encountered during checksum calculation).
      
      Software workaround:
      We do get info within the RX descriptor about the kind of
      L3/L4 protocol coming in the packet and the error status. These
      errors might not just be checksum errors but could be related to
      version, length of IPv4, UDP, TCP etc.
      Because there is no-way of knowing if it is a L3/L4 error due
      to bad checksum or any other L3/L4 error, we will not (cannot)
      convey hardware checksum status(CHECKSUM_UNNECESSARY) for such
      cases to upper stack and will not maintain the RX L3/L4 checksum
      counters as well.
      Signed-off-by: NSalil Mehta <salil.mehta@huawei.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      862b3d20
  12. 11 11月, 2016 2 次提交
  13. 18 10月, 2016 1 次提交
    • J
      ethernet: use core min/max MTU checking · 44770e11
      Jarod Wilson 提交于
      et131x: min_mtu 64, max_mtu 9216
      
      altera_tse: min_mtu 64, max_mtu 1500
      
      amd8111e: min_mtu 60, max_mtu 9000
      
      bnad: min_mtu 46, max_mtu 9000
      
      macb: min_mtu 68, max_mtu 1500 or 10240 depending on hardware capability
      
      xgmac: min_mtu 46, max_mtu 9000
      
      cxgb2: min_mtu 68, max_mtu 9582 (pm3393) or 9600 (vsc7326)
      
      enic: min_mtu 68, max_mtu 9000
      
      gianfar: min_mtu 50, max_mu 9586
      
      hns_enet: min_mtu 68, max_mtu 9578 (v1) or 9706 (v2)
      
      ksz884x: min_mtu 60, max_mtu 1894
      
      myri10ge: min_mtu 68, max_mtu 9000
      
      natsemi: min_mtu 64, max_mtu 2024
      
      nfp: min_mtu 68, max_mtu hardware-specific
      
      forcedeth: min_mtu 64, max_mtu 1500 or 9100, depending on hardware
      
      pch_gbe: min_mtu 46, max_mtu 10300
      
      pasemi_mac: min_mtu 64, max_mtu 9000
      
      qcaspi: min_mtu 46, max_mtu 1500
      - remove qcaspi_netdev_change_mtu as it is now redundant
      
      rocker: min_mtu 68, max_mtu 9000
      
      sxgbe: min_mtu 68, max_mtu 9000
      
      stmmac: min_mtu 46, max_mtu depends on hardware
      
      tehuti: min_mtu 60, max_mtu 16384
      - driver had no max mtu checking, but product docs say 16k jumbo packets
        are supported by the hardware
      
      netcp: min_mtu 68, max_mtu 9486
      - remove netcp_ndo_change_mtu as it is now redundant
      
      via-velocity: min_mtu 64, max_mtu 9000
      
      octeon: min_mtu 46, max_mtu 65370
      
      CC: netdev@vger.kernel.org
      CC: Mark Einon <mark.einon@gmail.com>
      CC: Vince Bridgers <vbridger@opensource.altera.com>
      CC: Rasesh Mody <rasesh.mody@qlogic.com>
      CC: Nicolas Ferre <nicolas.ferre@atmel.com>
      CC: Santosh Raspatur <santosh@chelsio.com>
      CC: Hariprasad S <hariprasad@chelsio.com>
      CC:  Christian Benvenuti <benve@cisco.com>
      CC: Sujith Sankar <ssujith@cisco.com>
      CC: Govindarajulu Varadarajan <_govind@gmx.com>
      CC: Neel Patel <neepatel@cisco.com>
      CC: Claudiu Manoil <claudiu.manoil@freescale.com>
      CC: Yisen Zhuang <yisen.zhuang@huawei.com>
      CC: Salil Mehta <salil.mehta@huawei.com>
      CC: Hyong-Youb Kim <hykim@myri.com>
      CC: Jakub Kicinski <jakub.kicinski@netronome.com>
      CC: Olof Johansson <olof@lixom.net>
      CC: Jiri Pirko <jiri@resnulli.us>
      CC: Byungho An <bh74.an@samsung.com>
      CC: Girish K S <ks.giri@samsung.com>
      CC: Vipul Pandya <vipul.pandya@samsung.com>
      CC: Giuseppe Cavallaro <peppe.cavallaro@st.com>
      CC: Alexandre Torgue <alexandre.torgue@st.com>
      CC: Andy Gospodarek <andy@greyhouse.net>
      CC: Wingman Kwok <w-kwok2@ti.com>
      CC: Murali Karicheri <m-karicheri2@ti.com>
      CC: Francois Romieu <romieu@fr.zoreil.com>
      Signed-off-by: NJarod Wilson <jarod@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      44770e11
  14. 03 10月, 2016 5 次提交
  15. 22 9月, 2016 1 次提交
  16. 02 7月, 2016 1 次提交
  17. 21 6月, 2016 7 次提交
  18. 05 6月, 2016 4 次提交
  19. 05 5月, 2016 1 次提交
  20. 26 4月, 2016 1 次提交
    • Y
      net: hns: add attribute port-idx-in-ae in enet node. · 406adee9
      Yisen.Zhuang\(Zhuangyuzeng\) 提交于
      This patch parse port-idx-in-ae in enet node. In NIC mode of DSAF, all 6
      PHYs of service DSAF are taken as ethernet ports to the CPU. The
      port-idx-in-ae can be 0 to 5. Here is the diagram:
                  +-----+---------------+
                  |            CPU      |
                  +-+-+-+---+-+-+-+-+-+-+
                    |    |   | | | | | |
                 debug debug   service
                 port  port     port
                 (0)   (0)     (0-5)
      
      In Switch mode of DSAF, all 6 PHYs of service DSAF are taken as physical
      ports connect to a LAN Switch while the CPU side assume itself have one
      single NIC connect to this switch. In this case, the port-idx-in-ae will
      be 0 only.
                  +-----+-----+------+------+
                  |                CPU      |
                  +-+-+-+-+-+-+-+-+-+-+-+-+-+
                    |    |     service| port(0)
                  debug debug  +------------+
                  port  port   |   switch   |
                  (0)   (0)    +-+-+-+-+-+-++
                                | | | | | |
                               external port
      
      when port-idx-in-ae is not exists, old attribute port-id will be used
      (only for compatible purpose, not recommended to use port-id in new code).
      Signed-off-by: NDaode Huang <huangdaode@hisilicon.com>
      Signed-off-by: NYisen Zhuang <yisen.zhuang@huawei.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      406adee9
  21. 25 3月, 2016 2 次提交