<feed xmlns='http://www.w3.org/2005/Atom'>
<title>user/sven/linux.git/drivers/net, branch v5.10.98</title>
<subtitle>Linux Kernel
</subtitle>
<id>https://git.stealer.net/cgit.cgi/user/sven/linux.git/atom?h=v5.10.98</id>
<link rel='self' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/atom?h=v5.10.98'/>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/'/>
<updated>2022-02-05T11:37:56Z</updated>
<entry>
<title>net: amd-xgbe: Fix skb data length underflow</title>
<updated>2022-02-05T11:37:56Z</updated>
<author>
<name>Shyam Sundar S K</name>
<email>Shyam-sundar.S-k@amd.com</email>
</author>
<published>2022-01-27T09:20:03Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=4d3fcfe8464838b3920bc2b939d888e0b792934e'/>
<id>urn:sha1:4d3fcfe8464838b3920bc2b939d888e0b792934e</id>
<content type='text'>
commit 5aac9108a180fc06e28d4e7fb00247ce603b72ee upstream.

There will be BUG_ON() triggered in include/linux/skbuff.h leading to
intermittent kernel panic, when the skb length underflow is detected.

Fix this by dropping the packet if such length underflows are seen
because of inconsistencies in the hardware descriptors.

Fixes: 622c36f143fc ("amd-xgbe: Fix jumbo MTU processing on newer hardware")
Suggested-by: Tom Lendacky &lt;thomas.lendacky@amd.com&gt;
Signed-off-by: Shyam Sundar S K &lt;Shyam-sundar.S-k@amd.com&gt;
Acked-by: Tom Lendacky &lt;thomas.lendacky@amd.com&gt;
Link: https://lore.kernel.org/r/20220127092003.2812745-1-Shyam-sundar.S-k@amd.com
Signed-off-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>net: amd-xgbe: ensure to reset the tx_timer_active flag</title>
<updated>2022-02-05T11:37:56Z</updated>
<author>
<name>Raju Rangoju</name>
<email>Raju.Rangoju@amd.com</email>
</author>
<published>2022-01-27T06:02:22Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=cadfa7dce526334d7ae1425cdc66c626f8adfbf5'/>
<id>urn:sha1:cadfa7dce526334d7ae1425cdc66c626f8adfbf5</id>
<content type='text'>
commit 7674b7b559b683478c3832527c59bceb169e701d upstream.

Ensure to reset the tx_timer_active flag in xgbe_stop(),
otherwise a port restart may result in tx timeout due to
uncleared flag.

Fixes: c635eaacbf77 ("amd-xgbe: Remove Tx coalescing")
Co-developed-by: Sudheesh Mavila &lt;sudheesh.mavila@amd.com&gt;
Signed-off-by: Sudheesh Mavila &lt;sudheesh.mavila@amd.com&gt;
Signed-off-by: Raju Rangoju &lt;Raju.Rangoju@amd.com&gt;
Acked-by: Tom Lendacky &lt;thomas.lendacky@amd.com&gt;
Link: https://lore.kernel.org/r/20220127060222.453371-1-Raju.Rangoju@amd.com
Signed-off-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>ipheth: fix EOVERFLOW in ipheth_rcvbulk_callback</title>
<updated>2022-02-05T11:37:56Z</updated>
<author>
<name>Georgi Valkov</name>
<email>gvalkov@abv.bg</email>
</author>
<published>2022-02-01T07:16:18Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=77534b114f240d8a3296cfc576f0608880d2e5ed'/>
<id>urn:sha1:77534b114f240d8a3296cfc576f0608880d2e5ed</id>
<content type='text'>
commit 63e4b45c82ed1bde979da7052229a4229ce9cabf upstream.

When rx_buf is allocated we need to account for IPHETH_IP_ALIGN,
which reduces the usable size by 2 bytes. Otherwise we have 1512
bytes usable instead of 1514, and if we receive more than 1512
bytes, ipheth_rcvbulk_callback is called with status -EOVERFLOW,
after which the driver malfunctiones and all communication stops.

Resolves ipheth 2-1:4.2: ipheth_rcvbulk_callback: urb status: -75

Fixes: f33d9e2b48a3 ("usbnet: ipheth: fix connectivity with iOS 14")
Signed-off-by: Georgi Valkov &lt;gvalkov@abv.bg&gt;
Tested-by: Jan Kiszka &lt;jan.kiszka@siemens.com&gt;
Link: https://lore.kernel.org/all/B60B8A4B-92A0-49B3-805D-809A2433B46C@abv.bg/
Link: https://lore.kernel.org/all/24851bd2769434a5fc24730dce8e8a984c5a4505.1643699778.git.jan.kiszka@siemens.com/
Signed-off-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>net/mlx5: E-Switch, Fix uninitialized variable modact</title>
<updated>2022-02-05T11:37:56Z</updated>
<author>
<name>Maor Dickman</name>
<email>maord@nvidia.com</email>
</author>
<published>2022-01-30T14:00:41Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=b4ced7a46d9f51d3b48ad7c024da288723afacaf'/>
<id>urn:sha1:b4ced7a46d9f51d3b48ad7c024da288723afacaf</id>
<content type='text'>
commit d8e5883d694bb053b19c4142a2d1f43a34f6fe2c upstream.

