Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1562884 > unrolled thread

[PATCH v2] xen-netfront: Fix Rx stall during network stress and OOM

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  [PATCH v2] xen-netfront: Fix Rx stall during network stress and OOM Vineeth Remanan Pillai <vineethp@amazon.com> - 2017-01-19 17:40 +0100
    Re: [PATCH v2] xen-netfront: Fix Rx stall during network stress  and OOM David Miller <davem@davemloft.net> - 2017-01-19 18:20 +0100
      Re: [PATCH v2] xen-netfront: Fix Rx stall during network stress  and OOM David Miller <davem@davemloft.net> - 2017-01-19 19:20 +0100
      Re: [PATCH v2] xen-netfront: Fix Rx stall during network stress and  OOM Vineeth Remanan Pillai <vineethp@amazon.com> - 2017-01-19 19:30 +0100
    Re: [PATCH v2] xen-netfront: Fix Rx stall during network stress  and OOM David Miller <davem@davemloft.net> - 2017-01-20 20:10 +0100
    Re: [PATCH v2] xen-netfront: Fix Rx stall during network stress and  OOM Boris Ostrovsky <boris.ostrovsky@oracle.com> - 2017-01-30 00:20 +0100
      Re: [PATCH v2] xen-netfront: Fix Rx stall during network stress and  OOM Vineeth Remanan Pillai <vineethp@amazon.com> - 2017-01-30 18:00 +0100
        Re: [PATCH v2] xen-netfront: Fix Rx stall during network stress and  OOM Boris Ostrovsky <boris.ostrovsky@oracle.com> - 2017-01-30 18:10 +0100
          Re: [PATCH v2] xen-netfront: Fix Rx stall during network stress and  OOM Vineeth Remanan Pillai <vineethp@amazon.com> - 2017-01-30 18:20 +0100

#1562884 — [PATCH v2] xen-netfront: Fix Rx stall during network stress and OOM

From: Vineeth Remanan Pillai <vineethp@amazon.com>

During an OOM scenario, request slots could not be created as skb
allocation fails. So the netback cannot pass in packets and netfront
wrongly assumes that there is no more work to be done and it disables
polling. This causes Rx to stall.

The issue is with the retry logic which schedules the timer if the
created slots are less than NET_RX_SLOTS_MIN. The count of new request
slots to be pushed are calculated as a difference between new req_prod
and rsp_cons which could be more than the actual slots, if there are
unconsumed responses.

The fix is to calculate the count of newly created slots as the
difference between new req_prod and old req_prod.

Signed-off-by: Vineeth Remanan Pillai <vineethp@amazon.com>
Reviewed-by: Juergen Gross <jgross@suse.com>
---
Changes in v2:
	- Removed the old implementation of enabling polling on
	  skb allocation error.
	- Corrected the refill timer logic to schedule when newly
	  created slots since last push is less than NET_RX_SLOTS_MIN.

  drivers/net/xen-netfront.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
index 40f26b6..2c7c29f 100644
--- a/drivers/net/xen-netfront.c
+++ b/drivers/net/xen-netfront.c
@@ -321,7 +321,7 @@ static void xennet_alloc_rx_buffers(struct netfront_queue *queue)
  	queue->rx.req_prod_pvt = req_prod;
  
  	/* Not enough requests? Try again later. */
