Re: [PATCH net] hv_sock: Report EOF instead of -EIO for FIN

[Stefano Garzarella]

On Tue, Apr 14, 2026 at 04:43:16PM -0700, Dexuan Cui 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.
>
> 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: stable@xxxxxxxxxxxxxxx
> Reported-by: Ben Hillis <Ben.Hillis@xxxxxxxxxxxxx>
> Reported-by: Mitchell Levy <levymitchell0@xxxxxxxxx>
> Signed-off-by: Dexuan Cui <decui@xxxxxxxxxxxxx>
> ---
> net/vmw_vsock/hyperv_transport.c | 18 ++++++++++++++++--
> 1 file changed, 16 insertions(+), 2 deletions(-)
>
> diff --git a/net/vmw_vsock/hyperv_transport.c b/net/vmw_vsock/hyperv_transport.c
> index 069386a74557..63d3549125be 100644
> --- a/net/vmw_vsock/hyperv_transport.c
> +++ b/net/vmw_vsock/hyperv_transport.c
> @@ -703,8 +703,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 (!need_refill) {

Can we drop `need_refill` entirly and just check `hvs->recv_desc` here?

Mainly because now the comment we are adding is confusing me about what 
`need_refill` means.

The rest LGTM.

Thanks,
Stefano

> +			/* 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)
> --
> 2.49.0