<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux/drivers/net, branch v5.19</title>
<subtitle>Mirror of https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/
</subtitle>
<id>https://git.shady.money/linux/atom?h=v5.19</id>
<link rel='self' href='https://git.shady.money/linux/atom?h=v5.19'/>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/'/>
<updated>2022-07-28T17:43:04Z</updated>
<entry>
<title>stmmac: dwmac-mediatek: fix resource leak in probe</title>
<updated>2022-07-28T17:43:04Z</updated>
<author>
<name>Dan Carpenter</name>
<email>dan.carpenter@oracle.com</email>
</author>
<published>2022-07-28T11:52:09Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=4d3d3a1b244fd54629a6b7047f39a7bbc8d11910'/>
<id>urn:sha1:4d3d3a1b244fd54629a6b7047f39a7bbc8d11910</id>
<content type='text'>
If mediatek_dwmac_clks_config() fails, then call stmmac_remove_config_dt()
before returning.  Otherwise it is a resource leak.

Fixes: fa4b3ca60e80 ("stmmac: dwmac-mediatek: fix clock issue")
Signed-off-by: Dan Carpenter &lt;dan.carpenter@oracle.com&gt;
Link: https://lore.kernel.org/r/YuJ4aZyMUlG6yGGa@kili
Signed-off-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
</content>
</entry>
<entry>
<title>net/funeth: Fix fun_xdp_tx() and XDP packet reclaim</title>
<updated>2022-07-28T10:54:10Z</updated>
<author>
<name>Dimitris Michailidis</name>
<email>d.michailidis@fungible.com</email>
</author>
<published>2022-07-26T21:59:23Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=51a83391d77bb0f7ff0aef06ca4c7f5aa9e80b4c'/>
<id>urn:sha1:51a83391d77bb0f7ff0aef06ca4c7f5aa9e80b4c</id>
<content type='text'>
The current implementation of fun_xdp_tx(), used for XPD_TX, is
incorrect in that it takes an address/length pair and later releases it
with page_frag_free(). It is OK for XDP_TX but the same code is used by
ndo_xdp_xmit. In that case it loses the XDP memory type and releases the
packet incorrectly for some of the types. Assorted breakage follows.

Change fun_xdp_tx() to take xdp_frame and rely on xdp_return_frame() in
reclaim.

Fixes: db37bc177dae ("net/funeth: add the data path")
Signed-off-by: Dimitris Michailidis &lt;dmichail@fungible.com&gt;
Link: https://lore.kernel.org/r/20220726215923.7887-1-dmichail@fungible.com
Signed-off-by: Paolo Abeni &lt;pabeni@redhat.com&gt;
</content>
</entry>
<entry>
<title>Merge branch '100GbE' of git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/net-queue</title>
<updated>2022-07-28T02:56:28Z</updated>
<author>
<name>Jakub Kicinski</name>
<email>kuba@kernel.org</email>
</author>
<published>2022-07-28T02:56:28Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=bf84719df765f1a832a770f3cd0cdc8bee20c91f'/>
<id>urn:sha1:bf84719df765f1a832a770f3cd0cdc8bee20c91f</id>
<content type='text'>
Tony Nguyen says:

====================
Intel Wired LAN Driver Updates 2022-07-26

This series contains updates to ice driver only.

Przemyslaw corrects accounting for VF VLANs to allow for correct number
of VLANs for untrusted VF. He also correct issue with checksum offload
on VXLAN tunnels.

Ani allows for two VSIs to share the same MAC address.

Maciej corrects checked bits for descriptor completion of loopback

* '100GbE' of git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/net-queue:
  ice: do not setup vlan for loopback VSI
  ice: check (DD | EOF) bits on Rx descriptor rather than (EOP | RS)
  ice: Fix VSIs unable to share unicast MAC
  ice: Fix tunnel checksum offload with fragmented traffic
  ice: Fix max VLANs available for VF
====================

