1. 05 1月, 2022 1 次提交
    • D
      i40e: fix use-after-free in i40e_sync_filters_subtask() · 3116f59c
      Di Zhu 提交于
      Using ifconfig command to delete the ipv6 address will cause
      the i40e network card driver to delete its internal mac_filter and
      i40e_service_task kernel thread will concurrently access the mac_filter.
      These two processes are not protected by lock
      so causing the following use-after-free problems.
      
       print_address_description+0x70/0x360
       ? vprintk_func+0x5e/0xf0
       kasan_report+0x1b2/0x330
       i40e_sync_vsi_filters+0x4f0/0x1850 [i40e]
       i40e_sync_filters_subtask+0xe3/0x130 [i40e]
       i40e_service_task+0x195/0x24c0 [i40e]
       process_one_work+0x3f5/0x7d0
       worker_thread+0x61/0x6c0
       ? process_one_work+0x7d0/0x7d0
       kthread+0x1c3/0x1f0
       ? kthread_park+0xc0/0xc0
       ret_from_fork+0x35/0x40
      
      Allocated by task 2279810:
       kasan_kmalloc+0xa0/0xd0
       kmem_cache_alloc_trace+0xf3/0x1e0
       i40e_add_filter+0x127/0x2b0 [i40e]
       i40e_add_mac_filter+0x156/0x190 [i40e]
       i40e_addr_sync+0x2d/0x40 [i40e]
       __hw_addr_sync_dev+0x154/0x210
       i40e_set_rx_mode+0x6d/0xf0 [i40e]
       __dev_set_rx_mode+0xfb/0x1f0
       __dev_mc_add+0x6c/0x90
       igmp6_group_added+0x214/0x230
       __ipv6_dev_mc_inc+0x338/0x4f0
       addrconf_join_solict.part.7+0xa2/0xd0
       addrconf_dad_work+0x500/0x980
       process_one_work+0x3f5/0x7d0
       worker_thread+0x61/0x6c0
       kthread+0x1c3/0x1f0
       ret_from_fork+0x35/0x40
      
      Freed by task 2547073:
       __kasan_slab_free+0x130/0x180
       kfree+0x90/0x1b0
       __i40e_del_filter+0xa3/0xf0 [i40e]
       i40e_del_mac_filter+0xf3/0x130 [i40e]
       i40e_addr_unsync+0x85/0xa0 [i40e]
       __hw_addr_sync_dev+0x9d/0x210
       i40e_set_rx_mode+0x6d/0xf0 [i40e]
       __dev_set_rx_mode+0xfb/0x1f0
       __dev_mc_del+0x69/0x80
       igmp6_group_dropped+0x279/0x510
       __ipv6_dev_mc_dec+0x174/0x220
       addrconf_leave_solict.part.8+0xa2/0xd0
       __ipv6_ifa_notify+0x4cd/0x570
       ipv6_ifa_notify+0x58/0x80
       ipv6_del_addr+0x259/0x4a0
       inet6_addr_del+0x188/0x260
       addrconf_del_ifaddr+0xcc/0x130
       inet6_ioctl+0x152/0x190
       sock_do_ioctl+0xd8/0x2b0
       sock_ioctl+0x2e5/0x4c0
       do_vfs_ioctl+0x14e/0xa80
       ksys_ioctl+0x7c/0xa0
       __x64_sys_ioctl+0x42/0x50
       do_syscall_64+0x98/0x2c0
       entry_SYSCALL_64_after_hwframe+0x65/0xca
      
      Fixes: 41c445ff ("i40e: main driver core")
      Signed-off-by: NDi Zhu <zhudi2@huawei.com>
      Signed-off-by: NRui Zhang <zhangrui182@huawei.com>
      Tested-by: NGurucharan G <gurucharanx.g@intel.com>
      Signed-off-by: NTony Nguyen <anthony.l.nguyen@intel.com>
      3116f59c
  2. 18 11月, 2021 5 次提交
  3. 07 10月, 2021 2 次提交
    • S
      i40e: Fix freeing of uninitialized misc IRQ vector · 2e5a2057
      Sylwester Dziedziuch 提交于
      When VSI set up failed in i40e_probe() as part of PF switch set up
      driver was trying to free misc IRQ vectors in
      i40e_clear_interrupt_scheme and produced a kernel Oops:
      
         Trying to free already-free IRQ 266
         WARNING: CPU: 0 PID: 5 at kernel/irq/manage.c:1731 __free_irq+0x9a/0x300
         Workqueue: events work_for_cpu_fn
         RIP: 0010:__free_irq+0x9a/0x300
         Call Trace:
         ? synchronize_irq+0x3a/0xa0
         free_irq+0x2e/0x60
         i40e_clear_interrupt_scheme+0x53/0x190 [i40e]
         i40e_probe.part.108+0x134b/0x1a40 [i40e]
         ? kmem_cache_alloc+0x158/0x1c0
         ? acpi_ut_update_ref_count.part.1+0x8e/0x345
         ? acpi_ut_update_object_reference+0x15e/0x1e2
         ? strstr+0x21/0x70
         ? irq_get_irq_data+0xa/0x20
         ? mp_check_pin_attr+0x13/0xc0
         ? irq_get_irq_data+0xa/0x20
         ? mp_map_pin_to_irq+0xd3/0x2f0
         ? acpi_register_gsi_ioapic+0x93/0x170
         ? pci_conf1_read+0xa4/0x100
         ? pci_bus_read_config_word+0x49/0x70
         ? do_pci_enable_device+0xcc/0x100
         local_pci_probe+0x41/0x90
         work_for_cpu_fn+0x16/0x20
         process_one_work+0x1a7/0x360
         worker_thread+0x1cf/0x390
         ? create_worker+0x1a0/0x1a0
         kthread+0x112/0x130
         ? kthread_flush_work_fn+0x10/0x10
         ret_from_fork+0x1f/0x40
      
      The problem is that at that point misc IRQ vectors
      were not allocated yet and we get a call trace
      that driver is trying to free already free IRQ vectors.
      
      Add a check in i40e_clear_interrupt_scheme for __I40E_MISC_IRQ_REQUESTED
      PF state before calling i40e_free_misc_vector. This state is set only if
      misc IRQ vectors were properly initialized.
      
      Fixes: c17401a1 ("i40e: use separate state bit for miscellaneous IRQ setup")
      Reported-by: NPJ Waskiewicz <pwaskiewicz@jumptrading.com>
      Signed-off-by: NSylwester Dziedziuch <sylwesterx.dziedziuch@intel.com>
      Signed-off-by: NMateusz Palczewski <mateusz.palczewski@intel.com>
      Tested-by: NDave Switzer <david.switzer@intel.com>
      Signed-off-by: NTony Nguyen <anthony.l.nguyen@intel.com>
      2e5a2057
    • J
      i40e: fix endless loop under rtnl · 857b6c6f
      Jiri Benc 提交于
      The loop in i40e_get_capabilities can never end. The problem is that
      although i40e_aq_discover_capabilities returns with an error if there's
      a firmware problem, the returned error is not checked. There is a check for
      pf->hw.aq.asq_last_status but that value is set to I40E_AQ_RC_OK on most
      firmware problems.
      
      When i40e_aq_discover_capabilities encounters a firmware problem, it will
      encounter the same problem on its next invocation. As the result, the loop
      becomes endless. We hit this with I40E_ERR_ADMIN_QUEUE_TIMEOUT but looking
      at the code, it can happen with a range of other firmware errors.
      
      I don't know what the correct behavior should be: whether the firmware
      should be retried a few times, or whether pf->hw.aq.asq_last_status should
      be always set to the encountered firmware error (but then it would be
      pointless and can be just replaced by the i40e_aq_discover_capabilities
      return value). However, the current behavior with an endless loop under the
      rtnl mutex(!) is unacceptable and Intel has not submitted a fix, although we
      explained the bug to them 7 months ago.
      
      This may not be the best possible fix but it's better than hanging the whole
      system on a firmware bug.
      
      Fixes: 56a62fc8 ("i40e: init code and hardware support")
      Tested-by: NStefan Assmann <sassmann@redhat.com>
      Signed-off-by: NJiri Benc <jbenc@redhat.com>
      Reviewed-by: NJesse Brandeburg <jesse.brandeburg@intel.com>
      Tested-by: NDave Switzer <david.switzer@intel.com>
      Signed-off-by: NTony Nguyen <anthony.l.nguyen@intel.com>
      857b6c6f
  4. 02 10月, 2021 1 次提交
  5. 18 8月, 2021 1 次提交
  6. 28 7月, 2021 1 次提交
    • A
      dev_ioctl: split out ndo_eth_ioctl · a7605370
      Arnd Bergmann 提交于
      Most users of ndo_do_ioctl are ethernet drivers that implement
      the MII commands SIOCGMIIPHY/SIOCGMIIREG/SIOCSMIIREG, or hardware
      timestamping with SIOCSHWTSTAMP/SIOCGHWTSTAMP.
      
      Separate these from the few drivers that use ndo_do_ioctl to
      implement SIOCBOND, SIOCBR and SIOCWANDEV commands.
      
      This is a purely cosmetic change intended to help readers find
      their way through the implementation.
      
      Cc: Doug Ledford <dledford@redhat.com>
      Cc: Jason Gunthorpe <jgg@ziepe.ca>
      Cc: Jay Vosburgh <j.vosburgh@gmail.com>
      Cc: Veaceslav Falico <vfalico@gmail.com>
      Cc: Andy Gospodarek <andy@greyhouse.net>
      Cc: Andrew Lunn <andrew@lunn.ch>
      Cc: Vivien Didelot <vivien.didelot@gmail.com>
      Cc: Florian Fainelli <f.fainelli@gmail.com>
      Cc: Vladimir Oltean <olteanv@gmail.com>
      Cc: Leon Romanovsky <leon@kernel.org>
      Cc: linux-rdma@vger.kernel.org
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Acked-by: NJason Gunthorpe <jgg@nvidia.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      a7605370
  7. 23 7月, 2021 3 次提交
  8. 21 7月, 2021 1 次提交
    • P
      i40e: add support for PTP external synchronization clock · 10507130
      Piotr Kwapulinski 提交于
      Add support for external synchronization clock via GPIOs.
      1PPS signals are handled via the dedicated 3 GPIOs: SDP3_2,
      SDP3_3 and GPIO_4.
      Previously it was not possible to use the external PTP
      synchronization clock.
      All possible HW configurations are supported.
      	SDP3_2,	SDP3_3,	GPIO_4
      	off,	off,	off
      	off,	in_A,	off
      	off,	out_A,	off
      	off,	in_B,	off
      	off,	out_B,	off
      	in_A,	off,	off
      	in_A,	in_B,	off
      	in_A,	out_B,	off
      	out_A,	off,	off
      	out_A,	in_B,	off
      	in_B,	off,	off
      	in_B,	in_A,	off
      	in_B,	out_A,	off
      	out_B,	off,	off
      	out_B,	in_A,	off
      	off,	off,	in_A
      	off,	out_A,	in_A
      	off,	in_B,	in_A
      	off,	out_B,	in_A
      	out_A,	off,	in_A
      	out_A,	in_B,	in_A
      	in_B,	off,	in_A
      	in_B,	out_A,	in_A
      	out_B,	off,	in_A
      	off,	off,	out_A
      	off,	in_A,	out_A
      	off,	in_B,	out_A
      	off,	out_B,	out_A
      	in_A,	off,	out_A
      	in_A,	in_B,	out_A
      	in_A,	out_B,	out_A
      	in_B,	off,	out_A
      	in_B,	in_A,	out_A
      	out_B,	off,	out_A
      	out_B,	in_A,	out_A
      	off,	off,	in_B
      	off,	in_A,	in_B
      	off,	out_A,	in_B
      	off,	out_B,	in_B
      	in_A,	off,	in_B
      	in_A,	out_B,	in_B
      	out_A,	off,	in_B
      	out_B,	off,	in_B
      	out_B,	in_A,	in_B
      	off,	off,	out_B
      	off,	in_A,	out_B
      	off,	out_A,	out_B
      	off,	in_B,	out_B
      	in_A,	off,	out_B
      	in_A,	in_B,	out_B
      	out_A,	off,	out_B
      	out_A,	in_B,	out_B
      	in_B,	off,	out_B
      	in_B,	in_A,	out_B
      	in_B,	out_A,	out_B
      
      Tested with oscilloscope, 1PPS generator and ts2phc.
      Reviewed-by: NAleksandr Loktionov <aleksandr.loktionov@intel.com>
      Reviewed-by: NArkadiusz Kubalewski <arkadiusz.kubalewski@intel.com>
      Signed-off-by: NPiotr Kwapulinski <piotr.kwapulinski@intel.com>
      Tested-by: NAshish K <ashishx.k@intel.com>
      Signed-off-by: NTony Nguyen <anthony.l.nguyen@intel.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      10507130
  9. 25 6月, 2021 2 次提交
  10. 29 5月, 2021 1 次提交
  11. 08 5月, 2021 1 次提交
  12. 24 4月, 2021 3 次提交
  13. 16 4月, 2021 1 次提交
    • J
      i40e: fix the panic when running bpf in xdpdrv mode · 4e39a072
      Jason Xing 提交于
      Fix this panic by adding more rules to calculate the value of @rss_size_max
      which could be used in allocating the queues when bpf is loaded, which,
      however, could cause the failure and then trigger the NULL pointer of
      vsi->rx_rings. Prio to this fix, the machine doesn't care about how many
      cpus are online and then allocates 256 queues on the machine with 32 cpus
      online actually.
      
      Once the load of bpf begins, the log will go like this "failed to get
      tracking for 256 queues for VSI 0 err -12" and this "setup of MAIN VSI
      failed".
      
      Thus, I attach the key information of the crash-log here.
      
      BUG: unable to handle kernel NULL pointer dereference at
      0000000000000000
      RIP: 0010:i40e_xdp+0xdd/0x1b0 [i40e]
      Call Trace:
      [2160294.717292]  ? i40e_reconfig_rss_queues+0x170/0x170 [i40e]
      [2160294.717666]  dev_xdp_install+0x4f/0x70
      [2160294.718036]  dev_change_xdp_fd+0x11f/0x230
      [2160294.718380]  ? dev_disable_lro+0xe0/0xe0
      [2160294.718705]  do_setlink+0xac7/0xe70
      [2160294.719035]  ? __nla_parse+0xed/0x120
      [2160294.719365]  rtnl_newlink+0x73b/0x860
      
      Fixes: 41c445ff ("i40e: main driver core")
      Co-developed-by: NShujin Li <lishujin@kuaishou.com>
      Signed-off-by: NShujin Li <lishujin@kuaishou.com>
      Signed-off-by: NJason Xing <xingwanli@kuaishou.com>
      Reviewed-by: NJesse Brandeburg <jesse.brandeburg@intel.com>
      Acked-by: NJesper Dangaard Brouer <brouer@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      4e39a072
  14. 09 4月, 2021 2 次提交
  15. 02 4月, 2021 1 次提交
  16. 31 3月, 2021 1 次提交
  17. 26 3月, 2021 1 次提交
  18. 24 3月, 2021 1 次提交
  19. 12 3月, 2021 1 次提交
  20. 20 2月, 2021 2 次提交
  21. 19 2月, 2021 5 次提交
  22. 13 2月, 2021 1 次提交
  23. 11 2月, 2021 2 次提交
    • K
      i40e: remove the useless value assignment in i40e_clean_adminq_subtask · bfe2e5c4
      Kaixu Xia 提交于
      The variable ret is overwritten by the following call
      i40e_clean_arq_element() and the assignment is useless, so remove it.
      Reported-by: NTosk Robot <tencent_os_robot@tencent.com>
      Signed-off-by: NKaixu Xia <kaixuxia@tencent.com>
      Tested-by: NTony Brelinski <tonyx.brelinski@intel.com>
      Signed-off-by: NTony Nguyen <anthony.l.nguyen@intel.com>
      bfe2e5c4
    • P
      i40e: Add flow director support for IPv6 · efca91e8
      Przemyslaw Patynowski 提交于
      Flow director for IPv6 is not supported.
      1) Implementation of support for IPv6 flow director.
      2) Added handlers for addition of TCP6, UDP6, SCTP6, IPv6.
      3) Refactored legacy code to make it more generic.
      4) Added packet templates for TCP6, UDP6, SCTP6, IPv6.
      5) Added handling of IPv6 source and destination address for flow director.
      6) Improved argument passing for source and destination portin TCP6, UDP6
         and SCTP6.
      7) Added handling of ethtool -n for IPv6, TCP6,UDP6, SCTP6.
      8) Used correct bit flag regarding FLEXOFF field of flow director data
         descriptor.
      
      Without this patch, there would be no support for flow director on IPv6,
      TCP6, UDP6, SCTP6.
      Tested based on x710 datasheet by using:
      ethtool -N enp133s0f0 flow-type tcp4 src-port 13 dst-port 37 user-def 0x44142 action 1
      ethtool -N enp133s0f0 flow-type tcp6 src-port 13 dst-port 40 user-def 0x44142 action 2
      ethtool -N enp133s0f0 flow-type udp4 src-port 20 dst-port 40 user-def 0x44142 action 3
      ethtool -N enp133s0f0 flow-type udp6 src-port 25 dst-port 40 user-def 0x44142 action 4
      ethtool -N enp133s0f0 flow-type sctp4 src-port 55 dst-port 65 user-def 0x44142 action 5
      ethtool -N enp133s0f0 flow-type sctp6 src-port 60 dst-port 40 user-def 0x44142 action 6
      ethtool -N enp133s0f0 flow-type ip4 src-ip 1.1.1.1 dst-ip 1.1.1.4 user-def 0x44142 action 7
      ethtool -N enp133s0f0 flow-type ip6 src-ip fe80::3efd:feff:fe6f:bbbb dst-ip fe80::3efd:feff:fe6f:aaaa user-def 0x44142 action 8
      Then send traffic from client which matches the criteria provided to ethtool.
      Observe that packets are redirected to user set queues with ethtool -S <interface>
      Signed-off-by: NPrzemyslaw Patynowski <przemyslawx.patynowski@intel.com>
      Tested-by: NTony Brelinski <tonyx.brelinski@intel.com>
      Signed-off-by: NTony Nguyen <anthony.l.nguyen@intel.com>
      efca91e8