The variable modact is not initialized before used in command
modify header allocation which can cause command to fail.

Fix by initializing modact with zeros.

Addresses-Coverity: ("Uninitialized scalar variable")
Fixes: 8f1e0b97cc70 ("net/mlx5: E-Switch, Mark miss packets with new chain id mapping")
Signed-off-by: Maor Dickman &lt;maord@nvidia.com&gt;
Reviewed-by: Roi Dayan &lt;roid@nvidia.com&gt;
Signed-off-by: Saeed Mahameed &lt;saeedm@nvidia.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>net/mlx5: Use del_timer_sync in fw reset flow of halting poll</title>
<updated>2022-02-05T11:37:56Z</updated>
<author>
<name>Maher Sanalla</name>
<email>msanalla@nvidia.com</email>
</author>
<published>2022-01-13T13:48:48Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=502c37b033fab7cde3e95a570af4f073306be45e'/>
<id>urn:sha1:502c37b033fab7cde3e95a570af4f073306be45e</id>
<content type='text'>
commit 3c5193a87b0fea090aa3f769d020337662d87b5e upstream.

Substitute del_timer() with del_timer_sync() in fw reset polling
deactivation flow, in order to prevent a race condition which occurs
when del_timer() is called and timer is deactivated while another
process is handling the timer interrupt. A situation that led to
the following call trace:
	RIP: 0010:run_timer_softirq+0x137/0x420
	&lt;IRQ&gt;
	recalibrate_cpu_khz+0x10/0x10
	ktime_get+0x3e/0xa0
	? sched_clock_cpu+0xb/0xc0
	__do_softirq+0xf5/0x2ea
	irq_exit_rcu+0xc1/0xf0
	sysvec_apic_timer_interrupt+0x9e/0xc0
	asm_sysvec_apic_timer_interrupt+0x12/0x20
	&lt;/IRQ&gt;

Fixes: 38b9f903f22b ("net/mlx5: Handle sync reset request event")
Signed-off-by: Maher Sanalla &lt;msanalla@nvidia.com&gt;
Reviewed-by: Moshe Shemesh &lt;moshe@nvidia.com&gt;
Signed-off-by: Saeed Mahameed &lt;saeedm@nvidia.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>net/mlx5e: Fix handling of wrong devices during bond netevent</title>
<updated>2022-02-05T11:37:56Z</updated>
<author>
<name>Maor Dickman</name>
<email>maord@nvidia.com</email>
</author>
<published>2022-01-13T13:11:42Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=a01ee1b8165f4161459b5ec4e728bc7130fe8cd4'/>
<id>urn:sha1:a01ee1b8165f4161459b5ec4e728bc7130fe8cd4</id>
<content type='text'>
commit ec41332e02bd0acf1f24206867bb6a02f5877a62 upstream.

Current implementation of bond netevent handler only check if
the handled netdev is VF representor and it missing a check if
the VF representor is on the same phys device of the bond handling
the netevent.

Fix by adding the missing check and optimizing the check if
the netdev is VF representor so it will not access uninitialized
private data and crashes.