Link: https://lore.kernel.org/r/20220726204646.2171589-1-anthony.l.nguyen@intel.com
Signed-off-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
</content>
</entry>
<entry>
<title>sfc: disable softirqs for ptp TX</title>
<updated>2022-07-28T01:20:43Z</updated>
<author>
<name>Alejandro Lucero</name>
<email>alejandro.lucero-palau@amd.com</email>
</author>
<published>2022-07-26T06:45:04Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=67c3b611d92fc238c43734878bc3e232ab570c79'/>
<id>urn:sha1:67c3b611d92fc238c43734878bc3e232ab570c79</id>
<content type='text'>
Sending a PTP packet can imply to use the normal TX driver datapath but
invoked from the driver's ptp worker. The kernel generic TX code
disables softirqs and preemption before calling specific driver TX code,
but the ptp worker does not. Although current ptp driver functionality
does not require it, there are several reasons for doing so:

   1) The invoked code is always executed with softirqs disabled for non
      PTP packets.
   2) Better if a ptp packet transmission is not interrupted by softirq
      handling which could lead to high latencies.
   3) netdev_xmit_more used by the TX code requires preemption to be
      disabled.

Indeed a solution for dealing with kernel preemption state based on static
kernel configuration is not possible since the introduction of dynamic
preemption level configuration at boot time using the static calls
functionality.

Fixes: f79c957a0b537 ("drivers: net: sfc: use netdev_xmit_more helper")
Signed-off-by: Alejandro Lucero &lt;alejandro.lucero-palau@amd.com&gt;
Link: https://lore.kernel.org/r/20220726064504.49613-1-alejandro.lucero-palau@amd.com
Signed-off-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
</content>
</entry>
<entry>
<title>virtio-net: fix the race between refill work and close</title>
<updated>2022-07-27T12:20:44Z</updated>
<author>
<name>Jason Wang</name>
<email>jasowang@redhat.com</email>
</author>
<published>2022-07-25T07:21:59Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=5a159128faff151b7fe5f4eb0f310b1e0a2d56bf'/>
<id>urn:sha1:5a159128faff151b7fe5f4eb0f310b1e0a2d56bf</id>
<content type='text'>
We try using cancel_delayed_work_sync() to prevent the work from
enabling NAPI. This is insufficient since we don't disable the source
of the refill work scheduling. This means an NAPI poll callback after
cancel_delayed_work_sync() can schedule the refill work then can
re-enable the NAPI that leads to use-after-free [1].

Since the work can enable NAPI, we can't simply disable NAPI before
calling cancel_delayed_work_sync(). So fix this by introducing a
dedicated boolean to control whether or not the work could be
scheduled from NAPI.

[1]
==================================================================
BUG: KASAN: use-after-free in refill_work+0x43/0xd4
Read of size 2 at addr ffff88810562c92e by task kworker/2:1/42

CPU: 2 PID: 42 Comm: kworker/2:1 Not tainted 5.19.0-rc1+ #480
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014
Workqueue: events refill_work
Call Trace:
 &lt;TASK&gt;
 dump_stack_lvl+0x34/0x44
 print_report.cold+0xbb/0x6ac
 ? _printk+0xad/0xde
 ? refill_work+0x43/0xd4
 kasan_report+0xa8/0x130
 ? refill_work+0x43/0xd4
 refill_work+0x43/0xd4
 process_one_work+0x43d/0x780
 worker_thread+0x2a0/0x6f0
 ? process_one_work+0x780/0x780
 kthread+0x167/0x1a0
 ? kthread_exit+0x50/0x50
 ret_from_fork+0x22/0x30
 &lt;/TASK&gt;
...

