[PATCH net] hyperv: Fix the error processing in netvsc_send()

[PATCH net] hyperv: Fix the error processing in netvsc_send()

[Haiyang Zhang]

The existing code frees the skb in EAGAIN case, in which the skb will be
retried from upper layer and used again.
Also, the existing code doesn't free send buffer slot in error case, because
there is no completion message for unsent packets.
This patch fixes these problems.

(Please also include this patch for stable trees. Thanks!)

Signed-off-by: Haiyang Zhang <haiyangz@microsoft.com>
Reviewed-by: K. Y. Srinivasan <kys@microsoft.com>
---
 drivers/net/hyperv/netvsc.c |   11 ++++++++---
 1 files changed, 8 insertions(+), 3 deletions(-)

diff --git a/drivers/net/hyperv/netvsc.c b/drivers/net/hyperv/netvsc.c
index 9f49c01..7cd4eb3 100644
--- a/drivers/net/hyperv/netvsc.c
+++ b/drivers/net/hyperv/netvsc.c
@@ -716,7 +716,7 @@ int netvsc_send(struct hv_device *device,
 	u64 req_id;
 	unsigned int section_index = NETVSC_INVALID_INDEX;
 	u32 msg_size = 0;
-	struct sk_buff *skb;
+	struct sk_buff *skb = NULL;
 	u16 q_idx = packet->q_idx;
 
 
@@ -743,8 +743,6 @@ int netvsc_send(struct hv_device *device,
 							   packet);
 			skb = (struct sk_buff *)
 			      (unsigned long)packet->send_completion_tid;
-			if (skb)
-				dev_kfree_skb_any(skb);
 			packet->page_buf_cnt = 0;
 		}
 	}
@@ -810,6 +808,13 @@ int netvsc_send(struct hv_device *device,
 			   packet, ret);
 	}
 
+	if (ret != 0) {
+		if (section_index != NETVSC_INVALID_INDEX)
+			netvsc_free_send_slot(net_device, section_index);
+	} else if (skb) {
+		dev_kfree_skb_any(skb);
+	}
+
 	return ret;
 }
 
-- 
1.7.4.1

Re: [PATCH net] hyperv: Fix the error processing in netvsc_send()

[Jason Wang]

On Fri, Jan 30, 2015 at 4:34 AM, Haiyang Zhang <haiyangz@microsoft.com> 
wrote:
> The existing code frees the skb in EAGAIN case, in which the skb will 
> be
> retried from upper layer and used again.
> Also, the existing code doesn't free send buffer slot in error case, 
> because
> there is no completion message for unsent packets.
> This patch fixes these problems.
> 
> (Please also include this patch for stable trees. Thanks!)
> 
> Signed-off-by: Haiyang Zhang <haiyangz@microsoft.com>
> Reviewed-by: K. Y. Srinivasan <kys@microsoft.com>
> ---
>  drivers/net/hyperv/netvsc.c |   11 ++++++++---
>  1 files changed, 8 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/net/hyperv/netvsc.c b/drivers/net/hyperv/netvsc.c
> index 9f49c01..7cd4eb3 100644
> --- a/drivers/net/hyperv/netvsc.c
> +++ b/drivers/net/hyperv/netvsc.c
> @@ -716,7 +716,7 @@ int netvsc_send(struct hv_device *device,
>  	u64 req_id;
>  	unsigned int section_index = NETVSC_INVALID_INDEX;
>  	u32 msg_size = 0;
> -	struct sk_buff *skb;
> +	struct sk_buff *skb = NULL;
>  	u16 q_idx = packet->q_idx;
>  
>  
> @@ -743,8 +743,6 @@ int netvsc_send(struct hv_device *device,
>  							   packet);
>  			skb = (struct sk_buff *)
>  			      (unsigned long)packet->send_completion_tid;
> -			if (skb)
> -				dev_kfree_skb_any(skb);
>  			packet->page_buf_cnt = 0;
>  		}
>  	}
> @@ -810,6 +808,13 @@ int netvsc_send(struct hv_device *device,
>  			   packet, ret);
>  	}
>  
> +	if (ret != 0) {
> +		if (section_index != NETVSC_INVALID_INDEX)
> +			netvsc_free_send_slot(net_device, section_index);

What if ret is -EINVAL or -ENOSPC? Looks like we need free the skb in 
this case also.
> 
> +	} else if (skb) {
> +		dev_kfree_skb_any(skb);

The caller - netvsc_start_xmit() do this also, may be handle this in 
caller is better since netvsc_start_xmit() is the only user that tries 
to send a skb?

btw, I find during netvsc_start_xmit(), ret was change to -ENOSPC when 
queue_sends[q_idx] < 1. But non of the caller check -ENOSPC in fact?

Thanks
> 
> +	}
> +
>  	return ret;
>  }
>  
> -- 
> 1.7.4.1
> 
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH net] hyperv: Fix the error processing in netvsc_send()

