Re: [RESEND PATCH net-next v4 2/4] hv_sock: Return the readable bytes in hvs_stream_has_data()

[Xuewei Niu <niuxuewei97@gmail.com>]

> On Jul 2, 2025, at 17:58, Stefano Garzarella <sgarzare@redhat.com> wrote:
> 
> On Mon, Jun 30, 2025 at 03:57:25PM +0800, Xuewei Niu wrote:
> 
> IMO here you should not reset the author to you, but you should keep
> Dexuan as authour of this patch.

Well, I did that. However, `./scripts/checkpatch.pl` is unhappy wihtout my SOB.
Perhaps I should ignore it, and will do in the next :)  

> 
>> When hv_sock was originally added, __vsock_stream_recvmsg() and
>> vsock_stream_has_data() actually only needed to know whether there
>> is any readable data or not, so hvs_stream_has_data() was written to
>> return 1 or 0 for simplicity.
>> 
>> However, now hvs_stream_has_data() should return the readable bytes
>> because vsock_data_ready() -> vsock_stream_has_data() needs to know the
>> actual bytes rather than a boolean value of 1 or 0.
>> 
>> The SIOCINQ ioctl support also needs hvs_stream_has_data() to return
>> the readable bytes.
>> 
>> Let hvs_stream_has_data() return the readable bytes of the payload in
>> the next host-to-guest VMBus hv_sock packet.
>> 
>> Note: there may be multpile incoming hv_sock packets pending in the
>> VMBus channel's ringbuffer, but so far there is not a VMBus API that
>> allows us to know all the readable bytes in total without reading and
>> caching the payload of the multiple packets, so let's just return the
>> readable bytes of the next single packet. In the future, we'll either
>> add a VMBus API that allows us to know the total readable bytes without
>> touching the data in the ringbuffer, or the hv_sock driver needs to
>> understand the VMBus packet format and parse the packets directly.
>> 
>> Signed-off-by: Dexuan Cui <decui@microsoft.com>
>> Signed-off-by: Xuewei Niu <niuxuewei.nxw@antgroup.com>
>> ---
>> net/vmw_vsock/hyperv_transport.c | 16 +++++++++++++---
>> 1 file changed, 13 insertions(+), 3 deletions(-)
>> 
>> diff --git a/net/vmw_vsock/hyperv_transport.c b/net/vmw_vsock/hyperv_transport.c
>> index 31342ab502b4..64f1290a9ae7 100644
>> --- a/net/vmw_vsock/hyperv_transport.c
>> +++ b/net/vmw_vsock/hyperv_transport.c
>> @@ -694,15 +694,25 @@ 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 = !hvs->recv_desc;
> 
> For v5 remember to fix this as Paolo suggested. Dexuan proposed a fix on his thread.

Will do. And big thanks to Dexuan for the great work.

Thanks,
Xuewei

> Stefano
> 
>> 	s64 ret;
>> 
>> 	if (hvs->recv_data_len > 0)
>> -		return 1;
>> +		return hvs->recv_data_len;
>> 
>> 	switch (hvs_channel_readable_payload(hvs->chan)) {
>> 	case 1:
>> -		ret = 1;
>> -		break;
>> +		if (!need_refill)
>> +			return -EIO;
>> +
>> +		hvs->recv_desc = hv_pkt_iter_first(hvs->chan);
>> +		if (!hvs->recv_desc)
>> +			return -ENOBUFS;
>> +
>> +		ret = hvs_update_recv_data(hvs);
>> +		if (ret)
>> +			return ret;
>> +		return hvs->recv_data_len;
>> 	case 0:
>> 		vsk->peer_shutdown |= SEND_SHUTDOWN;
>> 		ret = 0;
>> -- 
>> 2.34.1
>> 
>