linux-toradex.git/drivers/net/virtio_net.c, branch v3.12.47

virtio-net: alloc big buffers also when guest can receive UFO

2014-03-13T22:19:39+00:00

[ Upstream commit 0e7ede80d929ff0f830c44a543daa1acd590c749 ]

We should alloc big buffers also when guest can receive UFO
packets to let the big packets fit into guest rx buffer.

Fixes 5c5167515d80f78f6bb538492c423adcae31ad65
(virtio-net: Allow UFO feature to be set and advertised.)

Cc: Rusty Russell 
Cc: Michael S. Tsirkin 
Cc: Sridhar Samudrala 
Signed-off-by: Jason Wang 
Acked-by: Michael S. Tsirkin 
Acked-by: Rusty Russell 
Signed-off-by: David S. Miller 
Signed-off-by: Jiri Slaby

virtio-net: fix refill races during restore

2014-01-15T23:31:38+00:00

[ Upstream commit 6cd4ce0099da7702f885b6fa9ebb49e3831d90b4 ]

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 
Cc: Rusty Russell 
Cc: Michael S. Tsirkin 
Cc: Eric Dumazet 
Signed-off-by: Jason Wang 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

virtio_net: don't leak memory or block when too many frags

2014-01-15T23:31:37+00:00

We leak an skb when there are too many frags,
we also stop processing the packet in the middle,
the result is almost sure to be loss of networking.

Reported-by: Michael Dalton 
Acked-by: Michael Dalton 
Signed-off-by: Michael S. Tsirkin 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

virtio-net: make all RX paths handle errors consistently

2014-01-15T23:31:37+00:00

receive mergeable now handles errors internally.
Do same for big and small packet paths, otherwise
the logic is too hard to follow.

Cc: Jason Wang 
Cc: David S. Miller 
Acked-by: Michael Dalton 
Signed-off-by: Michael S. Tsirkin 

(cherry picked from commit f121159d72091f25afb22007c833e60a6845e912)
Acked-by: Jason Wang 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

virtio_net: fix error handling for mergeable buffers

2014-01-15T23:31:37+00:00

Eric Dumazet noticed that if we encounter an error
when processing a mergeable buffer, we don't
dequeue all of the buffers from this packet,
the result is almost sure to be loss of networking.

Fix this issue.

Cc: Rusty Russell 
Cc: Michael Dalton 
Acked-by: Michael Dalton 
Cc: Eric Dumazet 
Cc: Jason Wang 
Cc: David S. Miller 

Signed-off-by: Michael S. Tsirkin 

(cherry picked from commit 8fc3b9e9a229778e5af3aa453c44f1a3857ba769)
Acked-by: Jason Wang 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

virtio: delete napi structures from netdev before releasing memory

2014-01-15T23:31:33+00:00

[ Upstream commit d4fb84eefe5164f6a6ea51d0a9e26280c661a0dd ]

free_netdev calls netif_napi_del too, but it's too late, because napi
structures are placed on vi->rq. netif_napi_add() is called from
virtnet_alloc_queues.

