hv_sock: Report EOF instead of -EIO for FIN

PATCH Applied Dexuan Cui 4 participants 7 messages Apr 16 – Apr 21

Subsystems (7)

Networking Network drivers Stable branch virtio core +3 more subsystems

lore

Share & tools

lore

Dexuan Cui

author maintainer

2026-04-16 19:15 UTC #0 lore raw

PATCH v2 1/1 hv_sock: Report EOF instead of -EIO for FIN

Commit f0c5827d07cb unluckily causes a regression for the FIN packet, and the final read syscall gets an error rather than 0.

Ideally, we would want to fix hvs_channel_readable_payload() so that it could return 0 in the FIN scenario, but it's not good for the hv_sock driver to use the VMBus ringbuffer's cached priv_read_index, which is internal data in the VMBus driver.

Fix the regression in hv_sock by returning 0 rather than -EIO.

Fixes f0c5827d07cb ("hv_sock: Return the readable bytes in hvs_stream_has_data()")

Cc [email protected]

Reported-by Ben Hillis <[email protected]>

Reported-by Mitchell Levy <[email protected]>

Signed-off-by Dexuan Cui <[email protected]>

---

Changes since v1:
Removed the local variable 'need_refill' to make the code more readable. Stefano, thanks!

No other change.

 net/vmw_vsock/hyperv_transport.c | 20 ++++++++++++++++----
 1 file changed, 16 insertions(+), 4 deletions(-)

net/vmw_vsock/hyperv_transport.c +16 -4