-	if (req_prod - queue->rx.rsp_cons < NET_RX_SLOTS_MIN) {
+	if (req_prod - queue->rx.sring->req_prod < NET_RX_SLOTS_MIN) {
  		mod_timer(&queue->rx_refill_timer, jiffies + (HZ/10));
  		return;
  	}
-- 
2.7.4

[toc] | [next] | [standalone]

#1562951 — Re: [PATCH v2] xen-netfront: Fix Rx stall during network stress and OOM

From: Vineeth Remanan Pillai <vineethp@amazon.com>
Date: Thu, 19 Jan 2017 08:35:39 -0800

> From: Vineeth Remanan Pillai <vineethp@amazon.com>
> 
> During an OOM scenario, request slots could not be created as skb
> allocation fails. So the netback cannot pass in packets and netfront
> wrongly assumes that there is no more work to be done and it disables
> polling. This causes Rx to stall.
> 
> The issue is with the retry logic which schedules the timer if the
> created slots are less than NET_RX_SLOTS_MIN. The count of new request
> slots to be pushed are calculated as a difference between new req_prod
> and rsp_cons which could be more than the actual slots, if there are
> unconsumed responses.
> 
> The fix is to calculate the count of newly created slots as the
> difference between new req_prod and old req_prod.
> 
> Signed-off-by: Vineeth Remanan Pillai <vineethp@amazon.com>
> Reviewed-by: Juergen Gross <jgross@suse.com>
> ---
> Changes in v2:
> 	- Removed the old implementation of enabling polling on
> 	  skb allocation error.
> 	- Corrected the refill timer logic to schedule when newly
> 	  created slots since last push is less than NET_RX_SLOTS_MIN.

Your postings aren't showing up on vger.kernel.org at all.

Are you getting a bounce message back?  I can only assume you are triggering
one of the various content filters we have.

[toc] | [prev] | [next] | [standalone]

#1562987 — Re: [PATCH v2] xen-netfront: Fix Rx stall during network stress and OOM

From: Vineeth Remanan Pillai <vineethp@amazon.com>
Date: Thu, 19 Jan 2017 09:17:09 -0800

> Should I try sending it once again?

No need, it just showed up.

[toc] | [prev] | [next] | [standalone]

#1562992 — Re: [PATCH v2] xen-netfront: Fix Rx stall during network stress and OOM

On 01/19/2017 09:11 AM, David Miller wrote:
> From: Vineeth Remanan Pillai <vineethp@amazon.com>
> Date: Thu, 19 Jan 2017 08:35:39 -0800
>
>> From: Vineeth Remanan Pillai <vineethp@amazon.com>
>>
>> During an OOM scenario, request slots could not be created as skb
>> allocation fails. So the netback cannot pass in packets and netfront
>> wrongly assumes that there is no more work to be done and it disables
>> polling. This causes Rx to stall.
>>
>> The issue is with the retry logic which schedules the timer if the
>> created slots are less than NET_RX_SLOTS_MIN. The count of new request
>> slots to be pushed are calculated as a difference between new req_prod
>> and rsp_cons which could be more than the actual slots, if there are
>> unconsumed responses.
>>
>> The fix is to calculate the count of newly created slots as the
>> difference between new req_prod and old req_prod.
>>
>> Signed-off-by: Vineeth Remanan Pillai <vineethp@amazon.com>
>> Reviewed-by: Juergen Gross <jgross@suse.com>
>> ---
>> Changes in v2:
>> 	- Removed the old implementation of enabling polling on
>> 	  skb allocation error.
>> 	- Corrected the refill timer logic to schedule when newly
>> 	  created slots since last push is less than NET_RX_SLOTS_MIN.
> Your postings aren't showing up on vger.kernel.org at all.
>
> Are you getting a bounce message back?  I can only assume you are triggering
> one of the various content filters we have.
>
I haven't received any bounce messages till now. The mail showed up
in xen-devel after about 8 hours yesterday. Not sure what is happening
with vger.kernel.org. My initial patch showed up in all the mailing 
list. The
only difference is, I switched to a machine running a later version of git.

Should I try sending it once again?

Thanks

[toc] | [prev] | [next] | [standalone]

#1563873 — Re: [PATCH v2] xen-netfront: Fix Rx stall during network stress and OOM

From: Vineeth Remanan Pillai <vineethp@amazon.com>
Date: Thu, 19 Jan 2017 08:35:39 -0800

> From: Vineeth Remanan Pillai <vineethp@amazon.com>
> 
> During an OOM scenario, request slots could not be created as skb
> allocation fails. So the netback cannot pass in packets and netfront
> wrongly assumes that there is no more work to be done and it disables
> polling. This causes Rx to stall.
> 
> The issue is with the retry logic which schedules the timer if the
> created slots are less than NET_RX_SLOTS_MIN. The count of new request
> slots to be pushed are calculated as a difference between new req_prod
> and rsp_cons which could be more than the actual slots, if there are
> unconsumed responses.
> 
> The fix is to calculate the count of newly created slots as the
> difference between new req_prod and old req_prod.
> 
> Signed-off-by: Vineeth Remanan Pillai <vineethp@amazon.com>
> Reviewed-by: Juergen Gross <jgross@suse.com>
> ---
> Changes in v2:
> 	- Removed the old implementation of enabling polling on
> 	  skb allocation error.
> 	- Corrected the refill timer logic to schedule when newly
> 	  created slots since last push is less than NET_RX_SLOTS_MIN.

Applied.

[toc] | [prev] | [next] | [standalone]

#1569307 — Re: [PATCH v2] xen-netfront: Fix Rx stall during network stress and OOM

On 01/19/2017 11:35 AM, Vineeth Remanan Pillai wrote:
> From: Vineeth Remanan Pillai <vineethp@amazon.com>
>
> During an OOM scenario, request slots could not be created as skb
> allocation fails. So the netback cannot pass in packets and netfront
> wrongly assumes that there is no more work to be done and it disables
> polling. This causes Rx to stall.
>
> The issue is with the retry logic which schedules the timer if the
> created slots are less than NET_RX_SLOTS_MIN. The count of new request
> slots to be pushed are calculated as a difference between new req_prod
> and rsp_cons which could be more than the actual slots, if there are
> unconsumed responses.
>
> The fix is to calculate the count of newly created slots as the
> difference between new req_prod and old req_prod.
>
> Signed-off-by: Vineeth Remanan Pillai <vineethp@amazon.com>
> Reviewed-by: Juergen Gross <jgross@suse.com>
> ---
> Changes in v2:
>     - Removed the old implementation of enabling polling on
>       skb allocation error.
>     - Corrected the refill timer logic to schedule when newly
>       created slots since last push is less than NET_RX_SLOTS_MIN.


There are couple of problems with this patch.
1. The 'if' clause now evaluates to true on pretty much every call to 
xennet_alloc_rx_buffers().
2. It tickles a latent bug during resume where the timer triggers before 
we re-connect. The trouble is that we now try to dereference 
queue->rx.sring which is NULL since we disconnect in netfront_resume(). 
(Curiously, I only observe it with 32-bit guests)

I'll send a patch later that will delete the timer since it looks like a 
bug to me in any case but the first problem seems to be more serious 
than the problem that this patch addresses.

-boris

>
>  drivers/net/xen-netfront.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
> index 40f26b6..2c7c29f 100644
> --- a/drivers/net/xen-netfront.c
> +++ b/drivers/net/xen-netfront.c
> @@ -321,7 +321,7 @@ static void xennet_alloc_rx_buffers(struct
> netfront_queue *queue)
>      queue->rx.req_prod_pvt = req_prod;
>
>      /* Not enough requests? Try again later. */
> -    if (req_prod - queue->rx.rsp_cons < NET_RX_SLOTS_MIN) {
> +    if (req_prod - queue->rx.sring->req_prod < NET_RX_SLOTS_MIN) {
>          mod_timer(&queue->rx_refill_timer, jiffies + (HZ/10));
>          return;
>      }

[toc] | [prev] | [next] | [standalone]

#1569893 — Re: [PATCH v2] xen-netfront: Fix Rx stall during network stress and OOM

On 01/29/2017 03:09 PM, Boris Ostrovsky wrote:
>
> There are couple of problems with this patch.
> 1. The 'if' clause now evaluates to true on pretty much every call to 
> xennet_alloc_rx_buffers().
Thanks for catching this. In my testing I did not notice this - mostly 
because of the nature of the workload in my testing.

> 2. It tickles a latent bug during resume where the timer triggers 
> before we re-connect. The trouble is that we now try to dereference 
> queue->rx.sring which is NULL since we disconnect in 
> netfront_resume(). (Curiously, I only observe it with 32-bit guests)
I think we may hit this bug after removing the timer as well. We call 
RING_PUSH_REQUESTS_AND_CHECK_NOTIFY soon after, which also dereference 
queue->rx.sring.

Thanks,
Vineeth

[toc] | [prev] | [next] | [standalone]

#1569903 — Re: [PATCH v2] xen-netfront: Fix Rx stall during network stress and OOM

On 01/30/2017 11:47 AM, Vineeth Remanan Pillai wrote:
>
>> 2. It tickles a latent bug during resume where the timer triggers
>> before we re-connect. The trouble is that we now try to dereference
>> queue->rx.sring which is NULL since we disconnect in
>> netfront_resume(). (Curiously, I only observe it with 32-bit guests)
> I think we may hit this bug after removing the timer as well. We call
> RING_PUSH_REQUESTS_AND_CHECK_NOTIFY soon after, which also dereference
> queue->rx.sring.


If the timer is deleted in xennet_disconnect_backend() then why would
anyone be pushing anything to the backend after that?

-boris

[toc] | [prev] | [next] | [standalone]

#1569923 — Re: [PATCH v2] xen-netfront: Fix Rx stall during network stress and OOM

On 01/30/2017 09:06 AM, Boris Ostrovsky wrote:
> On 01/30/2017 11:47 AM, Vineeth Remanan Pillai wrote:
>
>>> 2. It tickles a latent bug during resume where the timer triggers
>>> before we re-connect. The trouble is that we now try to dereference
>>> queue->rx.sring which is NULL since we disconnect in
>>> netfront_resume(). (Curiously, I only observe it with 32-bit guests)
>> I think we may hit this bug after removing the timer as well. We call
>> RING_PUSH_REQUESTS_AND_CHECK_NOTIFY soon after, which also dereference
>> queue->rx.sring.
> If the timer is deleted in xennet_disconnect_backend() then why would
> anyone be pushing anything to the backend after that?
Sorry, I got the ordering wrong. Thanks for the clarification..

Thanks,
Vineeth

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web