linux-stable.git/drivers/xen, branch v3.18.26

xen/gntdevt: Fix race condition in gntdev_release()

2015-08-27T17:25:25+00:00

[ Upstream commit 30b03d05e07467b8c6ec683ea96b5bffcbcd3931 ]

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 
Cc: 
Signed-off-by: David Vrabel 
Signed-off-by: Sasha Levin

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

2015-08-27T17:25:18+00:00

[ Upstream commit 1401c00e59ea021c575f74612fe2dbba36d6a4ee ]

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 
Signed-off-by: Sasha Levin

x86/xen: allow privcmd hypercalls to be preempted

2015-07-21T01:12:45+00:00

[ Upstream commit db0e2aa47f0a45fc56592c25ad370f8836cbb128 ]

Hypercalls submitted by user space tools via the privcmd driver can
take a long time (potentially many 10s of seconds) if the hypercall
has many sub-operations.

A fully preemptible kernel may deschedule such as task in any upcall
called from a hypercall continuation.

However, in a kernel with voluntary or no preemption, hypercall
continuations in Xen allow event handlers to be run but the task
issuing the hypercall will not be descheduled until the hypercall is
complete and the ioctl returns to user space.  These long running
tasks may also trigger the kernel's soft lockup detection.

Add xen_preemptible_hcall_begin() and xen_preemptible_hcall_end() to
bracket hypercalls that may be preempted.  Use these in the privcmd
driver.

When returning from an upcall, call xen_maybe_preempt_hcall() which
adds a schedule point if if the current task was within a preemptible
hypercall.

Since _cond_resched() can move the task to a different CPU, clear and
set xen_in_preemptible_hcall around the call.

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

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

2015-06-09T17:43:54+00:00

[ Upstream commit 77bb3dfdc0d554befad58fdefbc41be5bc3ed38a ]

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 
Cc: 
Signed-off-by: Sasha Levin

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

2015-05-23T19:53:21+00:00

[ Upstream commit 8014bcc86ef112eab9ee1db312dba4e6b608cf89 ]

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 
Signed-off-by: Sasha Levin

xen/events: Set irq_info->evtchn before binding the channel to CPU in __startup_pirq()

2015-05-23T19:53:13+00:00

[ Upstream commit 16e6bd5970c88a2ac018b84a5f1dd5c2ff1fdf2c ]

.. because bind_evtchn_to_cpu(evtchn, cpu) will map evtchn to
'info' and pass 'info' down to xen_evtchn_port_bind_to_cpu().

Signed-off-by: Boris Ostrovsky 
Tested-by: Annie Li 
Cc: 
Signed-off-by: David Vrabel 
Signed-off-by: Sasha Levin

xen/xenbus: Update xenbus event channel on resume

2015-05-23T19:52:58+00:00

[ Upstream commit 16f1cf3ba7303228372d3756677bf7d10e79cf9f ]

After a resume the hypervisor/tools may change xenbus event
channel number. We should re-query it.

Signed-off-by: Boris Ostrovsky 
Cc: 
Signed-off-by: David Vrabel 
Signed-off-by: Sasha Levin

xen/events: Clear cpu_evtchn_mask before resuming

2015-05-23T19:52:50+00:00

[ Upstream commit 5cec98834989a014a9560b1841649eaca95cf00e ]

When a guest is resumed, the hypervisor may change event channel
assignments. If this happens and the guest uses 2-level events it
is possible for the interrupt to be claimed by wrong VCPU since
cpu_evtchn_mask bits may be stale. This can happen even though
evtchn_2l_bind_to_cpu() attempts to clear old bits: irq_info that
is passed in is not necessarily the original one (from pre-migration
times) but instead is freshly allocated during resume and so any
information about which CPU the channel was bound to is lost.

Thus we should clear the mask during resume.

We also need to make sure that bits for xenstore and console channels
are set when these two subsystems are resumed. While rebind_evtchn_irq()
(which is invoked for both of them on a resume) calls irq_set_affinity(),
the latter will in fact postpone setting affinity until handling the
interrupt. But because cpu_evtchn_mask will have bits for these two
cleared we won't be able to take the interrupt.

With that in mind, we need to bind those two channels explicitly in
rebind_evtchn_irq(). We will keep irq_set_affinity() so that we have a
pass through generic irq affinity code later, in case something needs
to be updated there as well.

(Also replace cpumask_of(0) with cpumask_of(info->cpu) in
rebind_evtchn_irq(): it should be set to zero in preceding
xen_irq_info_evtchn_setup().)

Signed-off-by: Boris Ostrovsky 
Reported-by: Annie Li 
Cc:  # 3.14+
Signed-off-by: David Vrabel 
Signed-off-by: Sasha Levin

xen/balloon: before adding hotplugged memory, set frames to invalid

2015-04-23T18:58:26+00:00

[ Upstream commit 3c56b3a12ce52f361468cbdd2f79b2f3b8da0ea6 ]

Commit 25b884a83d487fd62c3de7ac1ab5549979188482 ("x86/xen: set
regions above the end of RAM as 1:1") introduced a regression.

To be able to add memory pages which were added via memory hotplug to
a pv domain, the pages must be "invalid" instead of "identity" in the
p2m list before they can be added.

Suggested-by: David Vrabel 
Signed-off-by: Juergen Gross 
Cc:  # 3.16+
Reviewed-by: Daniel Kiper 
Signed-off-by: David Vrabel 
Signed-off-by: Sasha Levin

xen-pciback: limit guest control of command register

2015-03-28T14:00:58+00:00

[ Upstream commit af6fc858a35b90e89ea7a7ee58e66628c55c776b ]

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 
Cc: 
Signed-off-by: David Vrabel 
Signed-off-by: Sasha Levin