Fixes: b2baed69e605c ("virtio_net: set/cancel work on ndo_open/ndo_stop")
Signed-off-by: Jason Wang &lt;jasowang@redhat.com&gt;
Acked-by: Michael S. Tsirkin &lt;mst@redhat.com&gt;
Reviewed-by: Xuan Zhuo &lt;xuanzhuo@linux.alibaba.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>ice: do not setup vlan for loopback VSI</title>
<updated>2022-07-26T20:15:36Z</updated>
<author>
<name>Maciej Fijalkowski</name>
<email>maciej.fijalkowski@intel.com</email>
</author>
<published>2022-07-07T10:20:43Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=cc019545a238518fa9da1e2a889f6e1bb1005a63'/>
<id>urn:sha1:cc019545a238518fa9da1e2a889f6e1bb1005a63</id>
<content type='text'>
Currently loopback test is failiing due to the error returned from
ice_vsi_vlan_setup(). Skip calling it when preparing loopback VSI.

Fixes: 0e674aeb0b77 ("ice: Add handler for ethtool selftest")
Signed-off-by: Maciej Fijalkowski &lt;maciej.fijalkowski@intel.com&gt;
Tested-by: George Kuruvinakunnel &lt;george.kuruvinakunnel@intel.com&gt;
Signed-off-by: Tony Nguyen &lt;anthony.l.nguyen@intel.com&gt;
</content>
</entry>
<entry>
<title>ice: check (DD | EOF) bits on Rx descriptor rather than (EOP | RS)</title>
<updated>2022-07-26T20:15:36Z</updated>
<author>
<name>Maciej Fijalkowski</name>
<email>maciej.fijalkowski@intel.com</email>
</author>
<published>2022-07-07T10:20:42Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=283d736ff7c7e96ac5b32c6c0de40372f8eb171e'/>
<id>urn:sha1:283d736ff7c7e96ac5b32c6c0de40372f8eb171e</id>
<content type='text'>
Tx side sets EOP and RS bits on descriptors to indicate that a
particular descriptor is the last one and needs to generate an irq when
it was sent. These bits should not be checked on completion path
regardless whether it's the Tx or the Rx. DD bit serves this purpose and
it indicates that a particular descriptor is either for Rx or was
successfully Txed. EOF is also set as loopback test does not xmit
fragmented frames.

Look at (DD | EOF) bits setting in ice_lbtest_receive_frames() instead
of EOP and RS pair.

Fixes: 0e674aeb0b77 ("ice: Add handler for ethtool selftest")
Signed-off-by: Maciej Fijalkowski &lt;maciej.fijalkowski@intel.com&gt;
Tested-by: George Kuruvinakunnel &lt;george.kuruvinakunnel@intel.com&gt;
Signed-off-by: Tony Nguyen &lt;anthony.l.nguyen@intel.com&gt;
</content>
</entry>
<entry>
<title>ice: Fix VSIs unable to share unicast MAC</title>
<updated>2022-07-26T20:15:36Z</updated>
<author>
<name>Anirudh Venkataramanan</name>
<email>anirudh.venkataramanan@intel.com</email>
</author>
<published>2022-07-21T08:03:09Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=5c8e3c7ff3e7bd7b938659be704f75cc746b697f'/>
<id>urn:sha1:5c8e3c7ff3e7bd7b938659be704f75cc746b697f</id>
<content type='text'>
The driver currently does not allow two VSIs in the same PF domain
to have the same unicast MAC address. This is incorrect in the sense
that a policy decision is being made in the driver when it must be
left to the user. This approach was causing issues when rebooting
the system with VFs spawned not being able to change their MAC addresses.
Such errors were present in dmesg:

[ 7921.068237] ice 0000:b6:00.2 ens2f2: Unicast MAC 6a:0d:e4:70:ca:d1 already
exists on this PF. Preventing setting VF 7 unicast MAC address to 6a:0d:e4:70:ca:d1

Fix that by removing this restriction. Doing this also allows
us to remove some additional code that's checking if a unicast MAC
filter already exists.

