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

xen/evtchn: avoid a deadlock when unbinding an event channel

2013-08-04T08:51:15+00:00

commit 179fbd5a45f0d4034cc6fd37b8d367a3b79663c4 upstream.

Unbinding an event channel (either with the ioctl or when the evtchn
device is closed) may deadlock because disable_irq() is called with
port_user_lock held which is also locked by the interrupt handler.

Think of the IOCTL_EVTCHN_UNBIND is being serviced, the routine has
just taken the lock, and an interrupt happens. The evtchn_interrupt
is invoked, tries to take the lock and spins forever.

A quick glance at the code shows that the spinlock is a local IRQ
variant. Unfortunately that does not help as "disable_irq() waits for
the interrupt handler on all CPUs to stop running.  If the irq occurs
on another VCPU, it tries to take port_user_lock and can't because
the unbind ioctl is holding it." (from David). Hence we cannot
depend on the said spinlock to protect us. We could make it a system
wide IRQ disable spinlock but there is a better way.

We can piggyback on the fact that the existence of the spinlock is
to make get_port_user() checks be up-to-date. And we can alter those
checks to not depend on the spin lock (as it's protected by u->bind_mutex
in the ioctl) and can remove the unnecessary locking (this is
IOCTL_EVTCHN_UNBIND) path.

In the interrupt handler we cannot use the mutex, but we do not
need it.

"The unbind disables the irq before making the port user stale, so when
you clear it you are guaranteed that the interrupt handler that might
use that port cannot be running." (from David).

Hence this patch removes the spinlock usage on the teardown path
and piggybacks on disable_irq happening before we muck with the
get_port_user() data. This ensures that the interrupt handler will
never run on stale data.

Signed-off-by: David Vrabel 
Signed-off-by: Konrad Rzeszutek Wilk 
[v1: Expanded the commit description a bit]
Signed-off-by: Jonghwan Choi 
Signed-off-by: Greg Kroah-Hartman

xen/tmem: Don't over-write tmem_frontswap_poolid after tmem_frontswap_init set it.

2013-06-10T14:14:33+00:00

Commit 10a7a0771399a57a297fca9615450dbb3f88081a ("xen: tmem: enable Xen
tmem shim to be built/loaded as a module") allows the tmem module
to be loaded any time. For this work the frontswap API had to
be able to asynchronously to call tmem_frontswap_init before
or after the swap image had been set. That was added in git
commit 905cd0e1bf9ffe82d6906a01fd974ea0f70be97a
("mm: frontswap: lazy initialization to allow tmem backends to build/run as modules").

Which means we could do this (The common case):

 modprobe tmem		[so calls frontswap_register_ops, no ->init]
			 modifies tmem_frontswap_poolid = -1
 swapon /dev/xvda1	[__frontswap_init, calls -> init, tmem_frontswap_poolid is
			 < 0 so tmem hypercall done]

Or the failing one:

 swapon /dev/xvda1	[calls __frontswap_init, sets the need_init bitmap]
 modprobe tmem		[calls frontswap_register_ops, -->init calls, finds out
			tmem_frontswap_poolid is 0, does not make a hypercall.
			Later in the module_init, sets tmem_frontswap_poolid=-1]

Which meant that in the failing case we would not call the hypercall
to initialize the pool and never be able to make any frontswap
backend calls.

Moving the frontswap_register_ops after setting the tmem_frontswap_poolid
fixes it.

Signed-off-by: Konrad Rzeszutek Wilk 
Reviewed-by: Bob Liu

xenbus_client.c: correct exit path for xenbus_map_ring_valloc_hvm

2013-05-29T19:24:55+00:00

Apparently we should not free page that has not been allocated.
This is b/c alloc_xenballooned_pages will take care of freeing
the page on its own.

Signed-off-by: Wei Liu 
Signed-off-by: Konrad Rzeszutek Wilk

xen-pciback: more uses of cached MSI-X capability offset

2013-05-29T13:04:22+00:00

Signed-off-by: Jan Beulich 
Signed-off-by: Konrad Rzeszutek Wilk

xenbus: save xenstore local status for later use

2013-05-29T13:04:20+00:00

Save the xenstore local status computed in xenbus_init. It can then be used
later to check if xenstored is running in this domain.

Signed-off-by: Aurelien Chartier 
[Changes in v4:
- Change variable name to xen_store_domain_type]
Reviewed-by: David Vrabel 
Signed-off-by: Konrad Rzeszutek Wilk

xenbus: delay xenbus frontend resume if xenstored is not running

2013-05-29T13:04:19+00:00

If the xenbus frontend is located in a domain running xenstored, the device
resume is hanging because it is happening before the process resume. This
patch adds extra logic to the resume code to check if we are the domain
running xenstored and delay the resume if needed.

Signed-off-by: Aurelien Chartier 
[Changes in v2:
- Instead of bypassing the resume, process it in a workqueue]
[Changes in v3:
- Add a struct work in xenbus_device to avoid dynamic allocation
- Several small code fixes]
[Changes in v4:
- Use a dedicated workqueue]
[Changes in v5:
- Move create_workqueue error handling to xenbus_frontend_dev_resume]
Acked-by: Jan Beulich 
Signed-off-by: Konrad Rzeszutek Wilk

xmem/tmem: fix 'undefined variable' build error.

2013-05-28T13:54:48+00:00

In the (not so useful) kernel configuration where CONFIG_SWAP
is undefined and CONFIG_XEN_SELFBALLOONING is defined,
xen_tmem_init would use undefined variable 'static bool frontswap'.

Added #else to have #define frontswap (0) in the case where
CONFIG_FRONTSWAP is not defined.

Signed-off-by: Frederico Cadete 
Signed-off-by: Konrad Rzeszutek Wilk

xen: Fixed assignment error in if statement

2013-05-20T18:14:48+00:00

Fixed assignment error in if statement in balloon.c

Signed-off-by: Lisa Nguyen 
Signed-off-by: Konrad Rzeszutek Wilk

xen/xenbus: Fixed over 80 character limit issue

2013-05-20T18:14:47+00:00

Fixed the format length of the xenbus_backend_ioctl()
function to meet the 80 character limit in
xenbus_dev_backend.c

Signed-off-by: Lisa Nguyen 
Signed-off-by: Konrad Rzeszutek Wilk

xen/xenbus: Fixed indentation error in switch case

2013-05-20T18:14:46+00:00

Fixed the indentation error in the switch case in
xenbus_dev_backend.c

Signed-off-by: Lisa Nguyen 
Signed-off-by: Konrad Rzeszutek Wilk