1. 11 5月, 2022 1 次提交
  2. 08 2月, 2022 1 次提交
    • C
      igc: avoid kernel warning when changing RX ring parameters · 453307b5
      Corinna Vinschen 提交于
      Calling ethtool changing the RX ring parameters like this:
      
        $ ethtool -G eth0 rx 1024
      
      on igc triggers kernel warnings like this:
      
      [  225.198467] ------------[ cut here ]------------
      [  225.198473] Missing unregister, handled but fix driver
      [  225.198485] WARNING: CPU: 7 PID: 959 at net/core/xdp.c:168
      xdp_rxq_info_reg+0x79/0xd0
      [...]
      [  225.198601] Call Trace:
      [  225.198604]  <TASK>
      [  225.198609]  igc_setup_rx_resources+0x3f/0xe0 [igc]
      [  225.198617]  igc_ethtool_set_ringparam+0x30e/0x450 [igc]
      [  225.198626]  ethnl_set_rings+0x18a/0x250
      [  225.198631]  genl_family_rcv_msg_doit+0xca/0x110
      [  225.198637]  genl_rcv_msg+0xce/0x1c0
      [  225.198640]  ? rings_prepare_data+0x60/0x60
      [  225.198644]  ? genl_get_cmd+0xd0/0xd0
      [  225.198647]  netlink_rcv_skb+0x4e/0xf0
      [  225.198652]  genl_rcv+0x24/0x40
      [  225.198655]  netlink_unicast+0x20e/0x330
      [  225.198659]  netlink_sendmsg+0x23f/0x480
      [  225.198663]  sock_sendmsg+0x5b/0x60
      [  225.198667]  __sys_sendto+0xf0/0x160
      [  225.198671]  ? handle_mm_fault+0xb2/0x280
      [  225.198676]  ? do_user_addr_fault+0x1eb/0x690
      [  225.198680]  __x64_sys_sendto+0x20/0x30
      [  225.198683]  do_syscall_64+0x38/0x90
      [  225.198687]  entry_SYSCALL_64_after_hwframe+0x44/0xae
      [  225.198693] RIP: 0033:0x7f7ae38ac3aa
      
      igc_ethtool_set_ringparam() copies the igc_ring structure but neglects to
      reset the xdp_rxq_info member before calling igc_setup_rx_resources().
      This in turn calls xdp_rxq_info_reg() with an already registered xdp_rxq_info.
      
      Make sure to unregister the xdp_rxq_info structure first in
      igc_setup_rx_resources.
      
      Fixes: 73f1071c ("igc: Add support for XDP_TX action")
      Reported-by: NLennert Buytenhek <buytenh@arista.com>
      Signed-off-by: NCorinna Vinschen <vinschen@redhat.com>
      Acked-by: NVinicius Costa Gomes <vinicius.gomes@intel.com>
      Tested-by: NDvora Fuxbrumer <dvorax.fuxbrumer@linux.intel.com>
      Signed-off-by: NTony Nguyen <anthony.l.nguyen@intel.com>
      453307b5
  3. 01 2月, 2022 1 次提交
  4. 28 1月, 2022 1 次提交
  5. 29 12月, 2021 2 次提交
  6. 14 12月, 2021 1 次提交
  7. 01 12月, 2021 2 次提交
  8. 30 10月, 2021 1 次提交
  9. 05 10月, 2021 1 次提交
  10. 16 9月, 2021 1 次提交
    • P
      igc: fix tunnel offloading · 40ee363c
      Paolo Abeni 提交于
      Checking tunnel offloading, it turns out that offloading doesn't work
      as expected.  The following script allows to reproduce the issue.
      Call it as `testscript DEVICE LOCALIP REMOTEIP NETMASK'
      
      === SNIP ===
      if [ $# -ne 4 ]
      then
        echo "Usage $0 DEVICE LOCALIP REMOTEIP NETMASK"
        exit 1
      fi
      DEVICE="$1"
      LOCAL_ADDRESS="$2"
      REMOTE_ADDRESS="$3"
      NWMASK="$4"
      echo "Driver: $(ethtool -i ${DEVICE} | awk '/^driver:/{print $2}') "
      ethtool -k "${DEVICE}" | grep tx-udp
      echo
      echo "Set up NIC and tunnel..."
      ip addr add "${LOCAL_ADDRESS}/${NWMASK}" dev "${DEVICE}"
      ip link set "${DEVICE}" up
      sleep 2
      ip link add vxlan1 type vxlan id 42 \
      		   remote "${REMOTE_ADDRESS}" \
      		   local "${LOCAL_ADDRESS}" \
      		   dstport 0 \
      		   dev "${DEVICE}"
      ip addr add fc00::1/64 dev vxlan1
      ip link set vxlan1 up
      sleep 2
      rm -f vxlan.pcap
      echo "Running tcpdump and iperf3..."
      ( nohup tcpdump -i any -w vxlan.pcap >/dev/null 2>&1 ) &
      sleep 2
      iperf3 -c fc00::2 >/dev/null
      pkill tcpdump
      echo
      echo -n "Max. Paket Size: "
      tcpdump -r vxlan.pcap -nnle 2>/dev/null \
      | grep "${LOCAL_ADDRESS}.*> ${REMOTE_ADDRESS}.*OTV" \
      | awk '{print $8}' | awk -F ':' '{print $1}' \
      | sort -n | tail -1
      echo
      ip link del vxlan1
      ip addr del ${LOCAL_ADDRESS}/${NWMASK} dev "${DEVICE}"
      === SNAP ===
      
      The expected outcome is
      
        Max. Paket Size: 64904
      
      This is what you see on igb, the code igc has been taken from.
      However, on igc the output is
      
        Max. Paket Size: 1516
      
      so the GSO aggregate packets are segmented by the kernel before calling
      igc_xmit_frame.  Inside the subsequent call to igc_tso, the check for
      skb_is_gso(skb) fails and the function returns prematurely.
      
      It turns out that this occurs because the feature flags aren't set
      entirely correctly in igc_probe.  In contrast to the original code
      from igb_probe, igc_probe neglects to set the flags required to allow
      tunnel offloading.
      
      Setting the same flags as igb fixes the issue on igc.
      
      Fixes: 34428dff ("igc: Add GSO partial support")
      Signed-off-by: NPaolo Abeni <pabeni@redhat.com>
      Tested-by: NCorinna Vinschen <vinschen@redhat.com>
      Acked-by: NSasha Neftin <sasha.neftin@intel.com>
      Tested-by: NNechama Kraus <nechamax.kraus@linux.intel.com>
      Signed-off-by: NTony Nguyen <anthony.l.nguyen@intel.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      40ee363c
  11. 28 8月, 2021 3 次提交
  12. 25 8月, 2021 1 次提交
  13. 20 8月, 2021 2 次提交
  14. 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
  15. 21 7月, 2021 4 次提交
  16. 20 7月, 2021 1 次提交
  17. 17 7月, 2021 4 次提交
  18. 02 7月, 2021 2 次提交
    • C
      igc: Fix an error handling path in 'igc_probe()' · c6bc9e5c
      Christophe JAILLET 提交于
      If an error occurs after a 'pci_enable_pcie_error_reporting()' call, it
      must be undone by a corresponding 'pci_disable_pcie_error_reporting()'
      call, as already done in the remove function.
      
      Fixes: c9a11c23 ("igc: Add netdev")
      Signed-off-by: NChristophe JAILLET <christophe.jaillet@wanadoo.fr>
      Tested-by: NDvora Fuxbrumer <dvorax.fuxbrumer@linux.intel.com>
      Acked-by: NSasha Neftin <sasha.neftin@intel.com>
      Signed-off-by: NTony Nguyen <anthony.l.nguyen@intel.com>
      c6bc9e5c
    • V
      igc: Fix use-after-free error during reset · 56ea7ed1
      Vinicius Costa Gomes 提交于
      Cleans the next descriptor to watch (next_to_watch) when cleaning the
      TX ring.
      
      Failure to do so can cause invalid memory accesses. If igc_poll() runs
      while the controller is being reset this can lead to the driver try to
      free a skb that was already freed.
      
      Log message:
      
       [  101.525242] refcount_t: underflow; use-after-free.
       [  101.525251] WARNING: CPU: 1 PID: 646 at lib/refcount.c:28 refcount_warn_saturate+0xab/0xf0
       [  101.525259] Modules linked in: sch_etf(E) sch_mqprio(E) rfkill(E) intel_rapl_msr(E) intel_rapl_common(E)
       x86_pkg_temp_thermal(E) intel_powerclamp(E) coretemp(E) binfmt_misc(E) kvm_intel(E) kvm(E) irqbypass(E) crc32_pclmul(E)
       ghash_clmulni_intel(E) aesni_intel(E) mei_wdt(E) libaes(E) crypto_simd(E) cryptd(E) glue_helper(E) snd_hda_codec_hdmi(E)
       rapl(E) intel_cstate(E) snd_hda_intel(E) snd_intel_dspcfg(E) sg(E) soundwire_intel(E) intel_uncore(E) at24(E)
       soundwire_generic_allocation(E) iTCO_wdt(E) soundwire_cadence(E) intel_pmc_bxt(E) serio_raw(E) snd_hda_codec(E)
       iTCO_vendor_support(E) watchdog(E) snd_hda_core(E) snd_hwdep(E) snd_soc_core(E) snd_compress(E) snd_pcsp(E)
       soundwire_bus(E) snd_pcm(E) evdev(E) snd_timer(E) mei_me(E) snd(E) soundcore(E) mei(E) configfs(E) ip_tables(E) x_tables(E)
       autofs4(E) ext4(E) crc32c_generic(E) crc16(E) mbcache(E) jbd2(E) sd_mod(E) t10_pi(E) crc_t10dif(E) crct10dif_generic(E)
       i915(E) ahci(E) libahci(E) ehci_pci(E) igb(E) xhci_pci(E) ehci_hcd(E)
       [  101.525303]  drm_kms_helper(E) dca(E) xhci_hcd(E) libata(E) crct10dif_pclmul(E) cec(E) crct10dif_common(E) tsn(E) igc(E)
       e1000e(E) ptp(E) i2c_i801(E) crc32c_intel(E) psmouse(E) i2c_algo_bit(E) i2c_smbus(E) scsi_mod(E) lpc_ich(E) pps_core(E)
       usbcore(E) drm(E) button(E) video(E)
       [  101.525318] CPU: 1 PID: 646 Comm: irq/37-enp7s0-T Tainted: G            E     5.10.30-rt37-tsn1-rt-ipipe #ipipe
       [  101.525320] Hardware name: SIEMENS AG SIMATIC IPC427D/A5E31233588, BIOS V17.02.09 03/31/2017
       [  101.525322] RIP: 0010:refcount_warn_saturate+0xab/0xf0
       [  101.525325] Code: 05 31 48 44 01 01 e8 f0 c6 42 00 0f 0b c3 80 3d 1f 48 44 01 00 75 90 48 c7 c7 78 a8 f3 a6 c6 05 0f 48
       44 01 01 e8 d1 c6 42 00 <0f> 0b c3 80 3d fe 47 44 01 00 0f 85 6d ff ff ff 48 c7 c7 d0 a8 f3
       [  101.525327] RSP: 0018:ffffbdedc0917cb8 EFLAGS: 00010286
       [  101.525329] RAX: 0000000000000000 RBX: ffff98fd6becbf40 RCX: 0000000000000001
       [  101.525330] RDX: 0000000000000001 RSI: ffffffffa6f2700c RDI: 00000000ffffffff
       [  101.525332] RBP: ffff98fd6becc14c R08: ffffffffa7463d00 R09: ffffbdedc0917c50
       [  101.525333] R10: ffffffffa74c3578 R11: 0000000000000034 R12: 00000000ffffff00
       [  101.525335] R13: ffff98fd6b0b1000 R14: 0000000000000039 R15: ffff98fd6be35c40
       [  101.525337] FS:  0000000000000000(0000) GS:ffff98fd6e240000(0000) knlGS:0000000000000000
       [  101.525339] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
       [  101.525341] CR2: 00007f34135a3a70 CR3: 0000000150210003 CR4: 00000000001706e0
       [  101.525343] Call Trace:
       [  101.525346]  sock_wfree+0x9c/0xa0
       [  101.525353]  unix_destruct_scm+0x7b/0xa0
       [  101.525358]  skb_release_head_state+0x40/0x90
       [  101.525362]  skb_release_all+0xe/0x30
       [  101.525364]  napi_consume_skb+0x57/0x160
       [  101.525367]  igc_poll+0xb7/0xc80 [igc]
       [  101.525376]  ? sched_clock+0x5/0x10
       [  101.525381]  ? sched_clock_cpu+0xe/0x100
       [  101.525385]  net_rx_action+0x14c/0x410
       [  101.525388]  __do_softirq+0xe9/0x2f4
       [  101.525391]  __local_bh_enable_ip+0xe3/0x110
       [  101.525395]  ? irq_finalize_oneshot.part.47+0xe0/0xe0
       [  101.525398]  irq_forced_thread_fn+0x6a/0x80
       [  101.525401]  irq_thread+0xe8/0x180
       [  101.525403]  ? wake_threads_waitq+0x30/0x30
       [  101.525406]  ? irq_thread_check_affinity+0xd0/0xd0
       [  101.525408]  kthread+0x183/0x1a0
       [  101.525412]  ? kthread_park+0x80/0x80
       [  101.525415]  ret_from_fork+0x22/0x30
      
      Fixes: 13b5b7fd ("igc: Add support for Tx/Rx rings")
      Reported-by: NErez Geva <erez.geva.ext@siemens.com>
      Signed-off-by: NVinicius Costa Gomes <vinicius.gomes@intel.com>
      Tested-by: NDvora Fuxbrumer <dvorax.fuxbrumer@linux.intel.com>
      Signed-off-by: NTony Nguyen <anthony.l.nguyen@intel.com>
      56ea7ed1
  19. 25 6月, 2021 1 次提交
    • T
      intel: Remove rcu_read_lock() around XDP program invocation · 49589b23
      Toke Høiland-Jørgensen 提交于
      The Intel drivers all have rcu_read_lock()/rcu_read_unlock() pairs around
      XDP program invocations. However, the actual lifetime of the objects
      referred by the XDP program invocation is longer, all the way through to
      the call to xdp_do_flush(), making the scope of the rcu_read_lock() too
      small. This turns out to be harmless because it all happens in a single
      NAPI poll cycle (and thus under local_bh_disable()), but it makes the
      rcu_read_lock() misleading.
      
      Rather than extend the scope of the rcu_read_lock(), just get rid of it
      entirely. With the addition of RCU annotations to the XDP_REDIRECT map
      types that take bh execution into account, lockdep even understands this to
      be safe, so there's really no reason to keep it around.
      Signed-off-by: NToke Høiland-Jørgensen <toke@redhat.com>
      Signed-off-by: NDaniel Borkmann <daniel@iogearbox.net>
      Tested-by: Jesper Dangaard Brouer <brouer@redhat.com> # i40e
      Cc: Jesse Brandeburg <jesse.brandeburg@intel.com>
      Cc: Tony Nguyen <anthony.l.nguyen@intel.com>
      Cc: intel-wired-lan@lists.osuosl.org
      Link: https://lore.kernel.org/bpf/20210624160609.292325-12-toke@redhat.com
      49589b23
  20. 05 6月, 2021 1 次提交
  21. 03 6月, 2021 1 次提交
  22. 21 5月, 2021 7 次提交