1. 11 7月, 2020 6 次提交
    • N
      net: macb: fix call to pm_runtime in the suspend/resume functions · 6c8f85ca
      Nicolas Ferre 提交于
      The calls to pm_runtime_force_suspend/resume() functions are only
      relevant if the device is not configured to act as a WoL wakeup source.
      Add the device_may_wakeup() test before calling them.
      
      Fixes: 3e2a5e15 ("net: macb: add wake-on-lan support via magic packet")
      Cc: Claudiu Beznea <claudiu.beznea@microchip.com>
      Cc: Harini Katakam <harini.katakam@xilinx.com>
      Cc: Sergio Prado <sergio.prado@e-labworks.com>
      Reviewed-by: NFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: NNicolas Ferre <nicolas.ferre@microchip.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      6c8f85ca
    • N
      net: macb: fix macb_suspend() by removing call to netif_carrier_off() · 64febc5e
      Nicolas Ferre 提交于
      As we now use the phylink call to phylink_stop() in the non-WoL path,
      there is no need for this call to netif_carrier_off() anymore. It can
      disturb the underlying phylink FSM.
      
      Fixes: 7897b071 ("net: macb: convert to phylink")
      Cc: Claudiu Beznea <claudiu.beznea@microchip.com>
      Cc: Harini Katakam <harini.katakam@xilinx.com>
      Cc: Antoine Tenart <antoine.tenart@bootlin.com>
      Reviewed-by: NFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: NNicolas Ferre <nicolas.ferre@microchip.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      64febc5e
    • N
      net: macb: fix macb_get/set_wol() when moving to phylink · 253fe094
      Nicolas Ferre 提交于
      Keep previous function goals and integrate phylink actions to them.
      
      phylink_ethtool_get_wol() is not enough to figure out if Ethernet driver
      supports Wake-on-Lan.
      Initialization of "supported" and "wolopts" members is done in phylink
      function, no need to keep them in calling function.
      
      phylink_ethtool_set_wol() return value is considered and determines
      if the MAC has to handle WoL or not. The case where the PHY doesn't
      implement WoL leads to the MAC configuring it to provide this feature.
      
      Fixes: 7897b071 ("net: macb: convert to phylink")
      Cc: Claudiu Beznea <claudiu.beznea@microchip.com>
      Cc: Harini Katakam <harini.katakam@xilinx.com>
      Cc: Antoine Tenart <antoine.tenart@bootlin.com>
      Cc: Florian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: NNicolas Ferre <nicolas.ferre@microchip.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      253fe094
    • N
      net: macb: mark device wake capable when "magic-packet" property present · ced4799d
      Nicolas Ferre 提交于
      Change the way the "magic-packet" DT property is handled in the
      macb_probe() function, matching DT binding documentation.
      Now we mark the device as "wakeup capable" instead of calling the
      device_init_wakeup() function that would enable the wakeup source.
      
      For Ethernet WoL, enabling the wakeup_source is done by
      using ethtool and associated macb_set_wol() function that
      already calls device_set_wakeup_enable() for this purpose.
      
      That would reduce power consumption by cutting more clocks if
      "magic-packet" property is set but WoL is not configured by ethtool.
      
      Fixes: 3e2a5e15 ("net: macb: add wake-on-lan support via magic packet")
      Cc: Claudiu Beznea <claudiu.beznea@microchip.com>
      Cc: Harini Katakam <harini.katakam@xilinx.com>
      Cc: Sergio Prado <sergio.prado@e-labworks.com>
      Reviewed-by: NFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: NNicolas Ferre <nicolas.ferre@microchip.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      ced4799d
    • N
      net: macb: fix wakeup test in runtime suspend/resume routines · 515a10a7
      Nicolas Ferre 提交于
      Use the proper struct device pointer to check if the wakeup flag
      and wakeup source are positioned.
      Use the one passed by function call which is equivalent to
      &bp->dev->dev.parent.
      
      It's preventing the trigger of a spurious interrupt in case the
      Wake-on-Lan feature is used.
      
      Fixes: d54f89af ("net: macb: Add pm runtime support")
      Cc: Claudiu Beznea <claudiu.beznea@microchip.com>
      Cc: Harini Katakam <harini.katakam@xilinx.com>
      Reviewed-by: NFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: NNicolas Ferre <nicolas.ferre@microchip.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      515a10a7
    • D
      bnxt_en: fix NULL dereference in case SR-IOV configuration fails · c8b1d743
      Davide Caratti 提交于
      we need to set 'active_vfs' back to 0, if something goes wrong during the
      allocation of SR-IOV resources: otherwise, further VF configurations will
      wrongly assume that bp->pf.vf[x] are valid memory locations, and commands
      like the ones in the following sequence:
      
       # echo 2 >/sys/bus/pci/devices/${ADDR}/sriov_numvfs
       # ip link set dev ens1f0np0 up
       # ip link set dev ens1f0np0 vf 0 trust on
      
      will cause a kernel crash similar to this:
      
       bnxt_en 0000:3b:00.0: not enough MMIO resources for SR-IOV
       BUG: kernel NULL pointer dereference, address: 0000000000000014
       #PF: supervisor read access in kernel mode
       #PF: error_code(0x0000) - not-present page
       PGD 0 P4D 0
       Oops: 0000 [#1] SMP PTI
       CPU: 43 PID: 2059 Comm: ip Tainted: G          I       5.8.0-rc2.upstream+ #871
       Hardware name: Dell Inc. PowerEdge R740/08D89F, BIOS 2.2.11 06/13/2019
       RIP: 0010:bnxt_set_vf_trust+0x5b/0x110 [bnxt_en]
       Code: 44 24 58 31 c0 e8 f5 fb ff ff 85 c0 0f 85 b6 00 00 00 48 8d 1c 5b 41 89 c6 b9 0b 00 00 00 48 c1 e3 04 49 03 9c 24 f0 0e 00 00 <8b> 43 14 89 c2 83 c8 10 83 e2 ef 45 84 ed 49 89 e5 0f 44 c2 4c 89
       RSP: 0018:ffffac6246a1f570 EFLAGS: 00010246
       RAX: 0000000000000000 RBX: 0000000000000000 RCX: 000000000000000b
       RDX: 0000000000000001 RSI: 0000000000000000 RDI: ffff98b28f538900
       RBP: ffff98b28f538900 R08: 0000000000000000 R09: 0000000000000008
       R10: ffffffffb9515be0 R11: ffffac6246a1f678 R12: ffff98b28f538000
       R13: 0000000000000001 R14: 0000000000000000 R15: ffffffffc05451e0
       FS:  00007fde0f688800(0000) GS:ffff98baffd40000(0000) knlGS:0000000000000000
       CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
       CR2: 0000000000000014 CR3: 000000104bb0a003 CR4: 00000000007606e0
       DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
       DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
       PKRU: 55555554
       Call Trace:
        do_setlink+0x994/0xfe0
        __rtnl_newlink+0x544/0x8d0
        rtnl_newlink+0x47/0x70
        rtnetlink_rcv_msg+0x29f/0x350
        netlink_rcv_skb+0x4a/0x110
        netlink_unicast+0x21d/0x300
        netlink_sendmsg+0x329/0x450
        sock_sendmsg+0x5b/0x60
        ____sys_sendmsg+0x204/0x280
        ___sys_sendmsg+0x88/0xd0
        __sys_sendmsg+0x5e/0xa0
        do_syscall_64+0x47/0x80
        entry_SYSCALL_64_after_hwframe+0x44/0xa9
      
      Fixes: c0c050c5 ("bnxt_en: New Broadcom ethernet driver.")
      Reported-by: NFei Liu <feliu@redhat.com>
      CC: Jonathan Toppins <jtoppins@redhat.com>
      CC: Michael Chan <michael.chan@broadcom.com>
      Signed-off-by: NDavide Caratti <dcaratti@redhat.com>
      Reviewed-by: NMichael Chan <michael.chan@broadcom.com>
      Acked-by: NJonathan Toppins <jtoppins@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      c8b1d743
  2. 10 7月, 2020 10 次提交
    • E
      net/mlx5e: CT: Fix memory leak in cleanup · eb32b3f5
      Eli Britstein 提交于
      CT entries are deleted via a workqueue from netfilter. If removing the
      module before that, the rules are cleaned by the driver itself, but the
      memory entries for them are not freed. Fix that.
      
      Fixes: ac991b48 ("net/mlx5e: CT: Offload established flows")
      Signed-off-by: NEli Britstein <elibr@mellanox.com>
      Reviewed-by: NRoi Dayan <roid@mellanox.com>
      Signed-off-by: NSaeed Mahameed <saeedm@mellanox.com>
      eb32b3f5
    • E
      net/mlx5e: Fix port buffers cell size value · 88b3d5c9
      Eran Ben Elisha 提交于
      Device unit for port buffers size, xoff_threshold and xon_threshold is
      cells. Fix a bug in driver where cell unit size was hard-coded to
      128 bytes. This hard-coded value is buggy, as it is wrong for some hardware
      versions.
      
      Driver to read cell size from SBCAM register and translate bytes to cell
      units accordingly.
      
      In order to fix the bug, this patch exposes SBCAM (Shared buffer
      capabilities mask) layout and defines.
      
      If SBCAM.cap_cell_size is valid, use it for all bytes to cells
      calculations. If not valid, fallback to 128.
      
      Cell size do not change on the fly per device. Instead of issuing SBCAM
      access reg command every time such translation is needed, cache it in
      mlx5e_dcbx as part of mlx5e_dcbnl_initialize(). Pass dcbx.port_buff_cell_sz
      as a param to every function that needs bytes to cells translation.
      
      While fixing the bug, move MLX5E_BUFFER_CELL_SHIFT macro to
      en_dcbnl.c, as it is only used by that file.
      
      Fixes: 0696d608 ("net/mlx5e: Receive buffer configuration")
      Signed-off-by: NEran Ben Elisha <eranbe@mellanox.com>
      Reviewed-by: NHuy Nguyen <huyn@mellanox.com>
      Signed-off-by: NSaeed Mahameed <saeedm@mellanox.com>
      88b3d5c9
    • A
      net/mlx5e: Fix 50G per lane indication · 6a1cf4e4
      Aya Levin 提交于
      Some released FW versions mistakenly don't set the capability that 50G
      per lane link-modes are supported for VFs (ptys_extended_ethernet
      capability bit). When the capability is unset, read
      PTYS.ext_eth_proto_capability (always reliable).
      If PTYS.ext_eth_proto_capability is valid (has a non-zero value)
      conclude that the HCA supports 50G per lane. Otherwise, conclude that
      the HCA doesn't support 50G per lane.
      
      Fixes: a08b4ed1 ("net/mlx5: Add support to ext_* fields introduced in Port Type and Speed register")
      Signed-off-by: NAya Levin <ayal@mellanox.com>
      Reviewed-by: NEran Ben Elisha <eranbe@mellanox.com>
      Signed-off-by: NSaeed Mahameed <saeedm@mellanox.com>
      6a1cf4e4
    • A
      net/mlx5e: Fix CPU mapping after function reload to avoid aRFS RX crash · f4aebbfb
      Aya Levin 提交于
      After function reload, CPU mapping used by aRFS RX is broken, leading to
      a kernel panic. Fix by moving initialization of rx_cpu_rmap from
      netdev_init to netdev_attach. IRQ table is re-allocated on mlx5_load,
      but netdev is not re-initialize.
      
      Trace of the panic:
      [ 22.055672] general protection fault, probably for non-canonical address 0x785634120000ff1c: 0000 [#1] SMP PTI
      [ 22.065010] CPU: 4 PID: 0 Comm: swapper/4 Not tainted 5.7.0-rc2-for-upstream-perf-2020-04-21_16-34-03-31 #1
      [ 22.067967] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.12.1-0-ga5cab58e9a3f-prebuilt.qemu.org 04/01/2014
      [ 22.071174] RIP: 0010:get_rps_cpu+0x267/0x300
      [ 22.075692] RSP: 0018:ffffc90000244d60 EFLAGS: 00010202
      [ 22.076888] RAX: ffff888459b0e400 RBX: 0000000000000000 RCX:0000000000000007
      [ 22.078364] RDX: 0000000000008884 RSI: ffff888467cb5b00 RDI:0000000000000000
      [ 22.079815] RBP: 00000000ff342b27 R08: 0000000000000007 R09:0000000000000003
      [ 22.081289] R10: ffffffffffffffff R11: 00000000000070cc R12:ffff888454900000
      [ 22.082767] R13: ffffc90000e5a950 R14: ffffc90000244dc0 R15:0000000000000007
      [ 22.084190] FS: 0000000000000000(0000) GS:ffff88846fc80000(0000)knlGS:0000000000000000
      [ 22.086161] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [ 22.087427] CR2: ffffffffffffffff CR3: 0000000464426003 CR4:0000000000760ee0
      [ 22.088888] DR0: 0000000000000000 DR1: 0000000000000000 DR2:0000000000000000
      [ 22.090336] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7:0000000000000400
      [ 22.091764] PKRU: 55555554
      [ 22.092618] Call Trace:
      [ 22.093442] <IRQ>
      [ 22.094211] ? kvm_clock_get_cycles+0xd/0x10
      [ 22.095272] netif_receive_skb_list_internal+0x258/0x2a0
      [ 22.096460] gro_normal_list.part.137+0x19/0x40
      [ 22.097547] napi_complete_done+0xc6/0x110
      [ 22.098685] mlx5e_napi_poll+0x190/0x670 [mlx5_core]
      [ 22.099859] net_rx_action+0x2a0/0x400
      [ 22.100848] __do_softirq+0xd8/0x2a8
      [ 22.101829] irq_exit+0xa5/0xb0
      [ 22.102750] do_IRQ+0x52/0xd0
      [ 22.103654] common_interrupt+0xf/0xf
      [ 22.104641] </IRQ>
      
      Fixes: 4383cfcc ("net/mlx5: Add devlink reload")
      Signed-off-by: NAya Levin <ayal@mellanox.com>
      Reviewed-by: NEran Ben Elisha <eranbe@mellanox.com>
      Signed-off-by: NSaeed Mahameed <saeedm@mellanox.com>
      f4aebbfb
    • A
      net/mlx5e: Fix VXLAN configuration restore after function reload · b3c2ed21
      Aya Levin 提交于
      When detaching netdev, remove vxlan port configuration using
      udp_tunnel_drop_rx_info. During function reload, configuration will be
      restored using udp_tunnel_get_rx_info. This ensures sync between
      firmware and driver. Use udp_tunnel_get_rx_info even if its physical
      interface is down.
      
      Fixes: 4383cfcc ("net/mlx5: Add devlink reload")
      Signed-off-by: NAya Levin <ayal@mellanox.com>
      Reviewed-by: NEran Ben Elisha <eranbe@mellanox.com>
      Signed-off-by: NSaeed Mahameed <saeedm@mellanox.com>
      b3c2ed21
    • V
      net/mlx5e: Fix usage of rcu-protected pointer · c1aea9e1
      Vlad Buslov 提交于
      In mlx5e_configure_flower() flow pointer is protected by rcu read lock.
      However, after cited commit the pointer is being used outside of rcu read
      block. Extend the block to protect all pointer accesses.
      
      Fixes: 553f9328 ("net/mlx5e: Support tc block sharing for representors")
      Signed-off-by: NVlad Buslov <vladbu@mellanox.com>
      Reviewed-by: NRoi Dayan <roid@mellanox.com>
      Signed-off-by: NSaeed Mahameed <saeedm@mellanox.com>
      c1aea9e1
    • V
      net/mxl5e: Verify that rpriv is not NULL · 2fb15e72
      Vlad Buslov 提交于
      In helper function is_flow_rule_duplicate_allowed() verify that rpviv
      pointer is not NULL before dereferencing it. This can happen when device is
      in NIC mode and leads to following crash:
      
      [90444.046419] BUG: kernel NULL pointer dereference, address: 0000000000000000
      [90444.048149] #PF: supervisor read access in kernel mode
      [90444.049781] #PF: error_code(0x0000) - not-present page
      [90444.051386] PGD 80000003d35a4067 P4D 80000003d35a4067 PUD 3d35a3067 PMD 0
      [90444.053051] Oops: 0000 [#1] SMP PTI
      [90444.054683] CPU: 16 PID: 31736 Comm: tc Not tainted 5.8.0-rc1+ #1157
      [90444.056340] Hardware name: Supermicro SYS-2028TP-DECR/X10DRT-P, BIOS 2.0b 03/30/2017
      [90444.058079] RIP: 0010:mlx5e_configure_flower+0x3aa/0x9b0 [mlx5_core]
      [90444.059753] Code: 24 50 49 8b 95 08 02 00 00 48 b8 00 08 00 00 04 00 00 00 48 21 c2 48 39 c2 74 0a 41 f6 85 0d 02 00 00 20 74 16 48 8b 44 24 20 <48> 8b 00 66 83 78 20 ff 74 07 4d 89 aa e0 00 00 00 48 83 7d 28 00
      [90444.063232] RSP: 0018:ffffabe9c61ff768 EFLAGS: 00010246
      [90444.065014] RAX: 0000000000000000 RBX: ffff9b13c4c91e80 RCX: 00000000000093fa
      [90444.066784] RDX: 0000000400000800 RSI: 0000000000000000 RDI: 000000000002d5e0
      [90444.068533] RBP: ffff9b174d308468 R08: 0000000000000000 R09: ffff9b17d63003f0
      [90444.070285] R10: ffff9b17ea288600 R11: 0000000000000000 R12: ffffabe9c61ff878
      [90444.072032] R13: ffff9b174d300000 R14: ffffabe9c61ffbb8 R15: ffff9b174d300880
      [90444.073760] FS:  00007f3c23775480(0000) GS:ffff9b13efc80000(0000) knlGS:0000000000000000
      [90444.075492] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [90444.077266] CR2: 0000000000000000 CR3: 00000003e2a60002 CR4: 00000000001606e0
      [90444.079024] Call Trace:
      [90444.080753]  tc_setup_cb_add+0xca/0x1e0
      [90444.082415]  fl_hw_replace_filter+0x15f/0x1f0 [cls_flower]
      [90444.084119]  fl_change+0xa59/0x13dc [cls_flower]
      [90444.085772]  ? wait_for_completion+0xa8/0xf0
      [90444.087364]  tc_new_tfilter+0x3f5/0xa60
      [90444.088960]  rtnetlink_rcv_msg+0xeb/0x360
      [90444.090514]  ? __d_lookup_done+0x76/0xe0
      [90444.092034]  ? proc_alloc_inode+0x16/0x70
      [90444.093560]  ? prep_new_page+0x8c/0xf0
      [90444.095048]  ? _cond_resched+0x15/0x30
      [90444.096483]  ? rtnl_calcit.isra.0+0x110/0x110
      [90444.097907]  netlink_rcv_skb+0x49/0x110
      [90444.099289]  netlink_unicast+0x191/0x230
      [90444.100629]  netlink_sendmsg+0x243/0x480
      [90444.101984]  sock_sendmsg+0x5e/0x60
      [90444.103305]  ____sys_sendmsg+0x1f3/0x260
      [90444.104597]  ? copy_msghdr_from_user+0x5c/0x90
      [90444.105916]  ? __mod_lruvec_state+0x3c/0xe0
      [90444.107210]  ___sys_sendmsg+0x81/0xc0
      [90444.108484]  ? do_filp_open+0xa5/0x100
      [90444.109732]  ? handle_mm_fault+0x117b/0x1e00
      [90444.110970]  ? __check_object_size+0x46/0x147
      [90444.112205]  ? __check_object_size+0x136/0x147
      [90444.113402]  __sys_sendmsg+0x59/0xa0
      [90444.114587]  do_syscall_64+0x4d/0x90
      [90444.115782]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
      [90444.116953] RIP: 0033:0x7f3c2393b7b8
      [90444.118101] Code: Bad RIP value.
      [90444.119240] RSP: 002b:00007ffc6ad8e6c8 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
      [90444.120408] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f3c2393b7b8
      [90444.121583] RDX: 0000000000000000 RSI: 00007ffc6ad8e740 RDI: 0000000000000003
      [90444.122750] RBP: 000000005eea0c3a R08: 0000000000000001 R09: 00007ffc6ad8e68c
      [90444.123928] R10: 0000000000404fa8 R11: 0000000000000246 R12: 0000000000000001
      [90444.125073] R13: 0000000000000000 R14: 00007ffc6ad92a00 R15: 00000000004866a0
      [90444.126221] Modules linked in: act_skbedit act_tunnel_key act_mirred bonding vxlan ip6_udp_tunnel udp_tunnel nfnetlink act_gact cls_flower sch_ingress openvswitch nsh nf_conncount nfsv3 nfs_acl nfs lockd grace fscache tun bridge stp llc sunrpc rdma_ucm rdma_cm iw_cm ib_cm mlx5_ib ib_uverbs ib_core mlx5_core intel_r
      apl_msr intel_rapl_common sb_edac x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel mlxfw kvm act_ct nf_flow_table nf_nat nf_conntrack irqbypass crct10dif_pclmul nf_defrag_ipv6 igb ipmi_ssif libcrc32c crc32_pclmul crc32c_intel ipmi_si nf_defrag_ipv4 ptp ghash_clmulni_intel mei_me ses iTCO_wdt i2c_i801 pps_core
      ioatdma iTCO_vendor_support joydev mei enclosure intel_cstate i2c_smbus wmi dca ipmi_devintf intel_uncore lpc_ich ipmi_msghandler pcspkr acpi_pad acpi_power_meter ast i2c_algo_bit drm_vram_helper drm_kms_helper drm_ttm_helper ttm drm mpt3sas raid_class scsi_transport_sas
      [90444.136253] CR2: 0000000000000000
      [90444.137621] ---[ end trace 924af62aa2b151bd ]---
      
      Fixes: 553f9328 ("net/mlx5e: Support tc block sharing for representors")
      Reported-by: NDavid Ahern <dsahern@gmail.com>
      Signed-off-by: NVlad Buslov <vladbu@mellanox.com>
      Reviewed-by: NRoi Dayan <roid@mellanox.com>
      Signed-off-by: NSaeed Mahameed <saeedm@mellanox.com>
      2fb15e72
    • V
      net/mlx5: E-Switch, Fix vlan or qos setting in legacy mode · 01f3d5db
      Vu Pham 提交于
      Refactoring eswitch ingress acl codes accidentally inserts extra
      memset zero that removes vlan and/or qos setting in legacy mode.
      
      Fixes: 07bab950 ("net/mlx5: E-Switch, Refactor eswitch ingress acl codes")
      Signed-off-by: NVu Pham <vuhuong@mellanox.com>
      Signed-off-by: NSaeed Mahameed <saeedm@mellanox.com>
      01f3d5db
    • E
      net/mlx5: Fix eeprom support for SFP module · 47afbdd2
      Eran Ben Elisha 提交于
      Fix eeprom SFP query support by setting i2c_addr, offset and page number
      correctly. Unlike QSFP modules, SFP eeprom params are as follow:
      - i2c_addr is 0x50 for offset 0 - 255 and 0x51 for offset 256 - 511.
      - Page number is always zero.
      - Page offset is always relative to zero.
      
      As part of eeprom query, query the module ID (SFP / QSFP*) via helper
      function to set the params accordingly.
      
      In addition, change mlx5_qsfp_eeprom_page() input type to be u16 to avoid
      unnecessary casting.
      
      Fixes: a708fb7b ("net/mlx5e: ethtool, Add support for EEPROM high pages query")
      Signed-off-by: NEran Ben Elisha <eranbe@mellanox.com>
      Signed-off-by: NHuy Nguyen <huyn@mellanox.com>
      Signed-off-by: NSaeed Mahameed <saeedm@mellanox.com>
      47afbdd2
    • S
      qed: Populate nvm-file attributes while reading nvm config partition. · 13cf8aab
      Sudarsana Reddy Kalluru 提交于
      NVM config file address will be modified when the MBI image is upgraded.
      Driver would return stale config values if user reads the nvm-config
      (via ethtool -d) in this state. The fix is to re-populate nvm attribute
      info while reading the nvm config values/partition.
      
      Changes from previous version:
      -------------------------------
      v3: Corrected the formatting in 'Fixes' tag.
      v2: Added 'Fixes' tag.
      
      Fixes: 1ac4329a ("qed: Add configuration information to register dump and debug data")
      Signed-off-by: NSudarsana Reddy Kalluru <skalluru@marvell.com>
      Signed-off-by: NIgor Russkikh <irusskikh@marvell.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      13cf8aab
  3. 09 7月, 2020 2 次提交
  4. 08 7月, 2020 5 次提交
  5. 07 7月, 2020 4 次提交
    • Y
      net: hns3: fix use-after-free when doing self test · a0665621
      Yonglong Liu 提交于
      Enable promisc mode of PF, set VF link state to enable, and
      run iperf of the VF, then do self test of the PF. The self test
      will fail with a low frequency, and may cause a use-after-free
      problem.
      
      [   87.142126] selftest:000004a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
      [   87.159722] ==================================================================
      [   87.174187] BUG: KASAN: use-after-free in hex_dump_to_buffer+0x140/0x608
      [   87.187600] Read of size 1 at addr ffff003b22828000 by task ethtool/1186
      [   87.201012]
      [   87.203978] CPU: 7 PID: 1186 Comm: ethtool Not tainted 5.5.0-rc4-gfd51c473-dirty #4
      [   87.219306] Hardware name: Huawei TaiShan 2280 V2/BC82AMDA, BIOS TA BIOS 2280-A CS V2.B160.01 01/15/2020
      [   87.238292] Call trace:
      [   87.243173]  dump_backtrace+0x0/0x280
      [   87.250491]  show_stack+0x24/0x30
      [   87.257114]  dump_stack+0xe8/0x140
      [   87.263911]  print_address_description.isra.8+0x70/0x380
      [   87.274538]  __kasan_report+0x12c/0x230
      [   87.282203]  kasan_report+0xc/0x18
      [   87.288999]  __asan_load1+0x60/0x68
      [   87.295969]  hex_dump_to_buffer+0x140/0x608
      [   87.304332]  print_hex_dump+0x140/0x1e0
      [   87.312000]  hns3_lb_check_skb_data+0x168/0x170
      [   87.321060]  hns3_clean_rx_ring+0xa94/0xfe0
      [   87.329422]  hns3_self_test+0x708/0x8c0
      
      The length of packet sent by the selftest process is only
      128 + 14 bytes, and the min buffer size of a BD is 256 bytes,
      and the receive process will make sure the packet sent by
      the selftest process is in the linear part, so only check
      the linear part in hns3_lb_check_skb_data().
      
      So fix this use-after-free by using skb_headlen() to dump
      skb->data instead of skb->len.
      
      Fixes: c39c4d98 ("net: hns3: Add mac loopback selftest support in hns3 driver")
      Signed-off-by: NYonglong Liu <liuyonglong@huawei.com>
      Signed-off-by: NHuazhong Tan <tanhuazhong@huawei.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      a0665621
    • H
      net: hns3: add a missing uninit debugfs when unload driver · e22b5e72
      Huazhong Tan 提交于
      When unloading driver, if flag HNS3_NIC_STATE_INITED has been
      already cleared, the debugfs will not be uninitialized, so fix it.
      
      Fixes: b2292360 ("net: hns3: Add debugfs framework registration")
      Signed-off-by: NHuazhong Tan <tanhuazhong@huawei.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      e22b5e72
    • H
      net: hns3: fix for mishandle of asserting VF reset fail · cddd5648
      Huazhong Tan 提交于
      When asserts VF reset fail, flag HCLGEVF_STATE_CMD_DISABLE
      and handshake status should not set, otherwise the retry will
      fail. So adds a check for asserting VF reset and returns
      directly when fails.
      
      Fixes: ef5f8e50 ("net: hns3: stop handling command queue while resetting VF")
      Signed-off-by: NHuazhong Tan <tanhuazhong@huawei.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      cddd5648
    • H
      net: hns3: check reset pending after FLR prepare · bb3d8668
      Huazhong Tan 提交于
      If there is a PF reset pending before FLR prepare, FLR's
      preparatory work will not fail, but the FLR rebuild procedure
      will fail for this pending. So this PF reset pending should
      be handled in the FLR preparatory.
      
      Fixes: 8627bded ("net: hns3: refactor the precedure of PF FLR")
      Signed-off-by: NHuazhong Tan <tanhuazhong@huawei.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      bb3d8668
  6. 05 7月, 2020 3 次提交
    • T
      net: rmnet: do not allow to add multiple bridge interfaces · 2fb2799a
      Taehee Yoo 提交于
      rmnet can have only two bridge interface.
      One of them is a link interface and another one is added by
      the master operation.
      rmnet interface shouldn't allow adding additional
      bridge interfaces by mater operation.
      But, there is no code to deny additional interfaces.
      So, interface leak occurs.
      
      Test commands:
          ip link add dummy0 type dummy
          ip link add dummy1 type dummy
          ip link add dummy2 type dummy
          ip link add rmnet0 link dummy0 type rmnet mux_id 1
          ip link set dummy1 master rmnet0
          ip link set dummy2 master rmnet0
          ip link del rmnet0
      
      In the above test command, the dummy0 was attached to rmnet as VND mode.
      Then, dummy1 was attached to rmnet0 as BRIDGE mode.
      At this point, dummy0 mode is switched from VND to BRIDGE automatically.
      Then, dummy2 is attached to rmnet as BRIDGE mode.
      At this point, rmnet0 should deny this operation.
      But, rmnet0 doesn't deny this.
      So that below splat occurs when the rmnet0 interface is deleted.
      
      Splat looks like:
      [  186.684787][    C2] WARNING: CPU: 2 PID: 1009 at net/core/dev.c:8992 rollback_registered_many+0x986/0xcf0
      [  186.684788][    C2] Modules linked in: rmnet dummy openvswitch nsh nf_conncount nf_nat nf_conntrack nf_defrag_x
      [  186.684805][    C2] CPU: 2 PID: 1009 Comm: ip Not tainted 5.8.0-rc1+ #621
      [  186.684807][    C2] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006
      [  186.684808][    C2] RIP: 0010:rollback_registered_many+0x986/0xcf0
      [  186.684811][    C2] Code: 41 8b 4e cc 45 31 c0 31 d2 4c 89 ee 48 89 df e8 e0 47 ff ff 85 c0 0f 84 cd fc ff ff 5
      [  186.684812][    C2] RSP: 0018:ffff8880cd9472e0 EFLAGS: 00010287
      [  186.684815][    C2] RAX: ffff8880cc56da58 RBX: ffff8880ab21c000 RCX: ffffffff9329d323
      [  186.684816][    C2] RDX: 1ffffffff2be6410 RSI: 0000000000000008 RDI: ffffffff95f32080
      [  186.684818][    C2] RBP: dffffc0000000000 R08: fffffbfff2be6411 R09: fffffbfff2be6411
      [  186.684819][    C2] R10: ffffffff95f32087 R11: 0000000000000001 R12: ffff8880cd947480
      [  186.684820][    C2] R13: ffff8880ab21c0b8 R14: ffff8880cd947400 R15: ffff8880cdf10640
      [  186.684822][    C2] FS:  00007f00843890c0(0000) GS:ffff8880d4e00000(0000) knlGS:0000000000000000
      [  186.684823][    C2] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [  186.684825][    C2] CR2: 000055b8ab1077b8 CR3: 00000000ab612006 CR4: 00000000000606e0
      [  186.684826][    C2] Call Trace:
      [  186.684827][    C2]  ? lockdep_hardirqs_on_prepare+0x379/0x540
      [  186.684829][    C2]  ? netif_set_real_num_tx_queues+0x780/0x780
      [  186.684830][    C2]  ? rmnet_unregister_real_device+0x56/0x90 [rmnet]
      [  186.684831][    C2]  ? __kasan_slab_free+0x126/0x150
      [  186.684832][    C2]  ? kfree+0xdc/0x320
      [  186.684834][    C2]  ? rmnet_unregister_real_device+0x56/0x90 [rmnet]
      [  186.684835][    C2]  unregister_netdevice_many.part.135+0x13/0x1b0
      [  186.684836][    C2]  rtnl_delete_link+0xbc/0x100
      [ ... ]
      [  238.440071][ T1009] unregister_netdevice: waiting for rmnet0 to become free. Usage count = 1
      
      Fixes: 037f9cdf ("net: rmnet: use upper/lower device infrastructure")
      Signed-off-by: NTaehee Yoo <ap420073@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      2fb2799a
    • T
      net: rmnet: fix lower interface leak · 2a762e9e
      Taehee Yoo 提交于
      There are two types of the lower interface of rmnet that are VND
      and BRIDGE.
      Each lower interface can have only one type either VND or BRIDGE.
      But, there is a case, which uses both lower interface types.
      Due to this unexpected behavior, lower interface leak occurs.
      
      Test commands:
          ip link add dummy0 type dummy
          ip link add dummy1 type dummy
          ip link add rmnet0 link dummy0 type rmnet mux_id 1
          ip link set dummy1 master rmnet0
          ip link add rmnet1 link dummy1 type rmnet mux_id 2
          ip link del rmnet0
      
      The dummy1 was attached as BRIDGE interface of rmnet0.
      Then, it also was attached as VND interface of rmnet1.
      This is unexpected behavior and there is no code for handling this case.
      So that below splat occurs when the rmnet0 interface is deleted.
      
      Splat looks like:
      [   53.254112][    C1] WARNING: CPU: 1 PID: 1192 at net/core/dev.c:8992 rollback_registered_many+0x986/0xcf0
      [   53.254117][    C1] Modules linked in: rmnet dummy openvswitch nsh nf_conncount nf_nat nf_conntrack nf_defrag_ipv6 nfx
      [   53.254182][    C1] CPU: 1 PID: 1192 Comm: ip Not tainted 5.8.0-rc1+ #620
      [   53.254188][    C1] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006
      [   53.254192][    C1] RIP: 0010:rollback_registered_many+0x986/0xcf0
      [   53.254200][    C1] Code: 41 8b 4e cc 45 31 c0 31 d2 4c 89 ee 48 89 df e8 e0 47 ff ff 85 c0 0f 84 cd fc ff ff 0f 0b e5
      [   53.254205][    C1] RSP: 0018:ffff888050a5f2e0 EFLAGS: 00010287
      [   53.254214][    C1] RAX: ffff88805756d658 RBX: ffff88804d99c000 RCX: ffffffff8329d323
      [   53.254219][    C1] RDX: 1ffffffff0be6410 RSI: 0000000000000008 RDI: ffffffff85f32080
      [   53.254223][    C1] RBP: dffffc0000000000 R08: fffffbfff0be6411 R09: fffffbfff0be6411
      [   53.254228][    C1] R10: ffffffff85f32087 R11: 0000000000000001 R12: ffff888050a5f480
      [   53.254233][    C1] R13: ffff88804d99c0b8 R14: ffff888050a5f400 R15: ffff8880548ebe40
      [   53.254238][    C1] FS:  00007f6b86b370c0(0000) GS:ffff88806c200000(0000) knlGS:0000000000000000
      [   53.254243][    C1] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [   53.254248][    C1] CR2: 0000562c62438758 CR3: 000000003f600005 CR4: 00000000000606e0
      [   53.254253][    C1] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      [   53.254257][    C1] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
      [   53.254261][    C1] Call Trace:
      [   53.254266][    C1]  ? lockdep_hardirqs_on_prepare+0x379/0x540
      [   53.254270][    C1]  ? netif_set_real_num_tx_queues+0x780/0x780
      [   53.254275][    C1]  ? rmnet_unregister_real_device+0x56/0x90 [rmnet]
      [   53.254279][    C1]  ? __kasan_slab_free+0x126/0x150
      [   53.254283][    C1]  ? kfree+0xdc/0x320
      [   53.254288][    C1]  ? rmnet_unregister_real_device+0x56/0x90 [rmnet]
      [   53.254293][    C1]  unregister_netdevice_many.part.135+0x13/0x1b0
      [   53.254297][    C1]  rtnl_delete_link+0xbc/0x100
      [   53.254301][    C1]  ? rtnl_af_register+0xc0/0xc0
      [   53.254305][    C1]  rtnl_dellink+0x2dc/0x840
      [   53.254309][    C1]  ? find_held_lock+0x39/0x1d0
      [   53.254314][    C1]  ? valid_fdb_dump_strict+0x620/0x620
      [   53.254318][    C1]  ? rtnetlink_rcv_msg+0x457/0x890
      [   53.254322][    C1]  ? lock_contended+0xd20/0xd20
      [   53.254326][    C1]  rtnetlink_rcv_msg+0x4a8/0x890
      [ ... ]
      [   73.813696][ T1192] unregister_netdevice: waiting for rmnet0 to become free. Usage count = 1
      
      Fixes: 037f9cdf ("net: rmnet: use upper/lower device infrastructure")
      Signed-off-by: NTaehee Yoo <ap420073@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      2a762e9e
    • L
      hinic: fix sending mailbox timeout in aeq event work · 6dbb8901
      Luo bin 提交于
      When sending mailbox in the work of aeq event, another aeq event
      will be triggered. because the last aeq work is not exited and only
      one work can be excuted simultaneously in the same workqueue, mailbox
      sending function will return failure of timeout. We create and use
      another workqueue to fix this.
      Signed-off-by: NLuo bin <luobin9@huawei.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      6dbb8901
  7. 02 7月, 2020 1 次提交
  8. 01 7月, 2020 2 次提交
  9. 27 6月, 2020 2 次提交
  10. 26 6月, 2020 4 次提交
  11. 25 6月, 2020 1 次提交
    • D
      net: bcmgenet: use hardware padding of runt frames · 20d1f2d1
      Doug Berger 提交于
      When commit 474ea9ca ("net: bcmgenet: correctly pad short
      packets") added the call to skb_padto() it should have been
      located before the nr_frags parameter was read since that value
      could be changed when padding packets with lengths between 55
      and 59 bytes (inclusive).
      
      The use of a stale nr_frags value can cause corruption of the
      pad data when tx-scatter-gather is enabled. This corruption of
      the pad can cause invalid checksum computation when hardware
      offload of tx-checksum is also enabled.
      
      Since the original reason for the padding was corrected by
      commit 7dd39913 ("net: bcmgenet: fix skb_len in
      bcmgenet_xmit_single()") we can remove the software padding all
      together and make use of hardware padding of short frames as
      long as the hardware also always appends the FCS value to the
      frame.
      
      Fixes: 474ea9ca ("net: bcmgenet: correctly pad short packets")
      Signed-off-by: NDoug Berger <opendmb@gmail.com>
      Acked-by: NFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      20d1f2d1