Commit 39d32157 authored by Herbert Xu's avatar Herbert Xu Committed by David S. Miller

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: default avatarHerbert Xu <herbert@gondor.apana.org.au>
Acked-by: default avatarRusty Russell <rusty@rustcorp.com.au>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
parent 5a27e86b
...@@ -395,8 +395,7 @@ static void refill_work(struct work_struct *work) ...@@ -395,8 +395,7 @@ static void refill_work(struct work_struct *work)
vi = container_of(work, struct virtnet_info, refill.work); vi = container_of(work, struct virtnet_info, refill.work);
napi_disable(&vi->napi); napi_disable(&vi->napi);
try_fill_recv(vi, GFP_KERNEL); still_empty = !try_fill_recv(vi, GFP_KERNEL);
still_empty = (vi->num == 0);
napi_enable(&vi->napi); napi_enable(&vi->napi);
/* In theory, this can happen: if we don't get any buffers in /* In theory, this can happen: if we don't get any buffers in
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment