1. 16 12月, 2022 1 次提交
    • V
      igc: Enhance Qbv scheduling by using first flag bit · db0b124f
      Vinicius Costa Gomes 提交于
      The I225 hardware has a limitation that packets can only be scheduled
      in the [0, cycle-time] interval. So, scheduling a packet to the start
      of the next cycle doesn't usually work.
      
      To overcome this, we use the Transmit Descriptor first flag to indicates
      that a packet should be the first packet (from a queue) in a cycle
      according to the section 7.5.2.9.3.4 The First Packet on Each QBV Cycle
      in Intel Discrete I225/6 User Manual.
      
      But this only works if there was any packet from that queue during the
      current cycle, to avoid this issue, we issue an empty packet if that's
      not the case. Also require one more descriptor to be available, to take
      into account the empty packet that might be issued.
      
      Test Setup:
      
      Talker: Use l2_tai to generate the launchtime into packet load.
      
      Listener: Use timedump.c to compute the delta between packet arrival
      and LaunchTime packet payload.
      
      Test Result:
      
      Before:
      
      1666000610127300000,1666000610127300096,96,621273
      1666000610127400000,1666000610127400192,192,621274
      1666000610127500000,1666000610127500032,32,621275
      1666000610127600000,1666000610127600128,128,621276
      1666000610127700000,1666000610127700224,224,621277
      1666000610127800000,1666000610127800064,64,621278
      1666000610127900000,1666000610127900160,160,621279
      1666000610128000000,1666000610128000000,0,621280
      1666000610128100000,1666000610128100096,96,621281
      1666000610128200000,1666000610128200192,192,621282
      1666000610128300000,1666000610128300032,32,621283
      1666000610128400000,1666000610128301056,-98944,621284
      1666000610128500000,1666000610128302080,-197920,621285
      1666000610128600000,1666000610128302848,-297152,621286
      1666000610128700000,1666000610128303872,-396128,621287
      1666000610128800000,1666000610128304896,-495104,621288
      1666000610128900000,1666000610128305664,-594336,621289
      1666000610129000000,1666000610128306688,-693312,621290
      1666000610129100000,1666000610128307712,-792288,621291
      1666000610129200000,1666000610128308480,-891520,621292
      1666000610129300000,1666000610128309504,-990496,621293
      1666000610129400000,1666000610128310528,-1089472,621294
      1666000610129500000,1666000610128311296,-1188704,621295
      1666000610129600000,1666000610128312320,-1287680,621296
      1666000610129700000,1666000610128313344,-1386656,621297
      1666000610129800000,1666000610128314112,-1485888,621298
      1666000610129900000,1666000610128315136,-1584864,621299
      1666000610130000000,1666000610128316160,-1683840,621300
      1666000610130100000,1666000610128316928,-1783072,621301
      1666000610130200000,1666000610128317952,-1882048,621302
      1666000610130300000,1666000610128318976,-1981024,621303
      1666000610130400000,1666000610128319744,-2080256,621304
      1666000610130500000,1666000610128320768,-2179232,621305
      1666000610130600000,1666000610128321792,-2278208,621306
      1666000610130700000,1666000610128322816,-2377184,621307
      1666000610130800000,1666000610128323584,-2476416,621308
      1666000610130900000,1666000610128324608,-2575392,621309
      1666000610131000000,1666000610128325632,-2674368,621310
      1666000610131100000,1666000610128326400,-2773600,621311
      1666000610131200000,1666000610128327424,-2872576,621312
      1666000610131300000,1666000610128328448,-2971552,621313
      1666000610131400000,1666000610128329216,-3070784,621314
      1666000610131500000,1666000610131500032,32,621315
      1666000610131600000,1666000610131600128,128,621316
      1666000610131700000,1666000610131700224,224,621317
      
      After:
      
      1666073510646200000,1666073510646200064,64,2676462
      1666073510646300000,1666073510646300160,160,2676463
      1666073510646400000,1666073510646400256,256,2676464
      1666073510646500000,1666073510646500096,96,2676465
      1666073510646600000,1666073510646600192,192,2676466
      1666073510646700000,1666073510646700032,32,2676467
      1666073510646800000,1666073510646800128,128,2676468
      1666073510646900000,1666073510646900224,224,2676469
      1666073510647000000,1666073510647000064,64,2676470
      1666073510647100000,1666073510647100160,160,2676471
      1666073510647200000,1666073510647200256,256,2676472
      1666073510647300000,1666073510647300096,96,2676473
      1666073510647400000,1666073510647400192,192,2676474
      1666073510647500000,1666073510647500032,32,2676475
      1666073510647600000,1666073510647600128,128,2676476
      1666073510647700000,1666073510647700224,224,2676477
      1666073510647800000,1666073510647800064,64,2676478
      1666073510647900000,1666073510647900160,160,2676479
      1666073510648000000,1666073510648000000,0,2676480
      1666073510648100000,1666073510648100096,96,2676481
      1666073510648200000,1666073510648200192,192,2676482
      1666073510648300000,1666073510648300032,32,2676483
      1666073510648400000,1666073510648400128,128,2676484
      1666073510648500000,1666073510648500224,224,2676485
      1666073510648600000,1666073510648600064,64,2676486
      1666073510648700000,1666073510648700160,160,2676487
      1666073510648800000,1666073510648800000,0,2676488
      1666073510648900000,1666073510648900096,96,2676489
      1666073510649000000,1666073510649000192,192,2676490
      1666073510649100000,1666073510649100032,32,2676491
      1666073510649200000,1666073510649200128,128,2676492
      1666073510649300000,1666073510649300224,224,2676493
      1666073510649400000,1666073510649400064,64,2676494
      1666073510649500000,1666073510649500160,160,2676495
      1666073510649600000,1666073510649600000,0,2676496
      1666073510649700000,1666073510649700096,96,2676497
      1666073510649800000,1666073510649800192,192,2676498
      1666073510649900000,1666073510649900032,32,2676499
      1666073510650000000,1666073510650000128,128,2676500
      
      Fixes: 82faa9b7 ("igc: Add support for ETF offloading")
      Signed-off-by: NVinicius Costa Gomes <vinicius.gomes@intel.com>
      Co-developed-by: NAravindhan Gunasekaran <aravindhan.gunasekaran@intel.com>
      Signed-off-by: NAravindhan Gunasekaran <aravindhan.gunasekaran@intel.com>
      Co-developed-by: NMuhammad Husaini Zulkifli <muhammad.husaini.zulkifli@intel.com>
      Signed-off-by: NMuhammad Husaini Zulkifli <muhammad.husaini.zulkifli@intel.com>
      Signed-off-by: NMalli C <mallikarjuna.chilakala@intel.com>
      Tested-by: NNaama Meir <naamax.meir@linux.intel.com>
      Signed-off-by: NTony Nguyen <anthony.l.nguyen@intel.com>
      db0b124f
  2. 03 11月, 2022 1 次提交
  3. 29 10月, 2022 1 次提交
  4. 29 9月, 2022 1 次提交
  5. 19 8月, 2022 1 次提交
  6. 19 7月, 2022 1 次提交
  7. 15 7月, 2022 1 次提交
    • L
      igc: Reinstate IGC_REMOVED logic and implement it properly · 7c1ddcee
      Lennert Buytenhek 提交于
      The initially merged version of the igc driver code (via commit
      146740f9, "igc: Add support for PF") contained the following
      IGC_REMOVED checks in the igc_rd32/wr32() MMIO accessors:
      
      	u32 igc_rd32(struct igc_hw *hw, u32 reg)
      	{
      		u8 __iomem *hw_addr = READ_ONCE(hw->hw_addr);
      		u32 value = 0;
      
      		if (IGC_REMOVED(hw_addr))
      			return ~value;
      
      		value = readl(&hw_addr[reg]);
      
      		/* reads should not return all F's */
      		if (!(~value) && (!reg || !(~readl(hw_addr))))
      			hw->hw_addr = NULL;
      
      		return value;
      	}
      
      And:
      
      	#define wr32(reg, val) \
      	do { \
      		u8 __iomem *hw_addr = READ_ONCE((hw)->hw_addr); \
      		if (!IGC_REMOVED(hw_addr)) \
      			writel((val), &hw_addr[(reg)]); \
      	} while (0)
      
      E.g. igb has similar checks in its MMIO accessors, and has a similar
      macro E1000_REMOVED, which is implemented as follows:
      
      	#define E1000_REMOVED(h) unlikely(!(h))
      
      These checks serve to detect and take note of an 0xffffffff MMIO read
      return from the device, which can be caused by a PCIe link flap or some
      other kind of PCI bus error, and to avoid performing MMIO reads and
      writes from that point onwards.
      
      However, the IGC_REMOVED macro was not originally implemented:
      
      	#ifndef IGC_REMOVED
      	#define IGC_REMOVED(a) (0)
      	#endif /* IGC_REMOVED */
      
      This led to the IGC_REMOVED logic to be removed entirely in a
      subsequent commit (commit 3c215fb1, "igc: remove IGC_REMOVED
      function"), with the rationale that such checks matter only for
      virtualization and that igc does not support virtualization -- but a
      PCIe device can become detached even without virtualization being in
      use, and without proper checks, a PCIe bus error affecting an igc
      adapter will lead to various NULL pointer dereferences, as the first
      access after the error will set hw->hw_addr to NULL, and subsequent
      accesses will blindly dereference this now-NULL pointer.
      
      This patch reinstates the IGC_REMOVED checks in igc_rd32/wr32(), and
      implements IGC_REMOVED the way it is done for igb, by checking for the
      unlikely() case of hw_addr being NULL.  This change prevents the oopses
      seen when a PCIe link flap occurs on an igc adapter.
      
      Fixes: 146740f9 ("igc: Add support for PF")
      Signed-off-by: NLennert Buytenhek <buytenh@arista.com>
      Tested-by: NNaama Meir <naamax.meir@linux.intel.com>
      Acked-by: NSasha Neftin <sasha.neftin@intel.com>
      Signed-off-by: NTony Nguyen <anthony.l.nguyen@intel.com>
      7c1ddcee
  8. 11 5月, 2022 1 次提交
  9. 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
  10. 01 2月, 2022 1 次提交
  11. 28 1月, 2022 1 次提交
  12. 29 12月, 2021 2 次提交
  13. 14 12月, 2021 1 次提交
  14. 01 12月, 2021 2 次提交
  15. 30 10月, 2021 1 次提交
  16. 05 10月, 2021 1 次提交
  17. 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
  18. 28 8月, 2021 3 次提交
  19. 25 8月, 2021 1 次提交
  20. 20 8月, 2021 2 次提交
  21. 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
  22. 21 7月, 2021 4 次提交
  23. 20 7月, 2021 1 次提交
  24. 17 7月, 2021 4 次提交
  25. 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
  26. 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
  27. 05 6月, 2021 1 次提交
  28. 03 6月, 2021 1 次提交