1. 09 4月, 2021 1 次提交
    • Y
      ice: fix memory leak of aRFS after resuming from suspend · 1831da7e
      Yongxin Liu 提交于
      In ice_suspend(), ice_clear_interrupt_scheme() is called, and then
      irq_free_descs() will be eventually called to free irq and its descriptor.
      
      In ice_resume(), ice_init_interrupt_scheme() is called to allocate new
      irqs. However, in ice_rebuild_arfs(), struct irq_glue and struct cpu_rmap
      maybe cannot be freed, if the irqs that released in ice_suspend() were
      reassigned to other devices, which makes irq descriptor's affinity_notify
      lost.
      
      So call ice_free_cpu_rx_rmap() before ice_clear_interrupt_scheme(), which
      can make sure all irq_glue and cpu_rmap can be correctly released before
      corresponding irq and descriptor are released.
      
      Fix the following memory leak.
      
      unreferenced object 0xffff95bd951afc00 (size 512):
        comm "kworker/0:1", pid 134, jiffies 4294684283 (age 13051.958s)
        hex dump (first 32 bytes):
          18 00 00 00 18 00 18 00 70 fc 1a 95 bd 95 ff ff  ........p.......
          00 00 ff ff 01 00 ff ff 02 00 ff ff 03 00 ff ff  ................
        backtrace:
          [<0000000072e4b914>] __kmalloc+0x336/0x540
          [<0000000054642a87>] alloc_cpu_rmap+0x3b/0xb0
          [<00000000f220deec>] ice_set_cpu_rx_rmap+0x6a/0x110 [ice]
          [<000000002370a632>] ice_probe+0x941/0x1180 [ice]
          [<00000000d692edba>] local_pci_probe+0x47/0xa0
          [<00000000503934f0>] work_for_cpu_fn+0x1a/0x30
          [<00000000555a9e4a>] process_one_work+0x1dd/0x410
          [<000000002c4b414a>] worker_thread+0x221/0x3f0
          [<00000000bb2b556b>] kthread+0x14c/0x170
          [<00000000ad2cf1cd>] ret_from_fork+0x1f/0x30
      unreferenced object 0xffff95bd81b0a2a0 (size 96):
        comm "kworker/0:1", pid 134, jiffies 4294684283 (age 13051.958s)
        hex dump (first 32 bytes):
          38 00 00 00 01 00 00 00 e0 ff ff ff 0f 00 00 00  8...............
          b0 a2 b0 81 bd 95 ff ff b0 a2 b0 81 bd 95 ff ff  ................
        backtrace:
          [<00000000582dd5c5>] kmem_cache_alloc_trace+0x31f/0x4c0
          [<000000002659850d>] irq_cpu_rmap_add+0x25/0xe0
          [<00000000495a3055>] ice_set_cpu_rx_rmap+0xb4/0x110 [ice]
          [<000000002370a632>] ice_probe+0x941/0x1180 [ice]
          [<00000000d692edba>] local_pci_probe+0x47/0xa0
          [<00000000503934f0>] work_for_cpu_fn+0x1a/0x30
          [<00000000555a9e4a>] process_one_work+0x1dd/0x410
          [<000000002c4b414a>] worker_thread+0x221/0x3f0
          [<00000000bb2b556b>] kthread+0x14c/0x170
          [<00000000ad2cf1cd>] ret_from_fork+0x1f/0x30
      
      Fixes: 769c500d ("ice: Add advanced power mgmt for WoL")
      Signed-off-by: NYongxin Liu <yongxin.liu@windriver.com>
      Tested-by: NTony Brelinski <tonyx.brelinski@intel.com>
      Signed-off-by: NTony Nguyen <anthony.l.nguyen@intel.com>
      1831da7e
  2. 08 4月, 2021 8 次提交
  3. 01 4月, 2021 5 次提交
  4. 30 3月, 2021 3 次提交
  5. 24 3月, 2021 1 次提交
  6. 23 3月, 2021 2 次提交
  7. 13 2月, 2021 1 次提交
  8. 09 2月, 2021 5 次提交
  9. 06 2月, 2021 3 次提交
    • B
      ice: remove dead code · 12aae8f1
      Bruce Allan 提交于
      The check for a NULL pf pointer is moot since the earlier declaration and
      assignment of struct device *dev already de-referenced the pointer.  Also,
      the only caller of ice_set_dflt_mib() already ensures pf is not NULL.
      
      Cc: Dave Ertman <david.m.ertman@intel.com>
      Reported-by: Nkernel test robot <lkp@intel.com>
      Reported-by: NDan Carpenter <dan.carpenter@oracle.com>
      Signed-off-by: NBruce Allan <bruce.w.allan@intel.com>
      Tested-by: NTony Brelinski <tonyx.brelinski@intel.com>
      Signed-off-by: NTony Nguyen <anthony.l.nguyen@intel.com>
      12aae8f1
    • G
      ice: Replace one-element array with flexible-array member · e94c0df9
      Gustavo A. R. Silva 提交于
      There is a regular need in the kernel to provide a way to declare having
      a dynamically sized set of trailing elements in a structure. Kernel code
      should always use “flexible array members”[1] for these cases. The older
      style of one-element or zero-length arrays should no longer be used[2].
      
      Refactor the code according to the use of a flexible-array member in
      struct ice_res_tracker, instead of a one-element array and use the
      struct_size() helper to calculate the size for the allocations.
      
      Also, notice that the code below suggests that, currently, two too many
      bytes are being allocated with devm_kzalloc(), as the total number of
      entries (pf->irq_tracker->num_entries) for pf->irq_tracker->list[] is
      _vectors_ and sizeof(*pf->irq_tracker) also includes the size of the
      one-element array _list_ in struct ice_res_tracker.
      
      drivers/net/ethernet/intel/ice/ice_main.c:3511:
      3511         /* populate SW interrupts pool with number of OS granted IRQs. */
      3512         pf->num_avail_sw_msix = (u16)vectors;
      3513         pf->irq_tracker->num_entries = (u16)vectors;
      3514         pf->irq_tracker->end = pf->irq_tracker->num_entries;
      
      With this change, the right amount of dynamic memory is now allocated
      because, contrary to one-element arrays which occupy at least as much
      space as a single object of the type, flexible-array members don't
      occupy such space in the containing structure.
      
      [1] https://en.wikipedia.org/wiki/Flexible_array_member
      [2] https://www.kernel.org/doc/html/v5.9-rc1/process/deprecated.html#zero-length-and-one-element-arraysBuilt-tested-by: Nkernel test robot <lkp@intel.com>
      Signed-off-by: NGustavo A. R. Silva <gustavoars@kernel.org>
      Tested-by: NTony Brelinski <tonyx.brelinski@intel.com>
      Signed-off-by: NTony Nguyen <anthony.l.nguyen@intel.com>
      e94c0df9
    • J
      ice: display stored netlist versions via devlink info · e120a9ab
      Jacob Keller 提交于
      Add a function to read the inactive netlist bank for version
      information. To support this, refactor how we read the netlist version
      data. Instead of using the firmware AQ interface with a module ID, read
      from the flash as a flat NVM, using ice_read_flash_module.
      
      This change requires a slight adjustment to the offset values used, as
      reading from the flat NVM includes the type field (which was stripped by
      firmware previously). Cleanup the macro names and move them to
      ice_type.h. For clarity in how we calculate the offsets and so that
      programmers can easily map the offset value to the data sheet, use
      a wrapper macro to account for the offset adjustments.
      
      Use the newly added ice_get_inactive_netlist_ver function to extract the
      version data from the pending netlist module update. Add the stored
      variants of "fw.netlist", and "fw.netlist.build" to the info version map
      array.
      
      With this change, we now report the "fw.netlist" and "fw.netlist.build"
      versions into the stored section of the devlink info report. As with the
      main NVM module versions, if there is no pending update, we report the
      currently active values as stored.
      Signed-off-by: NJacob Keller <jacob.e.keller@intel.com>
      Tested-by: NTony Brelinski <tonyx.brelinski@intel.com>
      Signed-off-by: NTony Nguyen <anthony.l.nguyen@intel.com>
      e120a9ab
  10. 27 1月, 2021 2 次提交
    • B
      ice: Fix MSI-X vector fallback logic · f3fe97f6
      Brett Creeley 提交于
      The current MSI-X enablement logic tries to enable best-case MSI-X
      vectors and if that fails we only support a bare-minimum set. This
      includes a single MSI-X for 1 Tx and 1 Rx queue and a single MSI-X
      for the OICR interrupt. Unfortunately, the driver fails to load when we
      don't get as many MSI-X as requested for a couple reasons.
      
      First, the code to allocate MSI-X in the driver tries to allocate
      num_online_cpus() MSI-X for LAN traffic without caring about the number
      of MSI-X actually enabled/requested from the kernel for LAN traffic.
      So, when calling ice_get_res() for the PF VSI, it returns failure
      because the number of available vectors is less than requested. Fix
      this by not allowing the PF VSI to allocation  more than
      pf->num_lan_msix MSI-X vectors and pf->num_lan_msix Rx/Tx queues.
      Limiting the number of queues is done because we don't want more than
      1 Tx/Rx queue per interrupt due to performance conerns.
      
      Second, the driver assigns pf->num_lan_msix = 2, to account for LAN
      traffic and the OICR. However, pf->num_lan_msix is only meant for LAN
      MSI-X. This is causing a failure when the PF VSI tries to
      allocate/reserve the minimum pf->num_lan_msix because the OICR MSI-X has
      already been reserved, so there may not be enough MSI-X vectors left.
      Fix this by setting pf->num_lan_msix = 1 for the failure case. Then the
      ICE_MIN_MSIX accounts for the LAN MSI-X and the OICR MSI-X needed for
      the failure case.
      
      Update the related defines used in ice_ena_msix_range() to align with
      the above behavior and remove the unused RDMA defines because RDMA is
      currently not supported. Also, remove the now incorrect comment.
      
      Fixes: 152b978a ("ice: Rework ice_ena_msix_range")
      Signed-off-by: NBrett Creeley <brett.creeley@intel.com>
      Tested-by: NTony Brelinski <tonyx.brelinski@intel.com>
      Signed-off-by: NTony Nguyen <anthony.l.nguyen@intel.com>
      f3fe97f6
    • N
      ice: update dev_addr in ice_set_mac_address even if HW filter exists · 13ed5e8a
      Nick Nunley 提交于
      Fix the driver to copy the MAC address configured in ndo_set_mac_address
      into dev_addr, even if the MAC filter already exists in HW. In some
      situations (e.g. bonding) the netdev's dev_addr could have been modified
      outside of the driver, with no change to the HW filter, so the driver
      cannot assume that they match.
      
      Fixes: 757976ab ("ice: Fix check for removing/adding mac filters")
      Signed-off-by: NNick Nunley <nicholas.d.nunley@intel.com>
      Tested-by: NTony Brelinski <tonyx.brelinski@intel.com>
      Signed-off-by: NTony Nguyen <anthony.l.nguyen@intel.com>
      13ed5e8a
  11. 08 1月, 2021 1 次提交
  12. 10 12月, 2020 2 次提交
  13. 10 10月, 2020 3 次提交
    • J
      ice: add additional debug logging for firmware update · 1e8249cc
      Jacob Keller 提交于
      While debugging a recent failure to update the flash of an ice device,
      I found it helpful to add additional logging which helped determine the
      root cause of the problem being a timeout issue.
      
      Add some extra dev_dbg() logging messages which can be enabled using the
      dynamic debug facility, including one for ice_aq_wait_for_event that
      will use jiffies to capture a rough estimate of how long we waited for
      the completion of a firmware command.
      Signed-off-by: NJacob Keller <jacob.e.keller@intel.com>
      Tested-by: NBrijesh Behera <brijeshx.behera@intel.com>
      Signed-off-by: NTony Nguyen <anthony.l.nguyen@intel.com>
      Signed-off-by: NJakub Kicinski <kuba@kernel.org>
      1e8249cc
    • J
      ice: refactor devlink_port to be per-VSI · 48d40025
      Jacob Keller 提交于
      Currently, the devlink_port structure is stored within the ice_pf. This
      made sense because we create a single devlink_port for each PF. This
      setup does not mesh with the abstractions in the driver very well, and
      led to a flow where we accidentally call devlink_port_unregister twice
      during error cleanup.
      
      In particular, if devlink_port_register or devlink_port_unregister are
      called twice, this leads to a kernel panic. This appears to occur during
      some possible flows while cleaning up from a failure during driver
      probe.
      
      If register_netdev fails, then we will call devlink_port_unregister in
      ice_cfg_netdev as it cleans up. Later, we again call
      devlink_port_unregister since we assume that we must cleanup the port
      that is associated with the PF structure.
      
      This occurs because we cleanup the devlink_port for the main PF even
      though it was not allocated. We allocated the port within a per-VSI
      function for managing the main netdev, but did not release the port when
      cleaning up that VSI, the allocation and destruction are not aligned.
      
      Instead of attempting to manage the devlink_port as part of the PF
      structure, manage it as part of the PF VSI. Doing this has advantages,
      as we can match the de-allocation of the devlink_port with the
      unregister_netdev associated with the main PF VSI.
      
      Moving the port to the VSI is preferable as it paves the way for
      handling devlink ports allocated for other purposes such as SR-IOV VFs.
      
      Since we're changing up how we allocate the devlink_port, also change
      the indexing. Originally, we indexed the port using the PF id number.
      This came from an old goal of sharing a devlink for each physical
      function. Managing devlink instances across multiple function drivers is
      not workable. Instead, lets set the port number to the logical port
      number returned by firmware and set the index using the VSI index
      (sometimes referred to as VSI handle).
      Signed-off-by: NJacob Keller <jacob.e.keller@intel.com>
      Tested-by: NAaron Brown <aaron.f.brown@intel.com>
      Signed-off-by: NTony Nguyen <anthony.l.nguyen@intel.com>
      Signed-off-by: NJakub Kicinski <kuba@kernel.org>
      48d40025
    • B
      ice: remove repeated words · ac382a09
      Bruce Allan 提交于
      A new test in checkpatch detects repeated words; cleanup all pre-existing
      occurrences of those now.
      Signed-off-by: NBruce Allan <bruce.w.allan@intel.com>
      Tested-by: NAaron Brown <aaron.f.brown@intel.com>
      Co-developed-by: NTony Nguyen <anthony.l.nguyen@intel.com>
      Signed-off-by: NTony Nguyen <anthony.l.nguyen@intel.com>
      Signed-off-by: NJakub Kicinski <kuba@kernel.org>
      ac382a09
  14. 30 9月, 2020 1 次提交
  15. 29 9月, 2020 1 次提交
  16. 25 9月, 2020 1 次提交
    • J
      ice: fix memory leak if register_netdev_fails · 135f4b9e
      Jacob Keller 提交于
      The ice_setup_pf_sw function can cause a memory leak if register_netdev
      fails, due to accidentally failing to free the VSI rings. Fix the memory
      leak by using ice_vsi_release, ensuring we actually go through the full
      teardown process.
      
      This should be safe even if the netdevice is not registered because we
      will have set the netdev pointer to NULL, ensuring ice_vsi_release won't
      call unregister_netdev.
      
      An alternative fix would be moving management of the PF VSI netdev into
      the main VSI setup code. This is complicated and likely requires
      significant refactor in how we manage VSIs
      
      Fixes: 3a858ba3 ("ice: Add support for VSI allocation and deallocation")
      Signed-off-by: NJacob Keller <jacob.e.keller@intel.com>
      Tested-by: NAaron Brown <aaron.f.brown@intel.com>
      Signed-off-by: NTony Nguyen <anthony.l.nguyen@intel.com>
      135f4b9e