1. 04 Apr, 2019 8 commits
    • Yonglong Liu's avatar
      net: hns: Fix sparse: some warnings in HNS drivers · 15400663
      Yonglong Liu authored
      There are some sparse warnings in the HNS drivers:
      
      warning: incorrect type in assignment (different address spaces)
          expected void [noderef] <asn:2> *io_base
          got void *vaddr
      warning: cast removes address space '<asn:2>' of expression
      [...]
      
      Add __iomem and change all the u8 __iomem to void __iomem to
      fix these kind of  warnings.
      
      warning: incorrect type in argument 1 (different address spaces)
          expected void [noderef] <asn:2> *base
          got unsigned char [usertype] *base_addr
      warning: cast to restricted __le16
      warning: incorrect type in assignment (different base types)
          expected unsigned int [usertype] tbl_tcam_data_high
          got restricted __le32 [usertype]
      warning: cast to restricted __le32
      [...]
      
      These variables used u32/u16 as their type, and finally as a
      parameter of writel(), writel() will do the cpu_to_le32 coversion
      so remove the little endian covert code to fix these kind of warnings.
      Signed-off-by: default avatarYonglong Liu <liuyonglong@huawei.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      15400663
    • Yonglong Liu's avatar
      net: hns: Fix WARNING when remove HNS driver with SMMU enabled · 8601a99d
      Yonglong Liu authored
      When enable SMMU, remove HNS driver will cause a WARNING:
      
      [  141.924177] WARNING: CPU: 36 PID: 2708 at drivers/iommu/dma-iommu.c:443 __iommu_dma_unmap+0xc0/0xc8
      [  141.954673] Modules linked in: hns_enet_drv(-)
      [  141.963615] CPU: 36 PID: 2708 Comm: rmmod Tainted: G        W         5.0.0-rc1-28723-gb729c57de95c-dirty #32
      [  141.983593] Hardware name: Huawei D05/D05, BIOS Hisilicon D05 UEFI Nemo 1.8 RC0 08/31/2017
      [  142.000244] pstate: 60000005 (nZCv daif -PAN -UAO)
      [  142.009886] pc : __iommu_dma_unmap+0xc0/0xc8
      [  142.018476] lr : __iommu_dma_unmap+0xc0/0xc8
      [  142.027066] sp : ffff000013533b90
      [  142.033728] x29: ffff000013533b90 x28: ffff8013e6983600
      [  142.044420] x27: 0000000000000000 x26: 0000000000000000
      [  142.055113] x25: 0000000056000000 x24: 0000000000000015
      [  142.065806] x23: 0000000000000028 x22: ffff8013e66eee68
      [  142.076499] x21: ffff8013db919800 x20: 0000ffffefbff000
      [  142.087192] x19: 0000000000001000 x18: 0000000000000007
      [  142.097885] x17: 000000000000000e x16: 0000000000000001
      [  142.108578] x15: 0000000000000019 x14: 363139343a70616d
      [  142.119270] x13: 6e75656761705f67 x12: 0000000000000000
      [  142.129963] x11: 00000000ffffffff x10: 0000000000000006
      [  142.140656] x9 : 1346c1aa88093500 x8 : ffff0000114de4e0
      [  142.151349] x7 : 6662666578303d72 x6 : ffff0000105ffec8
      [  142.162042] x5 : 0000000000000000 x4 : 0000000000000000
      [  142.172734] x3 : 00000000ffffffff x2 : ffff0000114de500
      [  142.183427] x1 : 0000000000000000 x0 : 0000000000000035
      [  142.194120] Call trace:
      [  142.199030]  __iommu_dma_unmap+0xc0/0xc8
      [  142.206920]  iommu_dma_unmap_page+0x20/0x28
      [  142.215335]  __iommu_unmap_page+0x40/0x60
      [  142.223399]  hnae_unmap_buffer+0x110/0x134
      [  142.231639]  hnae_free_desc+0x6c/0x10c
      [  142.239177]  hnae_fini_ring+0x14/0x34
      [  142.246540]  hnae_fini_queue+0x2c/0x40
      [  142.254080]  hnae_put_handle+0x38/0xcc
      [  142.261619]  hns_nic_dev_remove+0x54/0xfc [hns_enet_drv]
      [  142.272312]  platform_drv_remove+0x24/0x64
      [  142.280552]  device_release_driver_internal+0x17c/0x20c
      [  142.291070]  driver_detach+0x4c/0x90
      [  142.298259]  bus_remove_driver+0x5c/0xd8
      [  142.306148]  driver_unregister+0x2c/0x54
      [  142.314037]  platform_driver_unregister+0x10/0x18
      [  142.323505]  hns_nic_dev_driver_exit+0x14/0xf0c [hns_enet_drv]
      [  142.335248]  __arm64_sys_delete_module+0x214/0x25c
      [  142.344891]  el0_svc_common+0xb0/0x10c
      [  142.352430]  el0_svc_handler+0x24/0x80
      [  142.359968]  el0_svc+0x8/0x7c0
      [  142.366104] ---[ end trace 60ad1cd58e63c407 ]---
      
      The tx ring buffer map when xmit and unmap when xmit done. So in
      hnae_init_ring() did not map tx ring buffer, but in hnae_fini_ring()
      have a unmap operation for tx ring buffer, which is already unmapped
      when xmit done, than cause this WARNING.
      
      The hnae_alloc_buffers() is called in hnae_init_ring(),
      so the hnae_free_buffers() should be in hnae_fini_ring(), not in
      hnae_free_desc().
      
      In hnae_fini_ring(), adds a check is_rx_ring() as in hnae_init_ring().
      When the ring buffer is tx ring, adds a piece of code to ensure that
      the tx ring is unmap.
      Signed-off-by: default avatarYonglong Liu <liuyonglong@huawei.com>
      Signed-off-by: default avatarPeng Li <lipeng321@huawei.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      8601a99d
    • Yonglong Liu's avatar
      net: hns: fix ICMP6 neighbor solicitation messages discard problem · f058e468
      Yonglong Liu authored
      ICMP6 neighbor solicitation messages will be discard by the Hip06
      chips, because of not setting forwarding pool. Enable promisc mode
      has the same problem.
      
      This patch fix the wrong forwarding table configs for the multicast
      vague matching when enable promisc mode, and add forwarding pool
      for the forwarding table.
      Signed-off-by: default avatarYonglong Liu <liuyonglong@huawei.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      f058e468
    • Yonglong Liu's avatar
      net: hns: Fix probabilistic memory overwrite when HNS driver initialized · c0b09844
      Yonglong Liu authored
      When reboot the system again and again, may cause a memory
      overwrite.
      
      [   15.638922] systemd[1]: Reached target Swap.
      [   15.667561] tun: Universal TUN/TAP device driver, 1.6
      [   15.676756] Bridge firewalling registered
      [   17.344135] Unable to handle kernel paging request at virtual address 0000000200000040
      [   17.352179] Mem abort info:
      [   17.355007]   ESR = 0x96000004
      [   17.358105]   Exception class = DABT (current EL), IL = 32 bits
      [   17.364112]   SET = 0, FnV = 0
      [   17.367209]   EA = 0, S1PTW = 0
      [   17.370393] Data abort info:
      [   17.373315]   ISV = 0, ISS = 0x00000004
      [   17.377206]   CM = 0, WnR = 0
      [   17.380214] user pgtable: 4k pages, 48-bit VAs, pgdp = (____ptrval____)
      [   17.386926] [0000000200000040] pgd=0000000000000000
      [   17.391878] Internal error: Oops: 96000004 [#1] SMP
      [   17.396824] CPU: 23 PID: 95 Comm: kworker/u130:0 Tainted: G            E     4.19.25-1.2.78.aarch64 #1
      [   17.414175] Hardware name: Huawei TaiShan 2280 /BC11SPCD, BIOS 1.54 08/16/2018
      [   17.425615] Workqueue: events_unbound async_run_entry_fn
      [   17.435151] pstate: 00000005 (nzcv daif -PAN -UAO)
      [   17.444139] pc : __mutex_lock.isra.1+0x74/0x540
      [   17.453002] lr : __mutex_lock.isra.1+0x3c/0x540
      [   17.461701] sp : ffff000100d9bb60
      [   17.469146] x29: ffff000100d9bb60 x28: 0000000000000000
      [   17.478547] x27: 0000000000000000 x26: ffff802fb8945000
      [   17.488063] x25: 0000000000000000 x24: ffff802fa32081a8
      [   17.497381] x23: 0000000000000002 x22: ffff801fa2b15220
      [   17.506701] x21: ffff000009809000 x20: ffff802fa23a0888
      [   17.515980] x19: ffff801fa2b15220 x18: 0000000000000000
      [   17.525272] x17: 0000000200000000 x16: 0000000200000000
      [   17.534511] x15: 0000000000000000 x14: 0000000000000000
      [   17.543652] x13: ffff000008d95db8 x12: 000000000000000d
      [   17.552780] x11: ffff000008d95d90 x10: 0000000000000b00
      [   17.561819] x9 : ffff000100d9bb90 x8 : ffff802fb89d6560
      [   17.570829] x7 : 0000000000000004 x6 : 00000004a1801d05
      [   17.579839] x5 : 0000000000000000 x4 : 0000000000000000
      [   17.588852] x3 : ffff802fb89d5a00 x2 : 0000000000000000
      [   17.597734] x1 : 0000000200000000 x0 : 0000000200000000
      [   17.606631] Process kworker/u130:0 (pid: 95, stack limit = 0x(____ptrval____))
      [   17.617438] Call trace:
      [   17.623349]  __mutex_lock.isra.1+0x74/0x540
      [   17.630927]  __mutex_lock_slowpath+0x24/0x30
      [   17.638602]  mutex_lock+0x50/0x60
      [   17.645295]  drain_workqueue+0x34/0x198
      [   17.652623]  __sas_drain_work+0x7c/0x168
      [   17.659903]  sas_drain_work+0x60/0x68
      [   17.666947]  hisi_sas_scan_finished+0x30/0x40 [hisi_sas_main]
      [   17.676129]  do_scsi_scan_host+0x70/0xb0
      [   17.683534]  do_scan_async+0x20/0x228
      [   17.690586]  async_run_entry_fn+0x4c/0x1d0
      [   17.697997]  process_one_work+0x1b4/0x3f8
      [   17.705296]  worker_thread+0x54/0x470
      
      Every time the call trace is not the same, but the overwrite address
      is always the same:
      Unable to handle kernel paging request at virtual address 0000000200000040
      
      The root cause is, when write the reg XGMAC_MAC_TX_LF_RF_CONTROL_REG,
      didn't use the io_base offset.
      Signed-off-by: default avatarYonglong Liu <liuyonglong@huawei.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      c0b09844
    • Yonglong Liu's avatar
      net: hns: Use NAPI_POLL_WEIGHT for hns driver · acb1ce15
      Yonglong Liu authored
      When the HNS driver loaded, always have an error print:
      "netif_napi_add() called with weight 256"
      
      This is because the kernel checks the NAPI polling weights
      requested by drivers and it prints an error message if a driver
      requests a weight bigger than 64.
      
      So use NAPI_POLL_WEIGHT to fix it.
      Signed-off-by: default avatarYonglong Liu <liuyonglong@huawei.com>
      Signed-off-by: default avatarPeng Li <lipeng321@huawei.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      acb1ce15
    • Liubin Shu's avatar
      net: hns: fix KASAN: use-after-free in hns_nic_net_xmit_hw() · 3a39a12a
      Liubin Shu authored
      This patch is trying to fix the issue due to:
      [27237.844750] BUG: KASAN: use-after-free in hns_nic_net_xmit_hw+0x708/0xa18[hns_enet_drv]
      
      After hnae_queue_xmit() in hns_nic_net_xmit_hw(), can be
      interrupted by interruptions, and than call hns_nic_tx_poll_one()
      to handle the new packets, and free the skb. So, when turn back to
      hns_nic_net_xmit_hw(), calling skb->len will cause use-after-free.
      
      This patch update tx ring statistics in hns_nic_tx_poll_one() to
      fix the bug.
      Signed-off-by: default avatarLiubin Shu <shuliubin@huawei.com>
      Signed-off-by: default avatarZhen Lei <thunder.leizhen@huawei.com>
      Signed-off-by: default avatarYonglong Liu <liuyonglong@huawei.com>
      Signed-off-by: default avatarPeng Li <lipeng321@huawei.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      3a39a12a
    • Junwei Hu's avatar
      ipv6: Fix dangling pointer when ipv6 fragment · ef0efcd3
      Junwei Hu authored
      At the beginning of ip6_fragment func, the prevhdr pointer is
      obtained in the ip6_find_1stfragopt func.
      However, all the pointers pointing into skb header may change
      when calling skb_checksum_help func with
      skb->ip_summed = CHECKSUM_PARTIAL condition.
      The prevhdr pointe will be dangling if it is not reloaded after
      calling __skb_linearize func in skb_checksum_help func.
      
      Here, I add a variable, nexthdr_offset, to evaluate the offset,
      which does not changes even after calling __skb_linearize func.
      
      Fixes: 405c92f7 ("ipv6: add defensive check for CHECKSUM_PARTIAL skbs in ip_fragment")
      Signed-off-by: default avatarJunwei Hu <hujunwei4@huawei.com>
      Reported-by: default avatarWenhao Zhang <zhangwenhao8@huawei.com>
      Reported-by: syzbot+e8ce541d095e486074fc@syzkaller.appspotmail.com
      Reviewed-by: default avatarZhiqiang Liu <liuzhiqiang26@huawei.com>
      Acked-by: default avatarMartin KaFai Lau <kafai@fb.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      ef0efcd3
    • Steffen Klassert's avatar
      net-gro: Fix GRO flush when receiving a GSO packet. · 0ab03f35
      Steffen Klassert authored
      Currently we may merge incorrectly a received GSO packet
      or a packet with frag_list into a packet sitting in the
      gro_hash list. skb_segment() may crash case because
      the assumptions on the skb layout are not met.
      The correct behaviour would be to flush the packet in the
      gro_hash list and send the received GSO packet directly
      afterwards. Commit d61d072e ("net-gro: avoid reorders")
      sets NAPI_GRO_CB(skb)->flush in this case, but this is not
      checked before merging. This patch makes sure to check this
      flag and to not merge in that case.
      
      Fixes: d61d072e ("net-gro: avoid reorders")
      Signed-off-by: default avatarSteffen Klassert <steffen.klassert@secunet.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      0ab03f35
  2. 02 Apr, 2019 7 commits
  3. 01 Apr, 2019 10 commits
  4. 31 Mar, 2019 11 commits
    • David S. Miller's avatar
      Merge branch 'tipc-a-batch-of-uninit-value-fixes-for-netlink_compat' · 7ff0b608
      David S. Miller authored
      Xin Long says:
      
      ====================
      tipc: a batch of uninit-value fixes for netlink_compat
      
      These issues were all reported by syzbot, and exist since very beginning.
      See the details on each patch.
      ====================
      Acked-by: default avatarJon Maloy <jon.maloy@ericsson.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      7ff0b608
    • Xin Long's avatar
      tipc: handle the err returned from cmd header function · 2ac695d1
      Xin Long authored
      Syzbot found a crash:
      
        BUG: KMSAN: uninit-value in tipc_nl_compat_name_table_dump+0x54f/0xcd0 net/tipc/netlink_compat.c:872
        Call Trace:
          tipc_nl_compat_name_table_dump+0x54f/0xcd0 net/tipc/netlink_compat.c:872
          __tipc_nl_compat_dumpit+0x59e/0xda0 net/tipc/netlink_compat.c:215
          tipc_nl_compat_dumpit+0x63a/0x820 net/tipc/netlink_compat.c:280
          tipc_nl_compat_handle net/tipc/netlink_compat.c:1226 [inline]
          tipc_nl_compat_recv+0x1b5f/0x2750 net/tipc/netlink_compat.c:1265
          genl_family_rcv_msg net/netlink/genetlink.c:601 [inline]
          genl_rcv_msg+0x185f/0x1a60 net/netlink/genetlink.c:626
          netlink_rcv_skb+0x431/0x620 net/netlink/af_netlink.c:2477
          genl_rcv+0x63/0x80 net/netlink/genetlink.c:637
          netlink_unicast_kernel net/netlink/af_netlink.c:1310 [inline]
          netlink_unicast+0xf3e/0x1020 net/netlink/af_netlink.c:1336
          netlink_sendmsg+0x127f/0x1300 net/netlink/af_netlink.c:1917
          sock_sendmsg_nosec net/socket.c:622 [inline]
          sock_sendmsg net/socket.c:632 [inline]
      
        Uninit was created at:
          __alloc_skb+0x309/0xa20 net/core/skbuff.c:208
          alloc_skb include/linux/skbuff.h:1012 [inline]
          netlink_alloc_large_skb net/netlink/af_netlink.c:1182 [inline]
          netlink_sendmsg+0xb82/0x1300 net/netlink/af_netlink.c:1892
          sock_sendmsg_nosec net/socket.c:622 [inline]
          sock_sendmsg net/socket.c:632 [inline]
      
      It was supposed to be fixed on commit 974cb0e3 ("tipc: fix uninit-value
      in tipc_nl_compat_name_table_dump") by checking TLV_GET_DATA_LEN(msg->req)
      in cmd->header()/tipc_nl_compat_name_table_dump_header(), which is called
      ahead of tipc_nl_compat_name_table_dump().
      
      However, tipc_nl_compat_dumpit() doesn't handle the error returned from cmd
      header function. It means even when the check added in that fix fails, it
      won't stop calling tipc_nl_compat_name_table_dump(), and the issue will be
      triggered again.
      
      So this patch is to add the process for the err returned from cmd header
      function in tipc_nl_compat_dumpit().
      
      Reported-by: syzbot+3ce8520484b0d4e260a5@syzkaller.appspotmail.com
      Signed-off-by: default avatarXin Long <lucien.xin@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      2ac695d1
    • Xin Long's avatar
      tipc: check link name with right length in tipc_nl_compat_link_set · 8c63bf9a
      Xin Long authored
      A similar issue as fixed by Patch "tipc: check bearer name with right
      length in tipc_nl_compat_bearer_enable" was also found by syzbot in
      tipc_nl_compat_link_set().
      
      The length to check with should be 'TLV_GET_DATA_LEN(msg->req) -
      offsetof(struct tipc_link_config, name)'.
      
      Reported-by: syzbot+de00a87b8644a582ae79@syzkaller.appspotmail.com
      Signed-off-by: default avatarXin Long <lucien.xin@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      8c63bf9a
    • Xin Long's avatar
      tipc: check bearer name with right length in tipc_nl_compat_bearer_enable · 6f07e5f0
      Xin Long authored
      Syzbot reported the following crash:
      
      BUG: KMSAN: uninit-value in memchr+0xce/0x110 lib/string.c:961
        memchr+0xce/0x110 lib/string.c:961
        string_is_valid net/tipc/netlink_compat.c:176 [inline]
        tipc_nl_compat_bearer_enable+0x2c4/0x910 net/tipc/netlink_compat.c:401
        __tipc_nl_compat_doit net/tipc/netlink_compat.c:321 [inline]
        tipc_nl_compat_doit+0x3aa/0xaf0 net/tipc/netlink_compat.c:354
        tipc_nl_compat_handle net/tipc/netlink_compat.c:1162 [inline]
        tipc_nl_compat_recv+0x1ae7/0x2750 net/tipc/netlink_compat.c:1265
        genl_family_rcv_msg net/netlink/genetlink.c:601 [inline]
        genl_rcv_msg+0x185f/0x1a60 net/netlink/genetlink.c:626
        netlink_rcv_skb+0x431/0x620 net/netlink/af_netlink.c:2477
        genl_rcv+0x63/0x80 net/netlink/genetlink.c:637
        netlink_unicast_kernel net/netlink/af_netlink.c:1310 [inline]
        netlink_unicast+0xf3e/0x1020 net/netlink/af_netlink.c:1336
        netlink_sendmsg+0x127f/0x1300 net/netlink/af_netlink.c:1917
        sock_sendmsg_nosec net/socket.c:622 [inline]
        sock_sendmsg net/socket.c:632 [inline]
      
      Uninit was created at:
        __alloc_skb+0x309/0xa20 net/core/skbuff.c:208
        alloc_skb include/linux/skbuff.h:1012 [inline]
        netlink_alloc_large_skb net/netlink/af_netlink.c:1182 [inline]
        netlink_sendmsg+0xb82/0x1300 net/netlink/af_netlink.c:1892
        sock_sendmsg_nosec net/socket.c:622 [inline]
        sock_sendmsg net/socket.c:632 [inline]
      
      It was triggered when the bearer name size < TIPC_MAX_BEARER_NAME,
      it would check with a wrong len/TLV_GET_DATA_LEN(msg->req), which
      also includes priority and disc_domain length.
      
      This patch is to fix it by checking it with a right length:
      'TLV_GET_DATA_LEN(msg->req) - offsetof(struct tipc_bearer_config, name)'.
      
      Reported-by: syzbot+8b707430713eb46e1e45@syzkaller.appspotmail.com
      Signed-off-by: default avatarXin Long <lucien.xin@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      6f07e5f0
    • David S. Miller's avatar
      Merge branch 'net-stmmac-fix-handling-of-oversized-frames' · d3de85a5
      David S. Miller authored
      Aaro Koskinen says:
      
      ====================
      net: stmmac: fix handling of oversized frames
      
      I accidentally had MTU size mismatch (9000 vs. 1500) in my network,
      and I noticed I could kill a system using stmmac & 1500 MTU simply
      by pinging it with "ping -s 2000 ...".
      
      While testing a fix I encountered also some other issues that need fixing.
      
      I have tested these only with enhanced descriptors, so the normal
      descriptor changes need a careful review.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      d3de85a5
    • Aaro Koskinen's avatar
      net: stmmac: don't log oversized frames · 057a0c56
      Aaro Koskinen authored
      This is log is harmful as it can trigger multiple times per packet. Delete
      it.
      Signed-off-by: default avatarAaro Koskinen <aaro.koskinen@nokia.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      057a0c56
    • Aaro Koskinen's avatar
      net: stmmac: fix dropping of multi-descriptor RX frames · 8ac0c24f
      Aaro Koskinen authored
      Packets without the last descriptor set should be dropped early. If we
      receive a frame larger than the DMA buffer, the HW will continue using the
      next descriptor. Driver mistakes these as individual frames, and sometimes
      a truncated frame (without the LD set) may look like a valid packet.
      
      This fixes a strange issue where the system replies to 4098-byte ping
      although the MTU/DMA buffer size is set to 4096, and yet at the same
      time it's logging an oversized packet.
      Signed-off-by: default avatarAaro Koskinen <aaro.koskinen@nokia.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      8ac0c24f
    • Aaro Koskinen's avatar
      net: stmmac: don't overwrite discard_frame status · 1b746ce8
      Aaro Koskinen authored
      If we have error bits set, the discard_frame status will get overwritten
      by checksum bit checks, which might set the status back to good one.
      Fix by checking the COE status only if the frame is good.
      Signed-off-by: default avatarAaro Koskinen <aaro.koskinen@nokia.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      1b746ce8
    • Aaro Koskinen's avatar
      net: stmmac: don't stop NAPI processing when dropping a packet · 07b39753
      Aaro Koskinen authored
      Currently, if we drop a packet, we exit from NAPI loop before the budget
      is consumed. In some situations this will make the RX processing stall
      e.g. when flood pinging the system with oversized packets, as the
      errorneous packets are not dropped efficiently.
      
      If we drop a packet, we should just continue to the next one as long as
      the budget allows.
      Signed-off-by: default avatarAaro Koskinen <aaro.koskinen@nokia.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      07b39753
    • Aaro Koskinen's avatar
      net: stmmac: ratelimit RX error logs · 972c9be7
      Aaro Koskinen authored
      Ratelimit RX error logs.
      Signed-off-by: default avatarAaro Koskinen <aaro.koskinen@nokia.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      972c9be7
    • Aaro Koskinen's avatar
      net: stmmac: use correct DMA buffer size in the RX descriptor · 583e6361
      Aaro Koskinen authored
      We always program the maximum DMA buffer size into the receive descriptor,
      although the allocated size may be less. E.g. with the default MTU size
      we allocate only 1536 bytes. If somebody sends us a bigger frame, then
      memory may get corrupted.
      
      Fix by using exact buffer sizes.
      Signed-off-by: default avatarAaro Koskinen <aaro.koskinen@nokia.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      583e6361
  5. 30 Mar, 2019 2 commits
  6. 29 Mar, 2019 2 commits
    • David S. Miller's avatar
      Merge tag 'mlx5-fixes-2019-03-29' of git://git.kernel.org/pub/scm/linux/kernel/git/saeed/linux · 19c84744
      David S. Miller authored
      Saeed Mahameed says:
      
      ====================
      Mellanox, mlx5 fixes 2019-03-29
      
      This series introduces some fixes to mlx5 driver.
      
      Please pull and let me know if there is any problem.
      
      For -stable v4.11
      ('net/mlx5: Decrease default mr cache size')
      
      For -stable v4.12
      ('net/mlx5e: Add a lock on tir list')
      
      For -stable v4.13
      ('net/mlx5e: Fix error handling when refreshing TIRs')
      
      For -stable v4.18
      ('net/mlx5e: Update xon formula')
      
      For -stable v4.19
      ('net: mlx5: Add a missing check on idr_find, free buf')
      ('net/mlx5e: Update xoff formula')
      
      net-next merge Note:
      When merged with net-next the following simple conflict will appear,
      
      drivers/net/ethernet/mellanox/mlx5/core/en/port_buffer.c
      
      ++<<<<<<< HEAD (net)
       + *   max_mtu: netdev's max_mtu
      ++=======
      +  *    @mtu: device's MTU
      ++>>>>>>> net-next
      
      To resolve: just replace the line in net-next
      *    @mtu: device's MTU
      to
      *    @max_mtu: netdev's max_mtu
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      19c84744
    • David S. Miller's avatar
      Revert "cxgb4: Update 1.23.3.0 as the latest firmware supported." · ec915f47
      David S. Miller authored
      This reverts commit 4d31c4fa.
      
      Accidently applied this to the wrong tree.
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      ec915f47