virtio_net: Make delayed refill more reliable (Closes: #576838)
svn path=/dists/sid/linux-2.6/; revision=15584
This commit is contained in:
parent
a594afd1b6
commit
c0bb5557f8
|
@ -24,6 +24,7 @@ linux-2.6 (2.6.32-12) UNRELEASED; urgency=low
|
|||
* megaraid_sas: Fix copying of sense data for 32-bit management tools on
|
||||
64-bit kernel (Closes: #578398)
|
||||
* Add ipheth driver for iPhone tethering
|
||||
* virtio_net: Make delayed refill more reliable (Closes: #576838)
|
||||
|
||||
[ maximilian attems]
|
||||
* [ia64] Built in fbcon.
|
||||
|
|
50
debian/patches/bugfix/all/virtio_net-Make-delayed-refill-more-reliable.patch
vendored
Normal file
50
debian/patches/bugfix/all/virtio_net-Make-delayed-refill-more-reliable.patch
vendored
Normal file
|
@ -0,0 +1,50 @@
|
|||
From 39d321577405e8e269fd238b278aaf2425fa788a Mon Sep 17 00:00:00 2001
|
||||
From: Herbert Xu <herbert@gondor.apana.org.au>
|
||||
Date: Mon, 25 Jan 2010 15:51:01 -0800
|
||||
Subject: [PATCH] virtio_net: Make delayed refill more reliable
|
||||
|
||||
I have seen RX stalls on a machine that experienced a suspected
|
||||
OOM. After the stall, the RX buffer is empty on the guest side
|
||||
and there are exactly 16 entries available on the host side. As
|
||||
the number of entries is less than that required by a maximal
|
||||
skb, the host cannot proceed.
|
||||
|
||||
The guest did not have a refill job scheduled.
|
||||
|
||||
My diagnosis is that an OOM had occured, with the delayed refill
|
||||
job scheduled. The job was able to allocate at least one skb, but
|
||||
not enough to overcome the minimum required by the host to proceed.
|
||||
|
||||
As the refill job would only reschedule itself if it failed completely
|
||||
to allocate any skbs, this would lead to an RX stall.
|
||||
|
||||
The following patch removes this stall possibility by always
|
||||
rescheduling the refill job until the ring is totally refilled.
|
||||
|
||||
Testing has shown that the RX stall no longer occurs whereas
|
||||
previously it would occur within a day.
|
||||
|
||||
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
|
||||
Acked-by: Rusty Russell <rusty@rustcorp.com.au>
|
||||
Signed-off-by: David S. Miller <davem@davemloft.net>
|
||||
---
|
||||
drivers/net/virtio_net.c | 3 +--
|
||||
1 files changed, 1 insertions(+), 2 deletions(-)
|
||||
|
||||
diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
|
||||
index c708ecc..9ead30b 100644
|
||||
--- a/drivers/net/virtio_net.c
|
||||
+++ b/drivers/net/virtio_net.c
|
||||
@@ -395,8 +395,7 @@ static void refill_work(struct work_struct *work)
|
||||
|
||||
vi = container_of(work, struct virtnet_info, refill.work);
|
||||
napi_disable(&vi->napi);
|
||||
- try_fill_recv(vi, GFP_KERNEL);
|
||||
- still_empty = (vi->num == 0);
|
||||
+ still_empty = !try_fill_recv(vi, GFP_KERNEL);
|
||||
napi_enable(&vi->napi);
|
||||
|
||||
/* In theory, this can happen: if we don't get any buffers in
|
||||
--
|
||||
1.7.0.3
|
||||
|
|
@ -58,3 +58,4 @@
|
|||
+ bugfix/all/ext4-issue-discard-operation-before-releasing-blocks.patch
|
||||
+ bugfix/all/libiscsi-regression-fix-header-digest-errors.patch
|
||||
+ bugfix/all/revert-percpu-stable-changes.patch
|
||||
+ bugfix/all/virtio_net-Make-delayed-refill-more-reliable.patch
|
||||
|
|
Loading…
Reference in New Issue