kernel/git/stable/linux.git/drivers/xen, branch linux-3.15.y

xen/manage: fix potential deadlock when resuming the console

2014-07-28T15:08:21+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 Signed-off-by: Greg Kroah-Hartman

xen/balloon: set ballooned out pages as invalid in p2m

2014-07-28T15:08:20+00:00

commit fb9a0c443691ceaab3daba966bbbd9f5ff3aa26f upstream. Since cd9151e26d31048b2b5e00fd02e110e07d2200c9 (xen/balloon: set a mapping for ballooned out pages), a ballooned out page had its entry in the p2m set to the MFN of one of the scratch pages. This means that the p2m will contain many entries pointing to the same MFN. During a domain save, these many-to-one entries are not identified as such and the scratch page is saved multiple times. On restore the ballooned pages are populated with new frames and the domain may use up its allocation before all pages can be restored. Since the original fix only needed to keep a mapping for the ballooned page it is safe to set ballooned out pages as INVALID_P2M_ENTRY in the p2m (as they were before). Thus preventing them from being saved and re-populated on restore. Signed-off-by: David Vrabel Reported-by: Marek Marczykowski Tested-by: Marek Marczykowski Acked-by: Stefano Stabellini Signed-off-by: Greg Kroah-Hartman

Merge tag 'stable/for-linus-3.15-rc5-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip

2014-05-13T02:21:01+00:00

Pull xen bug fixes from David Vrabel: - Fix arm64 crash on boot. - Quiet a noisy arm build warning (virt_to_pfn() redefined). * tag 'stable/for-linus-3.15-rc5-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip: arm64: introduce virt_to_pfn xen/events/fifo: correctly align bitops arm/xen: Remove definiition of virt_to_pfn in asm/xen/page.h

xen/events/fifo: correctly align bitops

2014-04-28T10:09:40+00:00

FIFO event channels require bitops on 32-bit aligned values (the event words). Linux's bitops require unsigned long alignment which may be 64-bits. On arm64 an incorrectly unaligned access will fault. Fix this by aligning the bitops along with an adjustment for bit position and using an unsigned long for the local copy of the ready word. Cc: stable@vger.kernel.org Signed-off-by: Vladimir Murzin Tested-by: Pranavkumar Sawargaonkar Reviewed-by: Ian Campbell Signed-off-by: David Vrabel

Merge tag 'stable/for-linus-3.15-rc1-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip

2014-04-17T17:54:07+00:00

Pull Xen fixes from David Vrabel: "Xen regression and bug fixes for 3.15-rc1: - fix completely broken 32-bit PV guests caused by x86 refactoring 32-bit thread_info. - only enable ticketlock slow path on Xen (not bare metal) - fix two bugs with PV guests not shutting down when requested - fix a minor memory leak in xen-pciback error path" * tag 'stable/for-linus-3.15-rc1-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip: xen/manage: Poweroff forcefully if user-space is not yet up. xen/xenbus: Avoid synchronous wait on XenBus stalling shutdown/restart. xen/spinlock: Don't enable them unconditionally. xen-pciback: silence an unwanted debug printk xen: fix memory leak in __xen_pcibk_add_pci_dev() x86/xen: Fix 32-bit PV guests's usage of kernel_stack

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/xenbus: Avoid synchronous wait on XenBus stalling shutdown/restart.

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

The 'read_reply' works with 'process_msg' to read of a reply in XenBus. 'process_msg' is running from within the 'xenbus' thread. Whenever a message shows up in XenBus it is put on a xs_state.reply_list list and 'read_reply' picks it up. The problem is if the backend domain or the xenstored process is killed. In which case 'xenbus' is still awaiting - and 'read_reply' if called - stuck forever waiting for the reply_list to have some contents. This is normally not a problem - as the backend domain can come back or the xenstored process can be restarted. However if the domain is in process of being powered off/restarted/halted - there is no point of waiting on it coming back - as we are effectively being terminated and should not impede the progress. This patch solves this problem by checking whether the guest is the right domain. If it is an initial domain and hurtling towards death - there is no point of continuing the wait. All other type of guests continue with their behavior (as Xenstore is expected to still be running in another domain). Fixes-Bug: http://bugs.xenproject.org/xen/bug/8 Signed-off-by: Konrad Rzeszutek Wilk Reviewed-by: Boris Ostrovsky Reviewed-by: David Vrabel Signed-off-by: David Vrabel

xen-pciback: silence an unwanted debug printk

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

There is a missing curly brace here so we might print some extra debug information. Signed-off-by: Dan Carpenter Signed-off-by: David Vrabel

xen: fix memory leak in __xen_pcibk_add_pci_dev()

2014-04-15T16:32:30+00:00

It need to free dev_entry when it failed to assign to a new slot on the virtual PCI bus. smatch says: drivers/xen/xen-pciback/vpci.c:142 __xen_pcibk_add_pci_dev() warn: possible memory leak of 'dev_entry' Signed-off-by: Daeseok Youn Signed-off-by: David Vrabel

Merge tag 'stable/for-linus-3.15-tag2' of git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip

2014-04-08T00:50:18+00:00

Pull Xen build fix from David Vrabel: "Fix arm build of drivers/xen/events/ The merge of irq-core-for-linus branch broke it" * tag 'stable/for-linus-3.15-tag2' of git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip: Xen: do hv callback accounting only on x86