<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel.git/drivers/net/ethernet/sfc, branch linux-4.9.y</title>
<subtitle>Hosts the 0x221E linux distro kernel.
</subtitle>
<id>https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-4.9.y</id>
<link rel='self' href='https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-4.9.y'/>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/'/>
<updated>2022-07-21T18:40:31Z</updated>
<entry>
<title>sfc: fix kernel panic when creating VF</title>
<updated>2022-07-21T18:40:31Z</updated>
<author>
<name>Íñigo Huguet</name>
</author>
<published>2022-07-13T09:21:16Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=d9840212a9c00507347c703f4fdeda16400407e0'/>
<id>urn:sha1:d9840212a9c00507347c703f4fdeda16400407e0</id>
<content type='text'>
[ Upstream commit ada74c5539eba06cf8b47d068f92e0b3963a9a6e ]

When creating VFs a kernel panic can happen when calling to
efx_ef10_try_update_nic_stats_vf.

When releasing a DMA coherent buffer, sometimes, I don't know in what
specific circumstances, it has to unmap memory with vunmap. It is
disallowed to do that in IRQ context or with BH disabled. Otherwise, we
hit this line in vunmap, causing the crash:
  BUG_ON(in_interrupt());

This patch reenables BH to release the buffer.

Log messages when the bug is hit:
 kernel BUG at mm/vmalloc.c:2727!
 invalid opcode: 0000 [#1] PREEMPT SMP NOPTI
 CPU: 6 PID: 1462 Comm: NetworkManager Kdump: loaded Tainted: G          I      --------- ---  5.14.0-119.el9.x86_64 #1
 Hardware name: Dell Inc. PowerEdge R740/06WXJT, BIOS 2.8.2 08/27/2020
 RIP: 0010:vunmap+0x2e/0x30
 ...skip...
 Call Trace:
  __iommu_dma_free+0x96/0x100
  efx_nic_free_buffer+0x2b/0x40 [sfc]
  efx_ef10_try_update_nic_stats_vf+0x14a/0x1c0 [sfc]
  efx_ef10_update_stats_vf+0x18/0x40 [sfc]
  efx_start_all+0x15e/0x1d0 [sfc]
  efx_net_open+0x5a/0xe0 [sfc]
  __dev_open+0xe7/0x1a0
  __dev_change_flags+0x1d7/0x240
  dev_change_flags+0x21/0x60
  ...skip...

Fixes: d778819609a2 ("sfc: DMA the VF stats only when requested")
Reported-by: Ma Yuying &lt;yuma@redhat.com&gt;
Signed-off-by: Íñigo Huguet &lt;ihuguet@redhat.com&gt;
Acked-by: Edward Cree &lt;ecree.xilinx@gmail.com&gt;
Link: https://lore.kernel.org/r/20220713092116.21238-1-ihuguet@redhat.com
Signed-off-by: Paolo Abeni &lt;pabeni@redhat.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>sfc: fix use after free when disabling sriov</title>
<updated>2022-07-21T18:40:31Z</updated>
<author>
<name>Íñigo Huguet</name>
</author>
<published>2022-07-12T06:26:42Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=3199e34912d84cdfb8a93a984c5ae5c73fb13e84'/>
<id>urn:sha1:3199e34912d84cdfb8a93a984c5ae5c73fb13e84</id>
<content type='text'>
[ Upstream commit ebe41da5d47ac0fff877e57bd14c54dccf168827 ]

Use after free is detected by kfence when disabling sriov. What was read
after being freed was vf-&gt;pci_dev: it was freed from pci_disable_sriov
and later read in efx_ef10_sriov_free_vf_vports, called from
efx_ef10_sriov_free_vf_vswitching.

Set the pointer to NULL at release time to not trying to read it later.

Reproducer and dmesg log (note that kfence doesn't detect it every time):
$ echo 1 &gt; /sys/class/net/enp65s0f0np0/device/sriov_numvfs
$ echo 0 &gt; /sys/class/net/enp65s0f0np0/device/sriov_numvfs

 BUG: KFENCE: use-after-free read in efx_ef10_sriov_free_vf_vswitching+0x82/0x170 [sfc]

 Use-after-free read at 0x00000000ff3c1ba5 (in kfence-#224):
  efx_ef10_sriov_free_vf_vswitching+0x82/0x170 [sfc]
  efx_ef10_pci_sriov_disable+0x38/0x70 [sfc]
  efx_pci_sriov_configure+0x24/0x40 [sfc]
  sriov_numvfs_store+0xfe/0x140
  kernfs_fop_write_iter+0x11c/0x1b0
  new_sync_write+0x11f/0x1b0
  vfs_write+0x1eb/0x280
  ksys_write+0x5f/0xe0
  do_syscall_64+0x5c/0x80
  entry_SYSCALL_64_after_hwframe+0x44/0xae

 kfence-#224: 0x00000000edb8ef95-0x00000000671f5ce1, size=2792, cache=kmalloc-4k

 allocated by task 6771 on cpu 10 at 3137.860196s:
  pci_alloc_dev+0x21/0x60
  pci_iov_add_virtfn+0x2a2/0x320
  sriov_enable+0x212/0x3e0
  efx_ef10_sriov_configure+0x67/0x80 [sfc]
  efx_pci_sriov_configure+0x24/0x40 [sfc]
  sriov_numvfs_store+0xba/0x140
  kernfs_fop_write_iter+0x11c/0x1b0
  new_sync_write+0x11f/0x1b0
  vfs_write+0x1eb/0x280
  ksys_write+0x5f/0xe0
  do_syscall_64+0x5c/0x80
  entry_SYSCALL_64_after_hwframe+0x44/0xae

 freed by task 6771 on cpu 12 at 3170.991309s:
  device_release+0x34/0x90
  kobject_cleanup+0x3a/0x130
  pci_iov_remove_virtfn+0xd9/0x120
  sriov_disable+0x30/0xe0
  efx_ef10_pci_sriov_disable+0x57/0x70 [sfc]
  efx_pci_sriov_configure+0x24/0x40 [sfc]
  sriov_numvfs_store+0xfe/0x140
  kernfs_fop_write_iter+0x11c/0x1b0
  new_sync_write+0x11f/0x1b0
  vfs_write+0x1eb/0x280
  ksys_write+0x5f/0xe0
  do_syscall_64+0x5c/0x80
  entry_SYSCALL_64_after_hwframe+0x44/0xae

Fixes: 3c5eb87605e85 ("sfc: create vports for VFs and assign random MAC addresses")
Reported-by: Yanghang Liu &lt;yanghliu@redhat.com&gt;
Signed-off-by: Íñigo Huguet &lt;ihuguet@redhat.com&gt;
Acked-by: Martin Habets &lt;habetsm.xilinx@gmail.com&gt;
Link: https://lore.kernel.org/r/20220712062642.6915-1-ihuguet@redhat.com
Signed-off-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>net: sfc: ef10: fix memory leak in efx_ef10_mtd_probe()</title>
<updated>2022-05-18T07:15:43Z</updated>
<author>
<name>Taehee Yoo</name>
</author>
<published>2022-05-12T05:47:09Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=095dbe58e825eaa54881939619a38f6bfb3dcb84'/>
<id>urn:sha1:095dbe58e825eaa54881939619a38f6bfb3dcb84</id>
<content type='text'>
[ Upstream commit 1fa89ffbc04545b7582518e57f4b63e2a062870f ]

In the NIC -&gt;probe() callback, -&gt;mtd_probe() callback is called.
If NIC has 2 ports, -&gt;probe() is called twice and -&gt;mtd_probe() too.
In the -&gt;mtd_probe(), which is efx_ef10_mtd_probe() it allocates and
initializes mtd partiion.
But mtd partition for sfc is shared data.
So that allocated mtd partition data from last called
efx_ef10_mtd_probe() will not be used.
Therefore it must be freed.
But it doesn't free a not used mtd partition data in efx_ef10_mtd_probe().

kmemleak reports:
unreferenced object 0xffff88811ddb0000 (size 63168):
  comm "systemd-udevd", pid 265, jiffies 4294681048 (age 348.586s)
  hex dump (first 32 bytes):
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
  backtrace:
    [&lt;ffffffffa3767749&gt;] kmalloc_order_trace+0x19/0x120
    [&lt;ffffffffa3873f0e&gt;] __kmalloc+0x20e/0x250
    [&lt;ffffffffc041389f&gt;] efx_ef10_mtd_probe+0x11f/0x270 [sfc]
    [&lt;ffffffffc0484c8a&gt;] efx_pci_probe.cold.17+0x3df/0x53d [sfc]
    [&lt;ffffffffa414192c&gt;] local_pci_probe+0xdc/0x170
    [&lt;ffffffffa4145df5&gt;] pci_device_probe+0x235/0x680
    [&lt;ffffffffa443dd52&gt;] really_probe+0x1c2/0x8f0
    [&lt;ffffffffa443e72b&gt;] __driver_probe_device+0x2ab/0x460
    [&lt;ffffffffa443e92a&gt;] driver_probe_device+0x4a/0x120
    [&lt;ffffffffa443f2ae&gt;] __driver_attach+0x16e/0x320
    [&lt;ffffffffa4437a90&gt;] bus_for_each_dev+0x110/0x190
    [&lt;ffffffffa443b75e&gt;] bus_add_driver+0x39e/0x560
    [&lt;ffffffffa4440b1e&gt;] driver_register+0x18e/0x310
    [&lt;ffffffffc02e2055&gt;] 0xffffffffc02e2055
    [&lt;ffffffffa3001af3&gt;] do_one_initcall+0xc3/0x450
    [&lt;ffffffffa33ca574&gt;] do_init_module+0x1b4/0x700

Acked-by: Martin Habets &lt;habetsm.xilinx@gmail.com&gt;
Fixes: 8127d661e77f ("sfc: Add support for Solarflare SFC9100 family")
Signed-off-by: Taehee Yoo &lt;ap420073@gmail.com&gt;
Link: https://lore.kernel.org/r/20220512054709.12513-1-ap420073@gmail.com
Signed-off-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>sfc: extend the locking on mcdi-&gt;seqno</title>
<updated>2022-03-23T08:00:33Z</updated>
<author>
<name>Niels Dossche</name>
</author>
<published>2022-03-01T22:28:22Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=caac3ea9f7852ded95e6155de3176df9d88084c8'/>
<id>urn:sha1:caac3ea9f7852ded95e6155de3176df9d88084c8</id>
<content type='text'>
[ Upstream commit f1fb205efb0ccca55626fd4ef38570dd16b44719 ]

seqno could be read as a stale value outside of the lock. The lock is
already acquired to protect the modification of seqno against a possible
race condition. Place the reading of this value also inside this locking
to protect it against a possible race condition.

Signed-off-by: Niels Dossche &lt;dossche.niels@gmail.com&gt;
Acked-by: Martin Habets &lt;habetsm.xilinx@gmail.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>sfc: Don't use netif_info before net_device setup</title>
<updated>2021-11-26T10:48:20Z</updated>
<author>
<name>Erik Ekman</name>
</author>
<published>2021-10-19T22:40:16Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=2a566fd381e4bffe7afe5b8885ce4bc8dfc62910'/>
<id>urn:sha1:2a566fd381e4bffe7afe5b8885ce4bc8dfc62910</id>
<content type='text'>
[ Upstream commit bf6abf345dfa77786aca554bc58c64bd428ecb1d ]

Use pci_info instead to avoid unnamed/uninitialized noise:

[197088.688729] sfc 0000:01:00.0: Solarflare NIC detected
[197088.690333] sfc 0000:01:00.0: Part Number : SFN5122F
[197088.729061] sfc 0000:01:00.0 (unnamed net_device) (uninitialized): no SR-IOV VFs probed
[197088.729071] sfc 0000:01:00.0 (unnamed net_device) (uninitialized): no PTP support

Inspired by fa44821a4ddd ("sfc: don't use netif_info et al before
net_device is registered") from Heiner Kallweit.

Signed-off-by: Erik Ekman &lt;erik@kryo.se&gt;
Acked-by: Martin Habets &lt;habetsm.xilinx@gmail.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>sfc: error code if SRIOV cannot be disabled</title>
<updated>2021-07-20T14:21:08Z</updated>
<author>
<name>Íñigo Huguet</name>
</author>
<published>2021-06-21T15:32:36Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=06538fdc1b44c0181b77038a2802887867d62e6b'/>
<id>urn:sha1:06538fdc1b44c0181b77038a2802887867d62e6b</id>
<content type='text'>
[ Upstream commit 1ebe4feb8b442884f5a28d2437040096723dd1ea ]

If SRIOV cannot be disabled during device removal or module unloading,
return error code so it can be logged properly in the calling function.

Note that this can only happen if any VF is currently attached to a
guest using Xen, but not with vfio/KVM. Despite that in that case the
VFs won't work properly with PF removed and/or the module unloaded, I
have let it as is because I don't know what side effects may have
changing it, and also it seems to be the same that other drivers are
doing in this situation.

In the case of being called during SRIOV reconfiguration, the behavior
hasn't changed because the function is called with force=false.

Signed-off-by: Íñigo Huguet &lt;ihuguet@redhat.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>sfc: avoid double pci_remove of VFs</title>
<updated>2021-07-20T14:21:08Z</updated>
<author>
<name>Íñigo Huguet</name>
</author>
<published>2021-06-21T15:32:35Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=ce90c3d1d3fb49974b71b79d66ed15f02aafd46a'/>
<id>urn:sha1:ce90c3d1d3fb49974b71b79d66ed15f02aafd46a</id>
<content type='text'>
[ Upstream commit 45423cff1db66cf0993e8a9bd0ac93e740149e49 ]

If pci_remove was called for a PF with VFs, the removal of the VFs was
called twice from efx_ef10_sriov_fini: one directly with pci_driver-&gt;remove
and another implicit by calling pci_disable_sriov, which also perform
the VFs remove. This was leading to crashing the kernel on the second
attempt.

Given that pci_disable_sriov already calls to pci remove function, get
rid of the direct call to pci_driver-&gt;remove from the driver.

2 different ways to trigger the bug:
- Create one or more VFs, then attach the PF to a virtual machine (at
  least with qemu/KVM)
- Create one or more VFs, then remove the PF with:
  echo 1 &gt; /sys/bus/pci/devices/PF_PCI_ID/remove

Removing sfc module does not trigger the error, at least for me, because
it removes the VF first, and then the PF.

Example of a log with the error:
    list_del corruption, ffff967fd20a8ad0-&gt;next is LIST_POISON1 (dead000000000100)
    ------------[ cut here ]------------
    kernel BUG at lib/list_debug.c:47!
    [...trimmed...]
    RIP: 0010:__list_del_entry_valid.cold.1+0x12/0x4c
    [...trimmed...]
    Call Trace:
    efx_dissociate+0x1f/0x140 [sfc]
    efx_pci_remove+0x27/0x150 [sfc]
    pci_device_remove+0x3b/0xc0
    device_release_driver_internal+0x103/0x1f0
    pci_stop_bus_device+0x69/0x90
    pci_stop_and_remove_bus_device+0xe/0x20
    pci_iov_remove_virtfn+0xba/0x120
    sriov_disable+0x2f/0xe0
    efx_ef10_pci_sriov_disable+0x52/0x80 [sfc]
    ? pcie_aer_is_native+0x12/0x40
    efx_ef10_sriov_fini+0x72/0x110 [sfc]
    efx_pci_remove+0x62/0x150 [sfc]
    pci_device_remove+0x3b/0xc0
    device_release_driver_internal+0x103/0x1f0
    unbind_store+0xf6/0x130
    kernfs_fop_write+0x116/0x190
    vfs_write+0xa5/0x1a0
    ksys_write+0x4f/0xb0
    do_syscall_64+0x5b/0x1a0
    entry_SYSCALL_64_after_hwframe+0x65/0xca

Signed-off-by: Íñigo Huguet &lt;ihuguet@redhat.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>sfc: initialise found bitmap in efx_ef10_mtd_probe</title>
<updated>2019-12-05T14:35:12Z</updated>
<author>
<name>Bert Kenward</name>
</author>
<published>2019-02-12T13:10:00Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=a253f13ad902926b07b7156878ac18bde3769e5c'/>
<id>urn:sha1:a253f13ad902926b07b7156878ac18bde3769e5c</id>
<content type='text'>
[ Upstream commit c65285428b6e7797f1bb063f33b0ae7e93397b7b ]

The bitmap of found partitions in efx_ef10_mtd_probe was not
initialised, causing partitions to be suppressed based off whatever
value was in the bitmap at the start.

Fixes: 3366463513f5 ("sfc: suppress duplicate nvmem partition types in efx_ef10_mtd_probe")
Signed-off-by: Bert Kenward &lt;bkenward@solarflare.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>sfc: suppress duplicate nvmem partition types in efx_ef10_mtd_probe</title>
<updated>2019-12-05T14:35:10Z</updated>
<author>
<name>Edward Cree</name>
</author>
<published>2019-01-22T19:02:17Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=bf148e672460cd48390db780512445718ddc7262'/>
<id>urn:sha1:bf148e672460cd48390db780512445718ddc7262</id>
<content type='text'>
[ Upstream commit 3366463513f544c12c6b88c13da4462ee9e7a1a1 ]

Use a bitmap to keep track of which partition types we've already seen;
 for duplicates, return -EEXIST from efx_ef10_mtd_probe_partition() and
 thus skip adding that partition.
Duplicate partitions occur because of the A/B backup scheme used by newer
 sfc NICs.  Prior to this patch they cause sysfs_warn_dup errors because
 they have the same name, causing us not to expose any MTDs at all.

Signed-off-by: Edward Cree &lt;ecree@solarflare.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>sfc: Only cancel the PPS workqueue if it exists</title>
<updated>2019-11-28T17:28:02Z</updated>
<author>
<name>Martin Habets</name>
</author>
<published>2019-11-21T17:52:15Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=baa541afe74550642f1dfe6df18628c4a87fa3d1'/>
<id>urn:sha1:baa541afe74550642f1dfe6df18628c4a87fa3d1</id>
<content type='text'>
[ Upstream commit 723eb53690041740a13ac78efeaf6804f5d684c9 ]

The workqueue only exists for the primary PF. For other functions
we hit a WARN_ON in kernel/workqueue.c.

Fixes: 7c236c43b838 ("sfc: Add support for IEEE-1588 PTP")
Signed-off-by: Martin Habets &lt;mhabets@solarflare.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
</feed>