index 069386a74557..e5ee7aa14d0c 100644
@@ -694,7 +694,6 @@ static ssize_t hvs_stream_enqueue(struct vsock_sock *vsk, struct msghdr *msg,
 static s64 hvs_stream_has_data(struct vsock_sock *vsk)
 {
 	struct hvsock *hvs = vsk->trans;
-	bool need_refill;
 	s64 ret;
 
 	if (hvs->recv_data_len > 0)

@@ -702,9 +701,22 @@ static s64 hvs_stream_has_data(struct vsock_sock *vsk)
 
 	switch (hvs_channel_readable_payload(hvs->chan)) {
 	case 1:
-		need_refill = !hvs->recv_desc;
-		if (!need_refill)
-			return -EIO;
+		if (hvs->recv_desc) {
+			/* Here hvs->recv_data_len is 0, so hvs->recv_desc must
+			 * be NULL unless it points to the 0-byte-payload FIN
+			 * packet: see hvs_update_recv_data().
+			 *
+			 * Here all the payload has been dequeued, but
+			 * hvs_channel_readable_payload() still returns 1,
+			 * because the VMBus ringbuffer's read_index is not
+			 * updated for the FIN packet: hvs_stream_dequeue() ->
+			 * hv_pkt_iter_next() updates the cached priv_read_index
+			 * but has no opportunity to update the read_index in
+			 * hv_pkt_iter_close() as hvs_stream_has_data() returns
+			 * 0 for the FIN packet, so it won't get dequeued.
+			 */
+			return 0;
+		}
 
 		hvs->recv_desc = hv_pkt_iter_first(hvs->chan);
 		if (!hvs->recv_desc)

Signature · 1 line

2.49.0

Stefano Garzarella

maintainer Acked-by on v2 1/1

2026-04-17 08:11 UTC #1 lore raw

Quoted 15 lines · Dexuan Cui

Commit f0c5827d07cb unluckily causes a regression for the FIN packet, and the final read syscall gets an error rather than 0.
Ideally, we would want to fix hvs_channel_readable_payload() so that it could return 0 in the FIN scenario, but it's not good for the hv_sock driver to use the VMBus ringbuffer's cached priv_read_index, which is internal data in the VMBus driver.
Fix the regression in hv_sock by returning 0 rather than -EIO.
Fixes f0c5827d07cb ("hv_sock: Return the readable bytes in hvs_stream_has_data()")
Cc [email protected]
Reported-by Ben Hillis <[email protected]>
Reported-by Mitchell Levy <[email protected]>
Signed-off-by Dexuan Cui <[email protected]>

Quoted 5 lines

---
Changes since v1:
Removed the local variable 'need_refill' to make the code more readable. Stefano, thanks!

Thanks for the fix!

Quoted 5 lines

No other change.
net/vmw_vsock/hyperv_transport.c | 20 ++++++++++++++++----
1 file changed, 16 insertions(+), 4 deletions(-)

Acked-by Stefano Garzarella <[email protected]>

[email protected]

CI Applied

2026-04-20 22:00 UTC #2 lore raw

In reply to Dexuan Cui

This patch was applied to netdev/net.git (main) by Jakub Kicinski <[email protected]>:

Hello:

This patch was applied to netdev/net.git (main)
by Jakub Kicinski <[email protected]>:

Quoted 9 lines · On Thu, 16 Apr 2026 12:14:33 -0700 you wrote:

Commit f0c5827d07cb unluckily causes a regression for the FIN packet, and the final read syscall gets an error rather than 0.
Ideally, we would want to fix hvs_channel_readable_payload() so that it could return 0 in the FIN scenario, but it's not good for the hv_sock driver to use the VMBus ringbuffer's cached priv_read_index, which is internal data in the VMBus driver.
[...]

Here is the summary with links:
- [net,v2] hv_sock: Report EOF instead of -EIO for FIN

    https://git.kernel.org/netdev/net/c/f63152958994

You are awesome, thank you!

Signature · 2 lines

Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html

Dexuan Cui

author maintainer

2026-04-21 03:13 UTC #3 lore raw

Quoted 8 lines

From: [email protected] <patchwork- [email protected]>
Sent: Monday, April 20, 2026 3:00 PM
Quoted 1 line
[...]
Here is the summary with links:
- [net,v2] hv_sock: Report EOF instead of -EIO for FIN
https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git/commit/?id=f63152958994

Hi Jakub, Stefano,
I'm sorry -- I just posted v3

    https://lore.kernel.org/linux-hyperv/[email protected]/T/#u

and then I realized that the v2 had been merged into the main branch :-(

Should I post a new delta patch(with a Fixes tag against the v2) based on the main branch?

Thanks,
Dexuan

Stefano Garzarella

maintainer

2026-04-21 07:28 UTC #4 lore raw

Quoted 10 lines · Dexuan Cui

Quoted 9 lines
From: [email protected] <patchwork- [email protected]>
Sent: Monday, April 20, 2026 3:00 PM
Quoted 1 line
[...]
Here is the summary with links:
- [net,v2] hv_sock: Report EOF instead of -EIO for FIN
https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git/commit/?id=f63152958994

Quoted 6 lines

Hi Jakub, Stefano,
I'm sorry -- I just posted v3
    https://lore.kernel.org/linux-hyperv/[email protected]/T/#u
and then I realized that the v2 had been merged into the main branch :-(
Should I post a new delta patch(with a Fixes tag against the v2) based on the main branch?

Ehm, I'm not sure about the process but if it's merged in net tree, maybe we need a follow up patch.

Anyway, let's wait for Jakub's or other net maintainers' suggestions.

Thanks,
Stefano

Jakub Kicinski

maintainer

2026-04-21 14:18 UTC #5 lore raw

Quoted 10 lines · On Tue, 21 Apr 2026 09:28:19 +0200 Stefano Garzarella wrote:

Quoted 5 lines
I'm sorry -- I just posted v3
    https://lore.kernel.org/linux-hyperv/[email protected]/T/#u
and then I realized that the v2 had been merged into the main branch :-(
Should I post a new delta patch(with a Fixes tag against the v2) based on the main branch?
Ehm, I'm not sure about the process but if it's merged in net tree, maybe we need a follow up patch.
Anyway, let's wait for Jakub's or other net maintainers' suggestions.

Yes, you have to post an incremental fix

Dexuan Cui

author maintainer

2026-04-21 17:54 UTC #6 lore raw

Quoted 6 lines

From: Jakub Kicinski <[email protected]>
Sent: Tuesday, April 21, 2026 7:19 AM
...
Quoted 1 line
Anyway, let's wait for Jakub's or other net maintainers' suggestions.
Yes, you have to post an incremental fix

Thanks for the quick replies! I posted an incremental fix:
https://lore.kernel.org/linux-hyperv/[email protected]/T/#u