BUG: kernel NULL pointer dereference, address: 000000000000036c
PGD 0 P4D 0
Oops: 0000 [#1] SMP NOPTI
Workqueue: eth3bond0 bond_mii_monitor [bonding]
RIP: 0010:mlx5e_is_uplink_rep+0xc/0x50 [mlx5_core]
RSP: 0018:ffff88812d69fd60 EFLAGS: 00010282
RAX: 0000000000000000 RBX: ffff8881cf800000 RCX: 0000000000000000
RDX: ffff88812d69fe10 RSI: 000000000000001b RDI: ffff8881cf800880
RBP: ffff8881cf800000 R08: 00000445cabccf2b R09: 0000000000000008
R10: 0000000000000004 R11: 0000000000000008 R12: ffff88812d69fe10
R13: 00000000fffffffe R14: ffff88820c0f9000 R15: 0000000000000000
FS:  0000000000000000(0000) GS:ffff88846fb00000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 000000000000036c CR3: 0000000103d80006 CR4: 0000000000370ea0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
 mlx5e_eswitch_uplink_rep+0x31/0x40 [mlx5_core]
 mlx5e_rep_is_lag_netdev+0x94/0xc0 [mlx5_core]
 mlx5e_rep_esw_bond_netevent+0xeb/0x3d0 [mlx5_core]
 raw_notifier_call_chain+0x41/0x60
 call_netdevice_notifiers_info+0x34/0x80
 netdev_lower_state_changed+0x4e/0xa0
 bond_mii_monitor+0x56b/0x640 [bonding]
 process_one_work+0x1b9/0x390
 worker_thread+0x4d/0x3d0
 ? rescuer_thread+0x350/0x350
 kthread+0x124/0x150
 ? set_kthread_struct+0x40/0x40
 ret_from_fork+0x1f/0x30

Fixes: 7e51891a237f ("net/mlx5e: Use netdev events to set/del egress acl forward-to-vport rule")
Signed-off-by: Maor Dickman &lt;maord@nvidia.com&gt;
Reviewed-by: Roi Dayan &lt;roid@nvidia.com&gt;
Signed-off-by: Saeed Mahameed &lt;saeedm@nvidia.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>net: ipa: prevent concurrent replenish</title>
<updated>2022-02-05T11:37:55Z</updated>
<author>
<name>Alex Elder</name>
<email>elder@linaro.org</email>
</author>
<published>2022-01-12T13:30:12Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=42fdbf8b7dab0328554899455a5b0a58526f8a63'/>
<id>urn:sha1:42fdbf8b7dab0328554899455a5b0a58526f8a63</id>
<content type='text'>
commit 998c0bd2b3715244da7639cc4e6a2062cb79c3f4 upstream.

We have seen cases where an endpoint RX completion interrupt arrives
while replenishing for the endpoint is underway.  This causes another
instance of replenishing to begin as part of completing the receive
transaction.  If this occurs it can lead to transaction corruption.

Use a new flag to ensure only one replenish instance for an endpoint
executes at a time.

Fixes: 84f9bd12d46db ("soc: qcom: ipa: IPA endpoints")
Signed-off-by: Alex Elder &lt;elder@linaro.org&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>
<entry>
<title>net: ipa: use a bitmap for endpoint replenish_enabled</title>
<updated>2022-02-05T11:37:55Z</updated>
<author>
<name>Alex Elder</name>
<email>elder@linaro.org</email>
</author>
<published>2022-01-12T13:30:11Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=ad81380d3a48f0d2f39ce5188d383897276c9c37'/>
<id>urn:sha1:ad81380d3a48f0d2f39ce5188d383897276c9c37</id>
<content type='text'>
commit c1aaa01dbf4cef95af3e04a5a43986c290e06ea3 upstream.

Define a new replenish_flags bitmap to contain Boolean flags
associated with an endpoint's replenishing state.  Replace the
replenish_enabled field with a flag in that bitmap.  This is to
prepare for the next patch, which adds another flag.

Signed-off-by: Alex Elder &lt;elder@linaro.org&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>
<entry>
<title>net: ipa: fix atomic update in ipa_endpoint_replenish()</title>
<updated>2022-02-05T11:37:55Z</updated>
<author>
<name>Alex Elder</name>
<email>elder@linaro.org</email>
</author>
<published>2022-01-12T13:30:10Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=2ed912e3e057b2e883cade4dcf9be74fcc5a7e82'/>
<id>urn:sha1:2ed912e3e057b2e883cade4dcf9be74fcc5a7e82</id>
<content type='text'>
commit 6c0e3b5ce94947b311348c367db9e11dcb2ccc93 upstream.

In ipa_endpoint_replenish(), if an error occurs when attempting to
replenish a receive buffer, we just quit and try again later.  In
that case we increment the backlog count to reflect that the attempt
was unsuccessful.  Then, if the add_one flag was true we increment
the backlog again.

This second increment is not included in the backlog local variable
though, and its value determines whether delayed work should be
scheduled.  This is a bug.

Fix this by determining whether 1 or 2 should be added to the
backlog before adding it in a atomic_add_return() call.

Reviewed-by: Matthias Kaehlcke &lt;mka@chromium.org&gt;
Fixes: 84f9bd12d46db ("soc: qcom: ipa: IPA endpoints")
Signed-off-by: Alex Elder &lt;elder@linaro.org&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>
<entry>
<title>net: hns3: handle empty unknown interrupt for VF</title>
<updated>2022-02-01T16:25:47Z</updated>
<author>
<name>Yufeng Mo</name>
<email>moyufeng@huawei.com</email>
</author>
<published>2022-01-25T07:03:12Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=699eef4ed910efd766ba8d16b9f8cd72f8161815'/>
<id>urn:sha1:699eef4ed910efd766ba8d16b9f8cd72f8161815</id>
<content type='text'>
[ Upstream commit 2f61353cd2f789a4229b6f5c1c24a40a613357bb ]

Since some interrupt states may be cleared by hardware, the driver
may receive an empty interrupt. Currently, the VF driver directly
disables the vector0 interrupt in this case. As a result, the VF
is unavailable. Therefore, the vector0 interrupt should be enabled
in this case.

Fixes: b90fcc5bd904 ("net: hns3: add reset handling for VF when doing Core/Global/IMP reset")
Signed-off-by: Yufeng Mo &lt;moyufeng@huawei.com&gt;
Signed-off-by: Guangbin Huang &lt;huangguangbin2@huawei.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>
</feed>
