On 10/20/2013 10:34 AM, Fengguang Wu wrote:
> Greetings,
>
> I got the below dmesg and the first bad commit is
>
> commit 3ab098df35f8b98b6553edc2e40234af512ba877
> Author: Jason Wang <jasowang@redhat.com>
> Date:   Tue Oct 15 11:18:58 2013 +0800
>
>     virtio-net: don't respond to cpu hotplug notifier if we're not ready
>     
>     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 <rusty@rustcorp.com.au>
>     Cc: Michael S. Tsirkin <mst@redhat.com>
>     Cc: Wanlong Gao <gaowanlong@cn.fujitsu.com>
>     Acked-by: Michael S. Tsirkin <mst@redhat.com>
>     Reviewed-by: Wanlong Gao <gaowanlong@cn.fujitsu.com>
>     Signed-off-by: Jason Wang <jasowang@redhat.com>
>     Signed-off-by: David S. Miller <davem@davemloft.net>
>
> [  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]  [<ffffffff81a32f22>] dump_stack+0x54/0x74
> [  622.950815]  [<ffffffff810edb02>] __might_sleep+0x112/0x114
> [  622.950817]  [<ffffffff81a396ed>] mutex_lock_nested+0x3c/0x3c6
> [  622.950818]  [<ffffffff810e861d>] ? up+0x39/0x3e
> [  622.950821]  [<ffffffff8153ea7c>] ? acpi_os_signal_semaphore+0x21/0x2d
> [  622.950824]  [<ffffffff81565ed1>] ? acpi_ut_release_mutex+0x5e/0x62
> [  622.950828]  [<ffffffff816d04ec>] virtnet_cpu_callback+0x33/0x87
> [  622.950830]  [<ffffffff81a42576>] notifier_call_chain+0x3c/0x5e
> [  622.950832]  [<ffffffff810e86a8>] __raw_notifier_call_chain+0xe/0x10
> [  622.950835]  [<ffffffff810c5556>] __cpu_notify+0x20/0x37
> [  622.950836]  [<ffffffff810c5580>] cpu_notify+0x13/0x15
> [  622.950838]  [<ffffffff81a237cd>] take_cpu_down+0x27/0x3a
> [  622.950841]  [<ffffffff81136289>] stop_machine_cpu_stop+0x93/0xf1
> [  622.950842]  [<ffffffff81136167>] cpu_stopper_thread+0xa0/0x12f
> [  622.950844]  [<ffffffff811361f6>] ? cpu_stopper_thread+0x12f/0x12f
> [  622.950847]  [<ffffffff81119710>] ? lock_release_holdtime.part.7+0xa3/0xa8
> [  622.950848]  [<ffffffff81135e4b>] ? cpu_stop_should_run+0x3f/0x47
> [  622.950850]  [<ffffffff810ea9b0>] smpboot_thread_fn+0x1c5/0x1e3
> [  622.950852]  [<ffffffff810ea7eb>] ? lg_global_unlock+0x67/0x67
> [  622.950854]  [<ffffffff810e36b7>] kthread+0xd8/0xe0
> [  622.950857]  [<ffffffff81a3bfad>] ? wait_for_common+0x12f/0x164
> [  622.950859]  [<ffffffff810e35df>] ? kthread_create_on_node+0x124/0x124
> [  622.950861]  [<ffffffff81a45ffc>] ret_from_fork+0x7c/0xb0
> [  622.950862]  [<ffffffff810e35df>] ? 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
 
Thanks for the testing Fengguang, could you please try the attached
patch to see if it works?