1. 20 8月, 2021 2 次提交
  2. 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
  3. 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
  4. 05 6月, 2021 1 次提交
  5. 03 6月, 2021 1 次提交
  6. 21 5月, 2021 9 次提交
  7. 15 5月, 2021 1 次提交
  8. 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
  9. 30 3月, 2021 3 次提交
  10. 29 3月, 2021 4 次提交
  11. 20 3月, 2021 1 次提交
  12. 12 3月, 2021 1 次提交
  13. 11 3月, 2021 1 次提交
  14. 05 2月, 2021 1 次提交
  15. 04 2月, 2021 1 次提交
  16. 20 1月, 2021 1 次提交
  17. 11 12月, 2020 1 次提交
  18. 11 11月, 2020 1 次提交
  19. 30 9月, 2020 1 次提交
  20. 29 9月, 2020 5 次提交