Fixes: 47ebc7b02485 ("ice: Check if unicast MAC exists before setting VF MAC")
Signed-off-by: Anirudh Venkataramanan &lt;anirudh.venkataramanan@intel.com&gt;
Signed-off-by: Sylwester Dziedziuch &lt;sylwesterx.dziedziuch@intel.com&gt;
Signed-off-by: Mateusz Palczewski &lt;mateusz.palczewski@intel.com&gt;
Signed-off-by: Jedrzej Jagielski &lt;jedrzej.jagielski@intel.com&gt;
Tested-by: Marek Szlosek &lt;marek.szlosek@intel.com&gt;
Signed-off-by: Tony Nguyen &lt;anthony.l.nguyen@intel.com&gt;
</content>
</entry>
<entry>
<title>ice: Fix tunnel checksum offload with fragmented traffic</title>
<updated>2022-07-26T20:15:36Z</updated>
<author>
<name>Przemyslaw Patynowski</name>
<email>przemyslawx.patynowski@intel.com</email>
</author>
<published>2022-07-18T11:34:27Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=01658aeeada6f93c2924af94d895ff28d559690c'/>
<id>urn:sha1:01658aeeada6f93c2924af94d895ff28d559690c</id>
<content type='text'>
Fix checksum offload on VXLAN tunnels.
In case, when mpls protocol is not used, set l4 header to transport
header of skb. This fixes case, when user tries to offload checksums
of VXLAN tunneled traffic.

Steps for reproduction (requires link partner with tunnels):
ip l s enp130s0f0 up
ip a f enp130s0f0
ip a a 10.10.110.2/24 dev enp130s0f0
ip l s enp130s0f0 mtu 1600
ip link add vxlan12_sut type vxlan id 12 group 238.168.100.100 dev enp130s0f0 dstport 4789
ip l s vxlan12_sut up
ip a a 20.10.110.2/24 dev vxlan12_sut
iperf3 -c 20.10.110.1 #should connect

Offload params: td_offset, cd_tunnel_params were
corrupted, due to l4 header pointing wrong address. NIC would then drop
those packets internally, due to incorrect TX descriptor data,
which increased GLV_TEPC register.

Fixes: 69e66c04c672 ("ice: Add mpls+tso support")
Signed-off-by: Przemyslaw Patynowski &lt;przemyslawx.patynowski@intel.com&gt;
Signed-off-by: Mateusz Palczewski &lt;mateusz.palczewski@intel.com&gt;
Signed-off-by: Jedrzej Jagielski &lt;jedrzej.jagielski@intel.com&gt;
Tested-by: Gurucharan &lt;gurucharanx.g@intel.com&gt; (A Contingent worker at Intel)
Signed-off-by: Tony Nguyen &lt;anthony.l.nguyen@intel.com&gt;
</content>
</entry>
<entry>
<title>ice: Fix max VLANs available for VF</title>
<updated>2022-07-26T20:15:18Z</updated>
<author>
<name>Przemyslaw Patynowski</name>
<email>przemyslawx.patynowski@intel.com</email>
</author>
<published>2022-07-04T13:46:12Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=1e308c6fb7127371f48a0fb9770ea0b30a6b5698'/>
<id>urn:sha1:1e308c6fb7127371f48a0fb9770ea0b30a6b5698</id>
<content type='text'>
Legacy VLAN implementation allows for untrusted VF to have 8 VLAN
filters, not counting VLAN 0 filters. Current VLAN_V2 implementation
lowers available filters for VF, by counting in VLAN 0 filter for both
TPIDs.
Fix this by counting only non zero VLAN filters.
Without this patch, untrusted VF would not be able to access 8 VLAN
filters.

Fixes: cc71de8fa133 ("ice: Add support for VIRTCHNL_VF_OFFLOAD_VLAN_V2")
Signed-off-by: Przemyslaw Patynowski &lt;przemyslawx.patynowski@intel.com&gt;
Signed-off-by: Mateusz Palczewski &lt;mateusz.palczewski@intel.com&gt;
Tested-by: Marek Szlosek &lt;marek.szlosek@intel.com&gt;
Signed-off-by: Tony Nguyen &lt;anthony.l.nguyen@intel.com&gt;
</content>
</entry>
</feed>
