linux-toradex.git/drivers/xen, branch v3.2.74

xen/gntdevt: Fix race condition in gntdev_release()

2015-10-13T02:46:01+00:00

commit 30b03d05e07467b8c6ec683ea96b5bffcbcd3931 upstream.

While gntdev_release() is called the MMU notifier is still registered
and can traverse priv->maps list even if no pages are mapped (which is
the case -- gntdev_release() is called after all). But
gntdev_release() will clear that list, so make sure that only one of
those things happens at the same time.

Signed-off-by: Marek Marczykowski-Górecki 
Signed-off-by: David Vrabel 
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings

xen/gntdev: convert priv->lock to a mutex

2015-10-13T02:46:01+00:00

commit 1401c00e59ea021c575f74612fe2dbba36d6a4ee upstream.

Unmapping may require sleeping and we unmap while holding priv->lock, so
convert it to a mutex.

Signed-off-by: David Vrabel 
Reviewed-by: Stefano Stabellini 
[bwh: Backported to 3.2:
 - Adjust context
 - Drop changes to functions we don't have]
Signed-off-by: Ben Hutchings

xen/events: don't bind non-percpu VIRQs with percpu chip

2015-08-06T23:32:12+00:00

commit 77bb3dfdc0d554befad58fdefbc41be5bc3ed38a upstream.

A non-percpu VIRQ (e.g., VIRQ_CONSOLE) may be freed on a different
VCPU than it is bound to.  This can result in a race between
handle_percpu_irq() and removing the action in __free_irq() because
handle_percpu_irq() does not take desc->lock.  The interrupt handler
sees a NULL action and oopses.

Only use the percpu chip/handler for per-CPU VIRQs (like VIRQ_TIMER).

  # cat /proc/interrupts | grep virq
   40:      87246          0  xen-percpu-virq      timer0
   44:          0          0  xen-percpu-virq      debug0
   47:          0      20995  xen-percpu-virq      timer1
   51:          0          0  xen-percpu-virq      debug1
   69:          0          0   xen-dyn-virq      xen-pcpu
   74:          0          0   xen-dyn-virq      mce
   75:         29          0   xen-dyn-virq      hvc_console

Signed-off-by: David Vrabel 
[bwh: Backported to 3.2: adjust filename, context, indentation]
Signed-off-by: Ben Hutchings

xen-pciback: Add name prefix to global 'permissive' variable

2015-08-06T23:32:08+00:00

commit 8014bcc86ef112eab9ee1db312dba4e6b608cf89 upstream.

The variable for the 'permissive' module parameter used to be static
but was recently changed to be extern.  This puts it in the kernel
global namespace if the driver is built-in, so its name should begin
with a prefix identifying the driver.

Signed-off-by: Ben Hutchings 
Fixes: af6fc858a35b ("xen-pciback: limit guest control of command register")
Signed-off-by: David Vrabel

xen-pciback: limit guest control of command register

2015-05-09T22:16:29+00:00

commit af6fc858a35b90e89ea7a7ee58e66628c55c776b upstream.

Otherwise the guest can abuse that control to cause e.g. PCIe
Unsupported Request responses by disabling memory and/or I/O decoding
and subsequently causing (CPU side) accesses to the respective address
ranges, which (depending on system configuration) may be fatal to the
host.

Note that to alter any of the bits collected together as
PCI_COMMAND_GUEST permissive mode is now required to be enabled
globally or on the specific device.

This is CVE-2015-2150 / XSA-120.

Signed-off-by: Jan Beulich 
Reviewed-by: Konrad Rzeszutek Wilk 
Signed-off-by: David Vrabel 
[bwh: Backported to 3.2: also change type of permissive from int to bool]
Signed-off-by: Ben Hutchings

xen/manage: Fix USB interaction issues when resuming

2015-05-09T22:16:15+00:00

commit 72978b2fe2f2cdf9f319c6c6dcdbe92b38de2be2 upstream.

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 
Signed-off-by: David Vrabel 
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings

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

2014-11-05T20:27:40+00:00

commit 61a734d305e16944b42730ef582a7171dc733321 upstream.

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 
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings

xen/manage: fix potential deadlock when resuming the console

2014-08-06T17:07:34+00:00

commit 1b6478231c6f5f844185acb32045cf195028cfce upstream.

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 
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings

xen-gnt: prevent adding duplicate gnt callbacks

2013-10-26T20:05:57+00:00

commit 5f338d9001094a56cf87bd8a280b4e7ff953bb59 upstream.

With the current implementation, the callback in the tail of the list
can be added twice, because the check done in
gnttab_request_free_callback is bogus, callback->next can be NULL if
it is the last callback in the list. If we add the same callback twice
we end up with an infinite loop, were callback == callback->next.

Replace this check with a proper one that iterates over the list to
see if the callback has already been added.

Signed-off-by: Roger Pau Monné 
Cc: Konrad Rzeszutek Wilk 
Cc: David Vrabel 
Signed-off-by: Konrad Rzeszutek Wilk 
Acked-by: Matt Wilson 
Reviewed-by: David Vrabel 
Signed-off-by: Ben Hutchings

xen/events: mask events when changing their VCPU binding

2013-09-10T00:57:26+00:00

commit 4704fe4f03a5ab27e3c36184af85d5000e0f8a48 upstream.

When a event is being bound to a VCPU there is a window between the
EVTCHNOP_bind_vpcu call and the adjustment of the local per-cpu masks
where an event may be lost.  The hypervisor upcalls the new VCPU but
the kernel thinks that event is still bound to the old VCPU and
ignores it.

There is even a problem when the event is being bound to the same VCPU
as there is a small window beween the clear_bit() and set_bit() calls
in bind_evtchn_to_cpu().  When scanning for pending events, the kernel
may read the bit when it is momentarily clear and ignore the event.

Avoid this by masking the event during the whole bind operation.

Signed-off-by: David Vrabel 
Signed-off-by: Konrad Rzeszutek Wilk 
Reviewed-by: Jan Beulich 
[bwh: Backported to 3.2: remove the BM() cast]
Signed-off-by: Ben Hutchings