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

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

xen/events: initialize local per-cpu mask for all possible events

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

commit 84ca7a8e45dafb49cd5ca90a343ba033e2885c17 upstream.

The sizeof() argument in init_evtchn_cpu_bindings() is incorrect
resulting in only the first 64 (or 32 in 32-bit guests) ports having
their bindings being initialized to VCPU 0.

In most cases this does not cause a problem as request_irq() will set
the irq affinity which will set the correct local per-cpu mask.
However, if the request_irq() is called on a VCPU other than 0, there
is a window between the unmasking of the event and the affinity being
set were an event may be lost because it is not locally unmasked on
any VCPU. If request_irq() is called on VCPU 0 then local irqs are
disabled during the window and the race does not occur.

Fix this by initializing all NR_EVENT_CHANNEL bits in the local
per-cpu masks.

Signed-off-by: David Vrabel 
Signed-off-by: Konrad Rzeszutek Wilk 
Signed-off-by: Ben Hutchings

xen/events: Handle VIRQ_TIMER before any other hardirq in event loop.

2013-06-19T01:16:45+00:00

This avoids any other hardirq handler seeing a very stale jiffies
value immediately after wakeup from a long idle period. The one
observable symptom of this was a USB keyboard, with software keyboard
repeat, which would always repeat a key immediately that it was
pressed. This is due to the key press waking the guest, the key
handler immediately runs, sees an old jiffies value, and then that
jiffies value significantly updated, before the key is unpressed.

Reviewed-by: David Vrabel 
Signed-off-by: Keir Fraser 
Signed-off-by: Konrad Rzeszutek Wilk 
(cherry picked from commit bee980d9e9642e96351fa3ca9077b853ecf62f57)
Signed-off-by: Ben Hutchings

xen/pciback: Don't disable a PCI device that is already disabled.

2013-03-20T15:03:29+00:00

commit bdc5c1812cea6efe1aaefb3131fcba28cd0b2b68 upstream.

While shuting down a HVM guest with pci devices passed through we
get this:

pciback 0000:04:00.0: restoring config space at offset 0x4 (was 0x100000, writing 0x100002)
------------[ cut here ]------------
WARNING: at drivers/pci/pci.c:1397 pci_disable_device+0x88/0xa0()
Hardware name: MS-7640
Device pciback
disabling already-disabled device
Modules linked in:
Pid: 53, comm: xenwatch Not tainted 3.9.0-rc1-20130304a+ #1
Call Trace:
 [] warn_slowpath_common+0x7a/0xc0
 [] warn_slowpath_fmt+0x41/0x50
 [] pci_disable_device+0x88/0xa0
 [] xen_pcibk_reset_device+0x37/0xd0
 [] ? pcistub_put_pci_dev+0x6f/0x120
 [] pcistub_put_pci_dev+0x8d/0x120
 [] __xen_pcibk_release_devices+0x59/0xa0

This fixes the bug.

Reported-and-Tested-by: Sander Eikelenboom 
Signed-off-by: Konrad Rzeszutek Wilk 
Signed-off-by: Ben Hutchings

xen-pciback: rate limit error messages from xen_pcibk_enable_msi{,x}()

2013-03-06T03:24:19+00:00

commit 51ac8893a7a51b196501164e645583bf78138699 upstream.

... as being guest triggerable (e.g. by invoking
XEN_PCI_OP_enable_msi{,x} on a device not being MSI/MSI-X capable).

This is CVE-2013-0231 / XSA-43.

Also make the two messages uniform in both their wording and severity.

Signed-off-by: Jan Beulich 
Acked-by: Ian Campbell 
Reviewed-by: Konrad Rzeszutek Wilk 
[bwh: Backported to 3.2: add #include , needed by
 printk_ratelimited()]
Signed-off-by: Ben Hutchings

xen: close evtchn port if binding to irq fails

2013-03-06T03:24:07+00:00

commit e7e44e444876478d50630f57b0c31d29f6725020 upstream.

Signed-off-by: Wei Liu 
Signed-off-by: Konrad Rzeszutek Wilk 
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings

xen/gntdev: don't leak memory from IOCTL_GNTDEV_MAP_GRANT_REF

2012-11-16T16:47:00+00:00

commit a67baeb77375199bbd842fa308cb565164dd1f19 upstream.

map->kmap_ops allocated in gntdev_alloc_map() wasn't freed by
gntdev_put_map().

Add a gntdev_free_map() helper function to free everything allocated
by gntdev_alloc_map().

Signed-off-by: David Vrabel 
Signed-off-by: Konrad Rzeszutek Wilk 
Signed-off-by: Ben Hutchings