1. 05 10月, 2021 1 次提交
  2. 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
  3. 28 8月, 2021 3 次提交
  4. 25 8月, 2021 1 次提交
  5. 20 8月, 2021 2 次提交
  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. 21 7月, 2021 4 次提交
  8. 20 7月, 2021 1 次提交
  9. 17 7月, 2021 4 次提交
  10. 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
  11. 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
  12. 05 6月, 2021 1 次提交
  13. 03 6月, 2021 1 次提交
  14. 21 5月, 2021 9 次提交
  15. 15 5月, 2021 1 次提交
  16. 17 4月, 2021 2 次提交
    • E
      igc: enable auxiliary PHC functions for the i225 · 87938851
      Ederson de Souza 提交于
      The i225 device offers a number of special PTP Hardware Clock features on
      the Software Defined Pins (SDPs) - much like i210, which is used as
      inspiration for this patch. It enables two possible functions, namely
      time stamping external events and periodic output signals.
      
      The assignment of PHC functions to the four SDP can be freely chosen by
      the user.
      
      For the external events time stamping, when the SDP (configured as input
      by user) level changes, an interrupt is generated and the kernel
      Precision Time Protocol (PTP) is informed.
      
      For the periodic output signals, the i225 is configured to generate them
      (so the SDP level will change periodically) and the driver also has to
      keep updating the time of the next level change. However, this work is
      not necessary for some frequencies as the i225 takes care of them
      (namely, anything with a half-cycle of 500ms, 250ms, 125ms or < 70ms).
      
      While i225 allows up to four timers to be used to source the time used
      on the external events or output signals, this patch uses only one of
      those timers. Main reason is to keep it simple, as it's not clear how
      these extra timers would be exposed to users. Note that currently a NIC
      can expose a single PTP device.
      Signed-off-by: NEderson de Souza <ederson.desouza@intel.com>
      Tested-by: NDvora Fuxbrumer <dvorax.fuxbrumer@linux.intel.com>
      Signed-off-by: NTony Nguyen <anthony.l.nguyen@intel.com>
      87938851
    • E
      igc: Enable internal i225 PPS · 64433e5b
      Ederson de Souza 提交于
      The i225 device can produce one interrupt on the full second, much
      like i210 - from where this patch is inspired.
      
      This patch sets up the full second interruption on the i225 and when
      receiving it, it sends a PPS event to PTP (Precision Time Protocol)
      kernel subsystem.
      
      The PTP subsystem exposes the PPS events via ioctl and sysfs, and one
      can use the `testptp` tool (tools/testing/selftests/ptp) to check that
      the events are being generated.
      Signed-off-by: NEderson de Souza <ederson.desouza@intel.com>
      Tested-by: NDvora Fuxbrumer <dvorax.fuxbrumer@linux.intel.com>
      Signed-off-by: NTony Nguyen <anthony.l.nguyen@intel.com>
      64433e5b
  17. 30 3月, 2021 3 次提交
  18. 29 3月, 2021 2 次提交