Thread (15 messages) 15 messages, 3 authors, 2011-12-22

Re: [PATCH RFC] virtio_net: fix refill related races

From: "Michael S. Tsirkin" <mst@redhat.com>
Date: 2011-12-20 19:07:24
Also in: lkml, netdev

On Tue, Dec 13, 2011 at 01:05:11PM +1030, Rusty Russell wrote:
On Mon, 12 Dec 2011 13:54:06 +0200, "Michael S. Tsirkin" [off-list ref] wrote:
quoted
On Mon, Dec 12, 2011 at 09:25:07AM +1030, Rusty Russell wrote:
quoted
Orthogonally, the refill-stop code is still buggy, as you noted.
Sorry I don't understand how it's still buggy.
Both places where we call:

	cancel_delayed_work_sync(&vi->refill);

Do not actually guarantee that vi->refill isn't running, because it
can requeue itself.  A 'bool no_more_refill' field seems like the
simplest fix for this, but I don't think it's sufficient.

Tejun, is this correct?  What's the correct way to synchronously stop a
delayed_work which can "schedule_delayed_work(&vi->refill, HZ/2);" on
itself?

Thanks,
Rusty.
Another question, wanted to make sure:
virtnet_poll does schedule_delayed_work(&vi->refill, 0);
separately refill work itself also does
schedule_delayed_work(&vi->refill, HZ/2);
If two such events happen twice, on different CPUs, we are still guaranteed
the work will only run once, right?
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help