general protection fault: 0000 [#1] SMP
Dumping ftrace buffer:
   (ftrace buffer empty)
Modules linked in: ip6table_filter ip6_tables iptable_filter ip_tables virtio_balloon pcspkr virtio_net(-) i2c_pii
CPU: 1 PID: 347 Comm: rmmod Not tainted 3.13.0-rc2+ #171
Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
task: ffff8800b779c420 ti: ffff8800379e0000 task.ti: ffff8800379e0000
RIP: 0010:[]  [] __list_del_entry+0x29/0xd0
RSP: 0018:ffff8800379e1dd0  EFLAGS: 00010a83
RAX: 6b6b6b6b6b6b6b6b RBX: ffff8800379c2fd0 RCX: dead000000200200
RDX: 6b6b6b6b6b6b6b6b RSI: 0000000000000001 RDI: ffff8800379c2fd0
RBP: ffff8800379e1dd0 R08: 0000000000000001 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000001 R12: ffff8800379c2f90
R13: ffff880037839160 R14: 0000000000000000 R15: 00000000013352f0
FS:  00007f1400e34740(0000) GS:ffff8800bfb00000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: 00007f464124c763 CR3: 00000000b68cf000 CR4: 00000000000006e0
Stack:
 ffff8800379e1df0 ffffffff8155beab 6b6b6b6b6b6b6b2b ffff8800378391c0
 ffff8800379e1e18 ffffffff8156499b ffff880037839be0 ffff880037839d20
 ffff88003779d3f0 ffff8800379e1e38 ffffffffa003477c ffff88003779d388
Call Trace:
 [] netif_napi_del+0x1b/0x80
 [] free_netdev+0x8b/0x110
 [] virtnet_remove+0x7c/0x90 [virtio_net]
 [] virtio_dev_remove+0x23/0x80
 [] __device_release_driver+0x7f/0xf0
 [] driver_detach+0xc0/0xd0
 [] bus_remove_driver+0x58/0xd0
 [] driver_unregister+0x2c/0x50
 [] unregister_virtio_driver+0xe/0x10
 [] virtio_net_driver_exit+0x10/0x6ce [virtio_net]
 [] SyS_delete_module+0x172/0x220
 [] ? trace_hardirqs_on+0xd/0x10
 [] ? __audit_syscall_entry+0x9c/0xf0
 [] system_call_fastpath+0x16/0x1b
Code: 00 00 55 48 8b 17 48 b9 00 01 10 00 00 00 ad de 48 8b 47 08 48 89 e5 48 39 ca 74 29 48 b9 00 02 20 00 00 00
RIP  [] __list_del_entry+0x29/0xd0
 RSP 
---[ end trace d5931cd3f87c9763 ]---

Fixes: 986a4f4d452d (virtio_net: multiqueue support)
Cc: Rusty Russell 
Cc: "Michael S. Tsirkin" 
Signed-off-by: Andrey Vagin 
Acked-by: Michael S. Tsirkin 
Acked-by: Jason Wang 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

virtio-net: correctly handle cpu hotplug notifier during resuming

2013-11-20T20:37:36+00:00

[ Upstream commit ec9debbd9a88d8ea86c488d6ffcac419ee7d46d9 ]

commit 3ab098df35f8b98b6553edc2e40234af512ba877 (virtio-net: don't respond to
cpu hotplug notifier if we're not ready) tries to bypass the cpu hotplug
notifier by checking the config_enable and does nothing is it was false. So it
need to try to hold the config_lock mutex which may happen in atomic
environment which leads the following warnings:

[  622.944441] CPU0 attaching NULL sched-domain.
[  622.944446] CPU1 attaching NULL sched-domain.
[  622.944485] CPU0 attaching NULL sched-domain.
[  622.950795] BUG: sleeping function called from invalid context at kernel/mutex.c:616
[  622.950796] in_atomic(): 1, irqs_disabled(): 1, pid: 10, name: migration/1
[  622.950796] no locks held by migration/1/10.
[  622.950798] CPU: 1 PID: 10 Comm: migration/1 Not tainted 3.12.0-rc5-wl-01249-gb91e82d #317
[  622.950799] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
[  622.950802]  0000000000000000 ffff88001d42dba0 ffffffff81a32f22 ffff88001bfb9c70
[  622.950803]  ffff88001d42dbb0 ffffffff810edb02 ffff88001d42dc38 ffffffff81a396ed
[  622.950805]  0000000000000046 ffff88001d42dbe8 ffffffff810e861d 0000000000000000
[  622.950805] Call Trace:
[  622.950810]  [] dump_stack+0x54/0x74
[  622.950815]  [] __might_sleep+0x112/0x114
[  622.950817]  [] mutex_lock_nested+0x3c/0x3c6
[  622.950818]  [] ? up+0x39/0x3e
[  622.950821]  [] ? acpi_os_signal_semaphore+0x21/0x2d
[  622.950824]  [] ? acpi_ut_release_mutex+0x5e/0x62
[  622.950828]  [] virtnet_cpu_callback+0x33/0x87
[  622.950830]  [] notifier_call_chain+0x3c/0x5e
[  622.950832]  [] __raw_notifier_call_chain+0xe/0x10
[  622.950835]  [] __cpu_notify+0x20/0x37
[  622.950836]  [] cpu_notify+0x13/0x15
[  622.950838]  [] take_cpu_down+0x27/0x3a
[  622.950841]  [] stop_machine_cpu_stop+0x93/0xf1
[  622.950842]  [] cpu_stopper_thread+0xa0/0x12f
[  622.950844]  [] ? cpu_stopper_thread+0x12f/0x12f
[  622.950847]  [] ? lock_release_holdtime.part.7+0xa3/0xa8
[  622.950848]  [] ? cpu_stop_should_run+0x3f/0x47
[  622.950850]  [] smpboot_thread_fn+0x1c5/0x1e3
[  622.950852]  [] ? lg_global_unlock+0x67/0x67
[  622.950854]  [] kthread+0xd8/0xe0
[  622.950857]  [] ? wait_for_common+0x12f/0x164
[  622.950859]  [] ? kthread_create_on_node+0x124/0x124
[  622.950861]  [] ret_from_fork+0x7c/0xb0
[  622.950862]  [] ? kthread_create_on_node+0x124/0x124
[  622.950876] smpboot: CPU 1 is now offline
[  623.194556] SMP alternatives: lockdep: fixing up alternatives
[  623.194559] smpboot: Booting Node 0 Processor 1 APIC 0x1
...

A correct fix is to unregister the hotcpu notifier during restore and register a
new one in resume.

Reported-by: Fengguang Wu 
Tested-by: Fengguang Wu 
Cc: Wanlong Gao 
Cc: Rusty Russell 
Cc: Michael S. Tsirkin 
Signed-off-by: Jason Wang 
Acked-by: Michael S. Tsirkin 
Reviewed-by: Wanlong Gao 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

virtio-net: refill only when device is up during setting queues

2013-10-17T19:53:09+00:00

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: fix the race between channels setting and refill)

Cc: Rusty Russell 
Cc: Michael S. Tsirkin 
Signed-off-by: Jason Wang 
Signed-off-by: David S. Miller

virtio-net: don't respond to cpu hotplug notifier if we're not ready

2013-10-17T19:53:09+00:00

We're trying to re-configure the affinity unconditionally in cpu hotplug
callback. This may lead the issue during resuming from s3/s4 since

- virt queues haven't been allocated at that time.
- it's unnecessary since thaw method will re-configure the affinity.

Fix this issue by checking the config_enable and do nothing is we're not ready.

The bug were introduced by commit 8de4b2f3ae90c8fc0f17eeaab87d5a951b66ee17
(virtio-net: reset virtqueue affinity when doing cpu hotplug).

Cc: Rusty Russell 
Cc: Michael S. Tsirkin 
Cc: Wanlong Gao 
Acked-by: Michael S. Tsirkin 
Reviewed-by: Wanlong Gao 
Signed-off-by: Jason Wang 
Signed-off-by: David S. Miller

virtio-net: Set RXCSUM feature if GUEST_CSUM is available

2013-09-04T01:36:41+00:00

If the VIRTIO_NET_F_GUEST_CSUM virtio feature is available, the guest
does not have to calculate the checksums on all received packets. This
is pretty much the same feature as RX checksum offloading on real
network cards, so the virtio-net driver should report this by setting
the NETIF_F_RXCSUM flag. When the user now runs "ethtool -k", he or she
can see whether the virtio-net interface has to calculate RX checksums
or not.

Signed-off-by: Thomas Huth 
Acked-by: Rusty Russell 
Signed-off-by: David S. Miller