search for: refills

Displaying 20 results from an estimated 845 matches for "refills".

Did you mean: refill
2013 Jul 03
4
[PATCH net] virtio-net: fix the race between channels setting and refill
Commit 55257d72bd1c51f25106350f4983ec19f62ed1fa (virtio-net: fill only rx queues which are being used) tries to refill on demand when changing the number of channels by call try_refill_recv() directly, this may race: - the refill work who may do the refill in the same time - the try_refill_recv() called in bh since napi was not disabled Which may led guest complain during setting channels:
2013 Jul 03
4
[PATCH net] virtio-net: fix the race between channels setting and refill
Commit 55257d72bd1c51f25106350f4983ec19f62ed1fa (virtio-net: fill only rx queues which are being used) tries to refill on demand when changing the number of channels by call try_refill_recv() directly, this may race: - the refill work who may do the refill in the same time - the try_refill_recv() called in bh since napi was not disabled Which may led guest complain during setting channels:
2011 Dec 07
1
[PATCH RFC] virtio_net: fix refill related races
Fix theoretical races related to refill work: 1. After napi is disabled by ndo_stop, refill work can run and re-enable it. 2. Refill can reschedule itself, if this happens it can run after cancel_delayed_work_sync, and will access device after it is destroyed. As a solution, add flags to track napi state and to disable refill, and toggle them on start, stop and remove; check these flags
2011 Dec 07
1
[PATCH RFC] virtio_net: fix refill related races
Fix theoretical races related to refill work: 1. After napi is disabled by ndo_stop, refill work can run and re-enable it. 2. Refill can reschedule itself, if this happens it can run after cancel_delayed_work_sync, and will access device after it is destroyed. As a solution, add flags to track napi state and to disable refill, and toggle them on start, stop and remove; check these flags
2011 Dec 20
0
[PATCH] virtio_net: fix refill related races
...work is cancelled after unregister netdev For small bufs this means it can alloc an skb for a device which is unregistered which is not a good idea. As a solution, add flag to track napi state and toggle it on start/stop check on refill. Add a mutex to pretect the flag, as well as serial refills. Move refill cancellation to after unregister. refill work structure and new fields aren't used on data path, so put them together near the end of struct virtnet_info. TODO: consider using system_nrq_wq as suggested by Tejun Heo. Probably be a good idea but not a must for correctness. Ligh...
2011 Dec 20
0
[PATCH] virtio_net: fix refill related races
...work is cancelled after unregister netdev For small bufs this means it can alloc an skb for a device which is unregistered which is not a good idea. As a solution, add flag to track napi state and toggle it on start/stop check on refill. Add a mutex to pretect the flag, as well as serial refills. Move refill cancellation to after unregister. refill work structure and new fields aren't used on data path, so put them together near the end of struct virtnet_info. TODO: consider using system_nrq_wq as suggested by Tejun Heo. Probably be a good idea but not a must for correctness. Ligh...
2013 Oct 14
1
[PATCH net 2/2] virtio-net: refill only when device is up during setting queues
On Mon, Oct 14, 2013 at 05:56:35PM +0800, Jason Wang wrote: > We used to schedule the refill work unconditionally after changing the > number of queues. This may lead an issue if the device is not > up. Since we only try to cancel the work in ndo_stop(), this may cause > the refill work still work after removing the device. Fix this by only > schedule the work when device is up.
2013 Oct 14
1
[PATCH net 2/2] virtio-net: refill only when device is up during setting queues
On Mon, Oct 14, 2013 at 05:56:35PM +0800, Jason Wang wrote: > We used to schedule the refill work unconditionally after changing the > number of queues. This may lead an issue if the device is not > up. Since we only try to cancel the work in ndo_stop(), this may cause > the refill work still work after removing the device. Fix this by only > schedule the work when device is up.
2010 Jun 03
0
[PATCH 1/3][STABLE] KVM: fix delayed refill checking
Please consider this for the 2.6.32 stable tree: commit 39d321577405e8e269fd238b278aaf2425fa788a Author: Herbert Xu <herbert at gondor.apana.org.au> Date: Mon Jan 25 15:51:01 2010 -0800 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
2010 Jun 03
0
[PATCH 1/3][STABLE] KVM: fix delayed refill checking
Please consider this for the 2.6.32 stable tree: commit 39d321577405e8e269fd238b278aaf2425fa788a Author: Herbert Xu <herbert at gondor.apana.org.au> Date: Mon Jan 25 15:51:01 2010 -0800 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
2013 Oct 14
0
[PATCH net 2/2] virtio-net: refill only when device is up during setting queues
We used to schedule the refill work unconditionally after changing the number of queues. This may lead an issue if the device is not up. Since we only try to cancel the work in ndo_stop(), this may cause the refill work still work after removing the device. Fix this by only schedule the work when device is up. The bug were introduce by commit 9b9cd8024a2882e896c65222aa421d461354e3f2. (virtio-net:
2013 Oct 15
0
[PATCH net V2 2/2] virtio-net: refill only when device is up during setting queues
We used to schedule the refill work unconditionally after changing the number of queues. This may lead an issue if the device is not up. Since we only try to cancel the work in ndo_stop(), this may cause the refill work still work after removing the device. Fix this by only schedule the work when device is up. The bug were introduce by commit 9b9cd8024a2882e896c65222aa421d461354e3f2. (virtio-net:
2013 Dec 26
2
[PATCH net-next 2/3] virtio-net: use per-receive queue page frag alloc for mergeable bufs
On Thu, 2013-12-26 at 13:28 -0800, Michael Dalton wrote: > On Mon, Dec 23, 2013 at 11:37 AM, Michael S. Tsirkin <mst at redhat.com> wrote: > > So there isn't a conflict with respect to locking. > > > > Is it problematic to use same page_frag with both GFP_ATOMIC and with > > GFP_KERNEL? If yes why? > > I believe it is safe to use the same page_frag and I
2013 Dec 26
2
[PATCH net-next 2/3] virtio-net: use per-receive queue page frag alloc for mergeable bufs
On Thu, 2013-12-26 at 13:28 -0800, Michael Dalton wrote: > On Mon, Dec 23, 2013 at 11:37 AM, Michael S. Tsirkin <mst at redhat.com> wrote: > > So there isn't a conflict with respect to locking. > > > > Is it problematic to use same page_frag with both GFP_ATOMIC and with > > GFP_KERNEL? If yes why? > > I believe it is safe to use the same page_frag and I
2012 Apr 04
2
question about napi_disable (was Re: [PATCH] virtio_net: set/cancel work on ndo_open/ndo_stop)
On Thu, Dec 29, 2011 at 09:12:38PM +1030, Rusty Russell wrote: > Michael S. Tsirkin noticed that we could run the refill work after > ndo_close, which can re-enable napi - we don't disable it until > virtnet_remove. This is clearly wrong, so move the workqueue control > to ndo_open and ndo_stop (aka. virtnet_open and virtnet_close). > > One subtle point: virtnet_probe()
2012 Apr 04
2
question about napi_disable (was Re: [PATCH] virtio_net: set/cancel work on ndo_open/ndo_stop)
On Thu, Dec 29, 2011 at 09:12:38PM +1030, Rusty Russell wrote: > Michael S. Tsirkin noticed that we could run the refill work after > ndo_close, which can re-enable napi - we don't disable it until > virtnet_remove. This is clearly wrong, so move the workqueue control > to ndo_open and ndo_stop (aka. virtnet_open and virtnet_close). > > One subtle point: virtnet_probe()
2011 Jul 29
1
[PATCH RFC net-next] virtio_net: refill buffer right after being used
To even the latency, refill buffer right after being used. Sign-off-by: Shirley Ma <xma at us.ibm.com> --- diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c index 0c7321c..c8201d4 100644 --- a/drivers/net/virtio_net.c +++ b/drivers/net/virtio_net.c @@ -429,6 +429,22 @@ static int add_recvbuf_mergeable(struct virtnet_info *vi, gfp_t gfp) return err; } +static bool
2011 Jul 29
1
[PATCH RFC net-next] virtio_net: refill buffer right after being used
To even the latency, refill buffer right after being used. Sign-off-by: Shirley Ma <xma at us.ibm.com> --- diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c index 0c7321c..c8201d4 100644 --- a/drivers/net/virtio_net.c +++ b/drivers/net/virtio_net.c @@ -429,6 +429,22 @@ static int add_recvbuf_mergeable(struct virtnet_info *vi, gfp_t gfp) return err; } +static bool
2013 Dec 30
1
[PATCH net] virtio-net: fix refill races during restore
During restoring, try_fill_recv() was called with neither napi lock nor napi disabled. This can lead two try_fill_recv() was called in the same time. Fix this by refilling before trying to enable napi. Fixes 0741bcb5584f9e2390ae6261573c4de8314999f2 (virtio: net: Add freeze, restore handlers to support S4). Cc: Amit Shah <amit.shah at redhat.com> Cc: Rusty Russell <rusty at
2013 Dec 30
1
[PATCH net] virtio-net: fix refill races during restore
During restoring, try_fill_recv() was called with neither napi lock nor napi disabled. This can lead two try_fill_recv() was called in the same time. Fix this by refilling before trying to enable napi. Fixes 0741bcb5584f9e2390ae6261573c4de8314999f2 (virtio: net: Add freeze, restore handlers to support S4). Cc: Amit Shah <amit.shah at redhat.com> Cc: Rusty Russell <rusty at