linux-toradex.git/drivers/xen/manage.c, branch v4.0-rc1

xen/manage: Fix USB interaction issues when resuming

2015-02-06T15:49:09+00:00

Commit 61a734d305e1 ("xen/manage: Always freeze/thaw processes when
suspend/resuming") ensured that userspace processes were always frozen
before suspending to reduce interaction issues when resuming devices.
However, freeze_processes() does not freeze kernel threads.  Freeze
kernel threads as well to prevent deadlocks with the khubd thread when
resuming devices.

This is what native suspend and resume does.

Example deadlock:
[ 7279.648010]  [] ? xen_poll_irq_timeout+0x3e/0x50
[ 7279.648010]  [] xen_poll_irq+0x10/0x20
[ 7279.648010]  [] xen_lock_spinning+0xb3/0x120
[ 7279.648010]  [] __raw_callee_save_xen_lock_spinning+0x11/0x20
[ 7279.648010]  [] ? usb_control_msg+0xe6/0x120
[ 7279.648010]  [] ? _raw_spin_lock_irq+0x50/0x60
[ 7279.648010]  [] wait_for_completion+0xac/0x160
[ 7279.648010]  [] ? try_to_wake_up+0x2c0/0x2c0
[ 7279.648010]  [] dpm_wait+0x32/0x40
[ 7279.648010]  [] device_resume+0x90/0x210
[ 7279.648010]  [] dpm_resume+0x121/0x250
[ 7279.648010]  [] ? xenbus_dev_request_and_reply+0xc0/0xc0
[ 7279.648010]  [] dpm_resume_end+0x15/0x30
[ 7279.648010]  [] do_suspend+0x10a/0x200
[ 7279.648010]  [] ? xen_pre_suspend+0x20/0x20
[ 7279.648010]  [] shutdown_handler+0x120/0x150
[ 7279.648010]  [] xenwatch_thread+0x9f/0x160
[ 7279.648010]  [] ? finish_wait+0x80/0x80
[ 7279.648010]  [] kthread+0xc9/0xe0
[ 7279.648010]  [] ? flush_kthread_worker+0x80/0x80
[ 7279.648010]  [] ret_from_fork+0x7c/0xb0
[ 7279.648010]  [] ? flush_kthread_worker+0x80/0x80

[ 7441.216287] INFO: task khubd:89 blocked for more than 120 seconds.
[ 7441.219457]       Tainted: G            X 3.13.11-ckt12.kz #1
[ 7441.222176] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[ 7441.225827] khubd           D ffff88003f433440     0    89      2 0x00000000
[ 7441.229258]  ffff88003ceb9b98 0000000000000046 ffff88003ce83000 0000000000013440
[ 7441.232959]  ffff88003ceb9fd8 0000000000013440 ffff88003cd13000 ffff88003ce83000
[ 7441.236658]  0000000000000286 ffff88003d3e0000 ffff88003ceb9bd0 00000001001aa01e
[ 7441.240415] Call Trace:
[ 7441.241614]  [] schedule+0x29/0x70
[ 7441.243930]  [] schedule_timeout+0x166/0x2c0
[ 7441.246681]  [] ? call_timer_fn+0x110/0x110
[ 7441.249339]  [] schedule_timeout_uninterruptible+0x1e/0x20
[ 7441.252644]  [] msleep+0x20/0x30
[ 7441.254812]  [] hub_port_reset+0xf0/0x580
[ 7441.257400]  [] hub_port_init+0x75/0xb40
[ 7441.259981]  [] ? update_autosuspend+0x39/0x60
[ 7441.262817]  [] ? pm_runtime_set_autosuspend_delay+0x50/0xa0
[ 7441.266212]  [] hub_thread+0x71a/0x1750
[ 7441.268728]  [] ? finish_wait+0x80/0x80
[ 7441.271272]  [] ? usb_port_resume+0x670/0x670
[ 7441.274067]  [] kthread+0xc9/0xe0
[ 7441.276305]  [] ? flush_kthread_worker+0x80/0x80
[ 7441.279131]  [] ret_from_fork+0x7c/0xb0
[ 7441.281659]  [] ? flush_kthread_worker+0x80/0x80

Signed-off-by: Ross Lagerwall 
Cc: stable@vger.kernel.org
Signed-off-by: David Vrabel

xen/manage: Always freeze/thaw processes when suspend/resuming

2014-09-02T14:36:59+00:00

Always freeze processes when suspending and thaw processes when resuming
to prevent a race noticeable with HVM guests.

This prevents a deadlock where the khubd kthread (which is designed to
be freezable) acquires a usb device lock and then tries to allocate
memory which requires the disk which hasn't been resumed yet.
Meanwhile, the xenwatch thread deadlocks waiting for the usb device
lock.

Freezing processes fixes this because the khubd thread is only thawed
after the xenwatch thread finishes resuming all the devices.

Signed-off-by: Ross Lagerwall 
Signed-off-by: David Vrabel 
Cc: stable@vger.kernel.org

xen/manage: fix potential deadlock when resuming the console

2014-07-03T10:02:28+00:00

Calling xen_console_resume() in xen_suspend() causes a warning because
it locks irq_mapping_update_lock (a mutex) and this may sleep.  If a
userspace process is using the evtchn device then this mutex may be
locked at the point of the stop_machine() call and
xen_console_resume() would then deadlock.

Resuming the console after stop_machine() returns avoids this
deadlock.

Signed-off-by: David Vrabel 
Reviewed-by: Boris Ostrovsky 
Cc:

xen: refactor suspend pre/post hooks

2014-05-12T16:19:56+00:00

New architectures currently have to provide implementations of 5 different
functions: xen_arch_pre_suspend(), xen_arch_post_suspend(),
xen_arch_hvm_post_suspend(), xen_mm_pin_all(), and xen_mm_unpin_all().

Refactor the suspend code to only require xen_arch_pre_suspend() and
xen_arch_post_suspend().

Signed-off-by: David Vrabel 
Reviewed-by: Boris Ostrovsky

xen/manage: Poweroff forcefully if user-space is not yet up.

2014-04-15T16:41:29+00:00

The user can launch the guest in this sequence:

xl create -p /vm.cfg	[launch, but pause it]
xl shutdown latest	[sets control/shutdown=poweroff]
xl unpause latest
xl console latest	[and see that the guest has completely
ignored the shutdown request]

In reality the guest hasn't ignored it. It registers a watch
and gets a notification that there is value. It then calls
the shutdown_handler which ends up calling orderly_shutdown.

Unfortunately that is so early in the bootup that there
are no user-space. Which means that the orderly_shutdown fails.
But since the force flag was set to false it continues on without
reporting.

What we really want to is to use the force when we are in the
SYSTEM_BOOTING state and not use the 'force' when SYSTEM_RUNNING.

However, if we are in the running state - and the shutdown command
has been given before the user-space has been setup, there is nothing
we can do. Worst yet, we stop ignoring the 'xl shutdown' requests!

As such, the other part of this patch is to only stop ignoring
the 'xl shutdown' when we are truly in the power off sequence.

That means the user can do multiple 'xl shutdown' and we will try
to act on them instead of ignoring them.

Fixes-Bug: http://bugs.xenproject.org/xen/bug/6
Reported-by:  Alex Bligh 
Signed-off-by: Konrad Rzeszutek Wilk 
Signed-off-by: David Vrabel

xen/acpi-processor: fix enabling interrupts on syscore_resume

2014-03-18T14:40:20+00:00

syscore->resume() callback is expected to do not enable interrupts,
it generates warning like below otherwise:

[ 9386.365390] WARNING: CPU: 0 PID: 6733 at drivers/base/syscore.c:104 syscore_resume+0x9a/0xe0()
[ 9386.365403] Interrupts enabled after xen_acpi_processor_resume+0x0/0x34 [xen_acpi_processor]
...
[ 9386.365429] Call Trace:
[ 9386.365434]  [] dump_stack+0x45/0x56
[ 9386.365437]  [] warn_slowpath_common+0x7d/0xa0
[ 9386.365439]  [] warn_slowpath_fmt+0x4c/0x50
[ 9386.365442]  [] ? xen_upload_processor_pm_data+0x300/0x300 [xen_acpi_processor]
[ 9386.365443]  [] syscore_resume+0x9a/0xe0
[ 9386.365445]  [] suspend_devices_and_enter+0x402/0x470
[ 9386.365447]  [] pm_suspend+0x178/0x260

On xen_acpi_processor_resume() we call various procedures, which are
non atomic and can enable interrupts. To prevent the issue introduce
separate resume notify called after we enable interrupts on resume
and before we call other drivers resume callbacks.

Signed-off-by: Stanislaw Gruszka 
Signed-off-by: Konrad Rzeszutek Wilk

Merge branch 'timers-core-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip

2013-07-06T21:09:38+00:00

Pull timer core updates from Thomas Gleixner:
 "The timer changes contain:

   - posix timer code consolidation and fixes for odd corner cases

   - sched_clock implementation moved from ARM to core code to avoid
     duplication by other architectures

   - alarm timer updates

   - clocksource and clockevents unregistration facilities

   - clocksource/events support for new hardware

   - precise nanoseconds RTC readout (Xen feature)

   - generic support for Xen suspend/resume oddities

   - the usual lot of fixes and cleanups all over the place

  The parts which touch other areas (ARM/XEN) have been coordinated with
  the relevant maintainers.  Though this results in an handful of
  trivial to solve merge conflicts, which we preferred over nasty cross
  tree merge dependencies.

  The patches which have been committed in the last few days are bug
  fixes plus the posix timer lot.  The latter was in akpms queue and
  next for quite some time; they just got forgotten and Frederic
  collected them last minute."

* 'timers-core-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: (59 commits)
  hrtimer: Remove unused variable
  hrtimers: Move SMP function call to thread context
  clocksource: Reselect clocksource when watchdog validated high-res capability
  posix-cpu-timers: don't account cpu timer after stopped thread runtime accounting
  posix_timers: fix racy timer delta caching on task exit
  posix-timers: correctly get dying task time sample in posix_cpu_timer_schedule()
  selftests: add basic posix timers selftests
  posix_cpu_timers: consolidate expired timers check
  posix_cpu_timers: consolidate timer list cleanups
  posix_cpu_timer: consolidate expiry time type
  tick: Sanitize broadcast control logic
  tick: Prevent uncontrolled switch to oneshot mode
  tick: Make oneshot broadcast robust vs. CPU offlining
  x86: xen: Sync the CMOS RTC as well as the Xen wallclock
  x86: xen: Sync the wallclock when the system time is set
  timekeeping: Indicate that clock was set in the pvclock gtod notifier
  timekeeping: Pass flags instead of multiple bools to timekeeping_update()
  xen: Remove clock_was_set() call in the resume path
  hrtimers: Support resuming with two or more CPUs online (but stopped)
  timer: Fix jiffies wrap behavior of round_jiffies_common()
  ...

xen: Remove clock_was_set() call in the resume path

2013-06-28T21:15:06+00:00

commit 359cdd3f866(xen: maintain clock offset over save/restore) added
a clock_was_set() call into the xen resume code to propagate the
system time changes. With the modified hrtimer resume code, which
makes sure that all cpus are notified this call is not longer necessary.

[ tglx: Separated it from the hrtimer change ]

Signed-off-by: David Vrabel 
Cc: Konrad Rzeszutek Wilk  
Cc: John Stultz  
Cc: 
Link: http://lkml.kernel.org/r/1372329348-20841-2-git-send-email-david.vrabel@citrix.com
Signed-off-by: Thomas Gleixner

xen: Convert printks to pr_

2013-06-28T15:19:58+00:00

Convert printks to pr_ (excludes printk(KERN_DEBUG...)
to be more consistent throughout the xen subsystem.

Add pr_fmt with KBUILD_MODNAME or "xen:" KBUILD_MODNAME
Coalesce formats and add missing word spaces
Add missing newlines
Align arguments and reflow to 80 columns
Remove DRV_NAME from formats as pr_fmt adds the same content

This does change some of the prefixes of these messages
but it also does make them more consistent.

Signed-off-by: Joe Perches 
Signed-off-by: Konrad Rzeszutek Wilk

xen: ifdef CONFIG_HIBERNATE_CALLBACKS xen_*_suspend

2013-06-28T15:19:50+00:00

xen_hvm_post_suspend, xen_pre_suspend, xen_post_suspend are only used if
CONFIG_HIBERNATE_CALLBACKS is defined, resulting in:

drivers/xen/manage.c:46:13: warning: ‘xen_hvm_post_suspend’ defined but not used [-Wunused-function]
drivers/xen/manage.c:52:13: warning: ‘xen_pre_suspend’ defined but not used [-Wunused-function]
drivers/xen/manage.c:59:13: warning: ‘xen_post_suspend’ defined but not used [-Wunused-function]

If the kernel config is missing CONFIG_HIBERNATE_CALLBACKS.

Simply ifdef CONFIG_HIBERNATE_CALLBACKS the three functions.

Signed-off-by: Stefano Stabellini 
Signed-off-by: Konrad Rzeszutek Wilk