[Haiyang Zhang]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="utf-8", Size: 1450 bytes --]



> -----Original Message-----
> From: Jason Wang [mailto:jasowang@redhat.com]
> Sent: Friday, January 30, 2015 5:25 AM
> > +	if (ret != 0) {
> > +		if (section_index != NETVSC_INVALID_INDEX)
> > +			netvsc_free_send_slot(net_device, section_index);
> 
> What if ret is -EINVAL or -ENOSPC? Looks like we need free the skb in
> this case also.

In these cases, skb is freed in netvsc_start_xmit().


> >
> > +	} else if (skb) {
> > +		dev_kfree_skb_any(skb);
> 
> The caller - netvsc_start_xmit() do this also, may be handle this in
> caller is better since netvsc_start_xmit() is the only user that tries
> to send a skb?

When the packet is sent out normally, we frees it in netvsc_send() if it's
copied to send-buffer. The free is done in netvsc_send(), because the copy
is also in this function. If it's not copied, it will be freed in another
function -- netvsc_xmit_completion().

netvsc_start_xmit() only does free skb in error case.

> btw, I find during netvsc_start_xmit(), ret was change to -ENOSPC when
> queue_sends[q_idx] < 1. But non of the caller check -ENOSPC in fact?

In this case, we don't request re-send, so set ret to a value other than
-EAGAIN. It's handled in the same way as errors != -EAGAIN, so we don't
need to check this value specifically.

Thanks,
- Haiyang

ÿôèº{.nÇ+‰·Ÿ®‰­†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±þG«éÿŠ{ayº\x1dʇڙë,j\a­¢f£¢·hšïêÿ‘êçz_è®\x03(­éšŽŠÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?™¨è­Ú&£ø§~á¶iO•æ¬z·švØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?–I¥

Re: [PATCH net] hyperv: Fix the error processing in netvsc_send()

[David Miller]

From: Haiyang Zhang <haiyangz@microsoft.com>
Date: Thu, 29 Jan 2015 12:34:49 -0800

> The existing code frees the skb in EAGAIN case, in which the skb will be
> retried from upper layer and used again.
> Also, the existing code doesn't free send buffer slot in error case, because
> there is no completion message for unsent packets.
> This patch fixes these problems.
> 
> (Please also include this patch for stable trees. Thanks!)
> 
> Signed-off-by: Haiyang Zhang <haiyangz@microsoft.com>
> Reviewed-by: K. Y. Srinivasan <kys@microsoft.com>

Applied and queued up for -stable, thanks.

RE: [PATCH net] hyperv: Fix the error processing in netvsc_send()

[Jason Wang]

On Fri, Jan 30, 2015 at 11:05 PM, Haiyang Zhang 
<haiyangz@microsoft.com> wrote:
> 
> 
>>  -----Original Message-----
>>  From: Jason Wang [mailto:jasowang@redhat.com]
>>  Sent: Friday, January 30, 2015 5:25 AM
>>  > +	if (ret != 0) {
>>  > +		if (section_index != NETVSC_INVALID_INDEX)
>>  > +			netvsc_free_send_slot(net_device, section_index);
>>  
>>  What if ret is -EINVAL or -ENOSPC? Looks like we need free the skb 
>> in
>>  this case also.
> 
> In these cases, skb is freed in netvsc_start_xmit().
> 
> 
>>  >
>>  > +	} else if (skb) {
>>  > +		dev_kfree_skb_any(skb);
>>  
>>  The caller - netvsc_start_xmit() do this also, may be handle this in
>>  caller is better since netvsc_start_xmit() is the only user that 
>> tries
>>  to send a skb?
> 
> When the packet is sent out normally, we frees it in netvsc_send() if 
> it's
> copied to send-buffer. The free is done in netvsc_send(), because the 
> copy
> is also in this function. If it's not copied, it will be freed in 
> another
> function -- netvsc_xmit_completion().
> 
> netvsc_start_xmit() only does free skb in error case.

Ok.
> 
> 
>>  btw, I find during netvsc_start_xmit(), ret was change to -ENOSPC 
>> when
>>  queue_sends[q_idx] < 1. But non of the caller check -ENOSPC in fact?
> 
> In this case, we don't request re-send, so set ret to a value other 
> than
> -EAGAIN. 

Why not? We have available slots for it to be sent now. Dropping the 
packet in this case may cause out of order sending.
> It's handled in the same way as errors != -EAGAIN, so we don't
> need to check this value specifically.

Thanks

RE: [PATCH net] hyperv: Fix the error processing in netvsc_send()

[Haiyang Zhang]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="utf-8", Size: 1198 bytes --]



> -----Original Message-----
> From: Jason Wang [mailto:jasowang@redhat.com]
> Sent: Monday, February 2, 2015 1:49 AM
> >>  btw, I find during netvsc_start_xmit(), ret was change to -ENOSPC
> >> when
> >>  queue_sends[q_idx] < 1. But non of the caller check -ENOSPC in fact?
> >
> > In this case, we don't request re-send, so set ret to a value other
> > than
> > -EAGAIN.
> 
> Why not? We have available slots for it to be sent now. Dropping the
> packet in this case may cause out of order sending.

The EAGAIN error doesn't normally happen, because we set the hi water mark
to stop send queue. If in really rare case, the ring buffer is full and there
is no outstanding sends, we can't stop queue here because there will be no
send-completion msg to wake it up. And, the ring buffer is likely to be 
occupied by other special msg, e.g. receive-completion msg (not a normal case),
so we can't assume there are available slots. We don't request retry from
the upper layer in this case to avoid possible busy retry.

Thanks,
- Haiyang

ÿôèº{.nÇ+‰·Ÿ®‰­†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±þG«éÿŠ{ayº\x1dʇڙë,j\a­¢f£¢·hšïêÿ‘êçz_è®\x03(­éšŽŠÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?™¨è­Ú&£ø§~á¶iO•æ¬z·švØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?–I¥

RE: [PATCH net] hyperv: Fix the error processing in netvsc_send()

[Jason Wang]

On Tue, Feb 3, 2015 at 11:46 PM, Haiyang Zhang <haiyangz@microsoft.com> 
wrote:
> 
> 
>>  -----Original Message-----
>>  From: Jason Wang [mailto:jasowang@redhat.com]
>>  Sent: Monday, February 2, 2015 1:49 AM
>>  >>  btw, I find during netvsc_start_xmit(), ret was change to 
>> -ENOSPC
>>  >> when
>>  >>  queue_sends[q_idx] < 1. But non of the caller check -ENOSPC in 
>> fact?
>>  >
>>  > In this case, we don't request re-send, so set ret to a value 
>> other
>>  > than
>>  > -EAGAIN.
>>  
>>  Why not? We have available slots for it to be sent now. Dropping the
>>  packet in this case may cause out of order sending.
> 
> The EAGAIN error doesn't normally happen, because we set the hi water 
> mark
> to stop send queue.

This is not true since only txq was stopped which means only network 
stack stop sending packets but not for control path e.g 
rndis_filter_send_request() or other callers who call 
vmbus_sendpacket() directly (e.g recv completion). 

For control path, user may meet several errors when they want to change 
mac address under heavy load. 

What's more serious is netvsc_send_recv_completion(), it can not even 
recover from more than 3 times of EAGAIN.

I must say mixing data packets with control packets with the same 
channel sounds really scary. Since control packets could be blocked or 
even dropped because of data packets already queued during heavy load, 
and you need to synchronize two paths carefully (e.g I didn't see any 
tx lock were held if rndis_filter_send_request() call netsc_send() 
which may stop or start a queue).

>  If in really rare case, the ring buffer is full and there
> is no outstanding sends, we can't stop queue here because there will 
> be no
> send-completion msg to wake it up. 

Confused, I believe only txq is stopped but we may still get completion 
interrupt in this case.

> And, the ring buffer is likely to be 
> occupied by other special msg, e.g. receive-completion msg (not a 
> normal case),
> so we can't assume there are available slots. 

Then why not checking hv_ringbuf_avail_percent() instead? And there's 
no need to check queue_sends since it does not count recv completion.

> We don't request retry from
> the upper layer in this case to avoid possible busy retry.

Can't we just do this by stopping txq and depending on tx interrupt to 
wake it?

Thanks

RE: [PATCH net] hyperv: Fix the error processing in netvsc_send()

[Haiyang Zhang]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="utf-8", Size: 2850 bytes --]



> -----Original Message-----
> From: Jason Wang [mailto:jasowang@redhat.com]
> Sent: Wednesday, February 4, 2015 2:29 AM
> > The EAGAIN error doesn't normally happen, because we set the hi water
> > mark
> > to stop send queue.
> 
> This is not true since only txq was stopped which means only network
> stack stop sending packets but not for control path e.g
> rndis_filter_send_request() or other callers who call
> vmbus_sendpacket() directly (e.g recv completion).
> 
> For control path, user may meet several errors when they want to change
> mac address under heavy load.
> 
> What's more serious is netvsc_send_recv_completion(), it can not even
> recover from more than 3 times of EAGAIN.
> 
> I must say mixing data packets with control packets with the same
> channel sounds really scary. Since control packets could be blocked or
> even dropped because of data packets already queued during heavy load,
> and you need to synchronize two paths carefully (e.g I didn't see any
> tx lock were held if rndis_filter_send_request() call netsc_send()
> which may stop or start a queue).

The RING_AVAIL_PERCENT_HIWATER is defined to be 20, so the data traffic
can only occupy 20% of the ring buffer before stopping the txq. So, this
mechanism ensures the control messages are not blocked by data traffic.

> >  If in really rare case, the ring buffer is full and there
> > is no outstanding sends, we can't stop queue here because there will
> > be no
> > send-completion msg to wake it up.
> 
> Confused, I believe only txq is stopped but we may still get completion
> interrupt in this case.

If there is no outstanding sends in this queue (queue_sends[q_idx]), we 
won't receive any more send-completion msg.

> 
> > And, the ring buffer is likely to be
> > occupied by other special msg, e.g. receive-completion msg (not a
> > normal case),
> > so we can't assume there are available slots.
> 
> Then why not checking hv_ringbuf_avail_percent() instead? And there's
> no need to check queue_sends since it does not count recv completion.

When ret == -EAGAIN, which means the ring is full, we don't need to check
hv_ringbuf_avail_percent().

> > We don't request retry from
> > the upper layer in this case to avoid possible busy retry.
> 
> Can't we just do this by stopping txq and depending on tx interrupt to
> wake it?

There is no tx interrupt. Do you mean rx interrupt for the send-completion?

In usual cases, when we hit the high water mark, the stopped queue depends on
the send-completion msg to wake up. But, not in some special cases.
As said above, we won't receive any more send-completion msg when there is 
no outstanding sends in this queue.

Thanks,
- Haiyang

ÿôèº{.nÇ+‰·Ÿ®‰­†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±þG«éÿŠ{ayº\x1dʇڙë,j\a­¢f£¢·hšïêÿ‘êçz_è®\x03(­éšŽŠÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?™¨è­Ú&£ø§~á¶iO•æ¬z·švØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?–I¥