From: Jason Wang
Date: Thu, 20 Nov 2014 17:03:05 +0800
> We currently trigger BUG when VIRTIO_NET_F_CTRL_VQ
> is not set but one of features depending on it is.
> That's not a friendly way to report errors to
> hypervisors.
> Let's check, and fail probe instead.
>
> Cc: Rusty Russell
> Cc: Corn
On 11/19/2014 05:14 PM, Michael S. Tsirkin wrote:
> On Thu, Oct 30, 2014 at 06:27:12PM +, Ben Hutchings wrote:
>> > IPv6 does not allow fragmentation by routers, so there is no
>> > fragmentation ID in the fixed header. UFO for IPv6 requires the ID to
>> > be passed separately, but there is no
On Thu 2014-11-20 19:00:16, Michael S. Tsirkin wrote:
> On Thu, Nov 20, 2014 at 05:55:58PM +0100, Petr Mladek wrote:
> > On Thu 2014-11-20 11:29:35, Tejun Heo wrote:
> > > On Thu, Nov 20, 2014 at 06:26:24PM +0200, Michael S. Tsirkin wrote:
> > > > On Thu, Nov 20, 2014 at 06:25:43PM +0200, Michael S
On Thu, Nov 20, 2014 at 05:55:58PM +0100, Petr Mladek wrote:
> On Thu 2014-11-20 11:29:35, Tejun Heo wrote:
> > On Thu, Nov 20, 2014 at 06:26:24PM +0200, Michael S. Tsirkin wrote:
> > > On Thu, Nov 20, 2014 at 06:25:43PM +0200, Michael S. Tsirkin wrote:
> > > > On Thu, Nov 20, 2014 at 11:07:46AM -0
On Thu 2014-11-20 11:29:35, Tejun Heo wrote:
> On Thu, Nov 20, 2014 at 06:26:24PM +0200, Michael S. Tsirkin wrote:
> > On Thu, Nov 20, 2014 at 06:25:43PM +0200, Michael S. Tsirkin wrote:
> > > On Thu, Nov 20, 2014 at 11:07:46AM -0500, Tejun Heo wrote:
> > > > On Thu, Nov 20, 2014 at 05:03:17PM +010
On Thu, Nov 20, 2014 at 11:49:33AM -0500, Tejun Heo wrote:
> On Thu, Nov 20, 2014 at 06:47:11PM +0200, Michael S. Tsirkin wrote:
> > > There's cancel_work_sync() to stop the self-requeueing ones.
> >
> > What happens if queue_work runs while cancel_work_sync is in progress?
> > Does it fail to que
On Thu, Nov 20, 2014 at 11:49:33AM -0500, Tejun Heo wrote:
> On Thu, Nov 20, 2014 at 06:47:11PM +0200, Michael S. Tsirkin wrote:
> > > There's cancel_work_sync() to stop the self-requeueing ones.
> >
> > What happens if queue_work runs while cancel_work_sync is in progress?
> > Does it fail to que
On Thu, Nov 20, 2014 at 06:47:11PM +0200, Michael S. Tsirkin wrote:
> > There's cancel_work_sync() to stop the self-requeueing ones.
>
> What happens if queue_work runs while cancel_work_sync is in progress?
> Does it fail to queue?
cancel_work_sync() is guaranteed to take self-requeueing work it
On Thu, Nov 20, 2014 at 11:29:35AM -0500, Tejun Heo wrote:
> On Thu, Nov 20, 2014 at 06:26:24PM +0200, Michael S. Tsirkin wrote:
> > On Thu, Nov 20, 2014 at 06:25:43PM +0200, Michael S. Tsirkin wrote:
> > > On Thu, Nov 20, 2014 at 11:07:46AM -0500, Tejun Heo wrote:
> > > > On Thu, Nov 20, 2014 at 0
On Thu, Nov 20, 2014 at 06:26:24PM +0200, Michael S. Tsirkin wrote:
> On Thu, Nov 20, 2014 at 06:25:43PM +0200, Michael S. Tsirkin wrote:
> > On Thu, Nov 20, 2014 at 11:07:46AM -0500, Tejun Heo wrote:
> > > On Thu, Nov 20, 2014 at 05:03:17PM +0100, Petr Mladek wrote:
> > > ...
> > > > @@ -476,7 +46
On Thu, Nov 20, 2014 at 06:25:43PM +0200, Michael S. Tsirkin wrote:
> On Thu, Nov 20, 2014 at 11:07:46AM -0500, Tejun Heo wrote:
> > On Thu, Nov 20, 2014 at 05:03:17PM +0100, Petr Mladek wrote:
> > ...
> > > @@ -476,7 +460,6 @@ static void virtballoon_remove(struct virtio_device
> > > *vdev)
> > >
On Thu, Nov 20, 2014 at 11:07:46AM -0500, Tejun Heo wrote:
> On Thu, Nov 20, 2014 at 05:03:17PM +0100, Petr Mladek wrote:
> ...
> > @@ -476,7 +460,6 @@ static void virtballoon_remove(struct virtio_device
> > *vdev)
> > {
> > struct virtio_balloon *vb = vdev->priv;
> >
> > - kthread_stop(v
On Thu, Nov 20, 2014 at 05:03:17PM +0100, Petr Mladek wrote:
...
> @@ -476,7 +460,6 @@ static void virtballoon_remove(struct virtio_device *vdev)
> {
> struct virtio_balloon *vb = vdev->priv;
>
> - kthread_stop(vb->thread);
> remove_common(vb);
> kfree(vb);
> }
Shouldn't
Workqueues have clean and rich API for all basic operations. The code is usually
easier and better readable. It can be easily tuned for the given purpose.
In many cases, it allows to avoid an extra kernel thread. It helps to stop the
growing number of them. Also there will be less thread-specific
On Thu, Nov 20, 2014 at 05:03:05PM +0800, Jason Wang wrote:
> We currently trigger BUG when VIRTIO_NET_F_CTRL_VQ
> is not set but one of features depending on it is.
> That's not a friendly way to report errors to
> hypervisors.
> Let's check, and fail probe instead.
>
> Cc: Rusty Russell
> Cc: C
On 11/20/2014 05:48 PM, Cornelia Huck wrote:
> On Thu, 20 Nov 2014 17:03:05 +0800
> Jason Wang wrote:
>
>> We currently trigger BUG when VIRTIO_NET_F_CTRL_VQ
>> is not set but one of features depending on it is.
>> That's not a friendly way to report errors to
>> hypervisors.
>> Let's check, and f
On Thu, 20 Nov 2014 17:03:05 +0800
Jason Wang wrote:
> We currently trigger BUG when VIRTIO_NET_F_CTRL_VQ
> is not set but one of features depending on it is.
> That's not a friendly way to report errors to
> hypervisors.
> Let's check, and fail probe instead.
>
> Cc: Rusty Russell
> Cc: Cornel
We currently trigger BUG when VIRTIO_NET_F_CTRL_VQ
is not set but one of features depending on it is.
That's not a friendly way to report errors to
hypervisors.
Let's check, and fail probe instead.
Cc: Rusty Russell
Cc: Cornelia Huck
Cc: Wanlong Gao
Signed-off-by: Michael S. Tsirkin
Signed-off
On 11/20/2014 04:27 PM, Jason Wang wrote:
> We currently trigger BUG when VIRTIO_NET_F_CTRL_VQ
> is not set but one of features depending on it is.
> That's not a friendly way to report errors to
> hypervisors.
> Let's check, and fail probe instead.
>
> Cc: Rusty Russell
> Cc: Cornelia Huck
> Cc:
We currently trigger BUG when VIRTIO_NET_F_CTRL_VQ
is not set but one of features depending on it is.
That's not a friendly way to report errors to
hypervisors.
Let's check, and fail probe instead.
Cc: Rusty Russell
Cc: Cornelia Huck
Cc: Wanlong Gao
Signed-off-by: Michael S. Tsirkin
Signed-off
20 matches
Mail list logo
