4.14-stable patches

added patches:
	x86-xen-delay-get_cpu_cap-until-stack-canary-is-established.patch
	xen-netfront-fix-hang-on-device-removal.patch

diff --git a/queue-4.14/series b/queue-4.14/series
index aba48b48408e0383d3ab37c566c25151c1852926..153a7c3ae891fac76e854e83e1b2ccd7c49557d1 100644 (file)
--- a/queue-4.14/series
+++ b/queue-4.14/series
@@ -29,3 +29,5 @@ spi-fix-unregistration-of-controller-with-fixed-spi-bus-number.patch
 media-atomisp_fops.c-disable-atomisp_compat_ioctl32.patch
 media-vivid-check-if-the-cec_adapter-is-valid.patch
 media-vsp1-fix-brx-conditional-path-in-wpf.patch
+x86-xen-delay-get_cpu_cap-until-stack-canary-is-established.patch
+xen-netfront-fix-hang-on-device-removal.patch

diff --git a/queue-4.14/x86-xen-delay-get_cpu_cap-until-stack-canary-is-established.patch b/queue-4.14/x86-xen-delay-get_cpu_cap-until-stack-canary-is-established.patch
new file mode 100644 (file)
index 0000000..142d8e9
--- /dev/null
+++ b/queue-4.14/x86-xen-delay-get_cpu_cap-until-stack-canary-is-established.patch
@@ -0,0 +1,61 @@
+From 36104cb9012a82e73c32a3b709257766b16bcd1d Mon Sep 17 00:00:00 2001
+From: Jason Andryuk <jandryuk@gmail.com>
+Date: Mon, 19 Mar 2018 12:58:04 -0400
+Subject: x86/xen: Delay get_cpu_cap until stack canary is established
+
+From: Jason Andryuk <jandryuk@gmail.com>
+
+commit 36104cb9012a82e73c32a3b709257766b16bcd1d upstream.
+
+Commit 2cc42bac1c79 ("x86-64/Xen: eliminate W+X mappings") introduced a
+call to get_cpu_cap, which is fstack-protected.  This is works on x86-64
+as commit 4f277295e54c ("x86/xen: init %gs very early to avoid page
+faults with stack protector") ensures the stack protector is configured,
+but it it did not cover x86-32.
+
+Delay calling get_cpu_cap until after xen_setup_gdt has initialized the
+stack canary.  Without this, a 32bit PV machine crashes early
+in boot.
+(XEN) Domain 0 (vcpu#0) crashed on cpu#0:
+(XEN) ----[ Xen-4.6.6-xc  x86_64  debug=n  Tainted:    C ]----
+(XEN) CPU:    0
+(XEN) RIP:    e019:[<00000000c10362f8>]
+
+And the PV kernel IP corresponds to init_scattered_cpuid_features
+   0xc10362f8 <+24>:    mov    %gs:0x14,%eax
+
+Fixes 2cc42bac1c79 ("x86-64/Xen: eliminate W+X mappings")
+
+Signed-off-by: Jason Andryuk <jandryuk@gmail.com>
+Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
+Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/x86/xen/enlighten_pv.c |    8 ++++----
+ 1 file changed, 4 insertions(+), 4 deletions(-)
+
+--- a/arch/x86/xen/enlighten_pv.c
++++ b/arch/x86/xen/enlighten_pv.c
+@@ -1258,10 +1258,6 @@ asmlinkage __visible void __init xen_sta
+        */
+       __userpte_alloc_gfp &= ~__GFP_HIGHMEM;
+ 
+-      /* Work out if we support NX */
+-      get_cpu_cap(&boot_cpu_data);
+-      x86_configure_nx();
+-
+       /* Get mfn list */
+       xen_build_dynamic_phys_to_machine();
+ 
+@@ -1271,6 +1267,10 @@ asmlinkage __visible void __init xen_sta
+        */
+       xen_setup_gdt(0);
+ 
++      /* Work out if we support NX */
++      get_cpu_cap(&boot_cpu_data);
++      x86_configure_nx();
++
+       xen_init_irq_ops();
+ 
+       /* Let's presume PV guests always boot on vCPU with id 0. */

diff --git a/queue-4.14/xen-netfront-fix-hang-on-device-removal.patch b/queue-4.14/xen-netfront-fix-hang-on-device-removal.patch
new file mode 100644 (file)
index 0000000..040184a
--- /dev/null
+++ b/queue-4.14/xen-netfront-fix-hang-on-device-removal.patch
@@ -0,0 +1,54 @@
+From c2d2e6738a209f0f9dffa2dc8e7292fc45360d61 Mon Sep 17 00:00:00 2001
+From: Jason Andryuk <jandryuk@gmail.com>
+Date: Wed, 28 Feb 2018 07:23:23 -0500
+Subject: xen-netfront: Fix hang on device removal
+
+From: Jason Andryuk <jandryuk@gmail.com>
+
+commit c2d2e6738a209f0f9dffa2dc8e7292fc45360d61 upstream.
+
+A toolstack may delete the vif frontend and backend xenstore entries
+while xen-netfront is in the removal code path.  In that case, the
+checks for xenbus_read_driver_state would return XenbusStateUnknown, and
+xennet_remove would hang indefinitely.  This hang prevents system
+shutdown.
+
+xennet_remove must be able to handle XenbusStateUnknown, and
+netback_changed must also wake up the wake_queue for that state as well.
+
+Fixes: 5b5971df3bc2 ("xen-netfront: remove warning when unloading module")
+
+Signed-off-by: Jason Andryuk <jandryuk@gmail.com>
+Cc: Eduardo Otubo <otubo@redhat.com>
+Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
+Signed-off-by: Juergen Gross <jgross@suse.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/net/xen-netfront.c |    7 ++++++-
+ 1 file changed, 6 insertions(+), 1 deletion(-)
+
+--- a/drivers/net/xen-netfront.c
++++ b/drivers/net/xen-netfront.c
+@@ -2008,7 +2008,10 @@ static void netback_changed(struct xenbu
+       case XenbusStateInitialised:
+       case XenbusStateReconfiguring:
+       case XenbusStateReconfigured:
++              break;
++
+       case XenbusStateUnknown:
++              wake_up_all(&module_unload_q);
+               break;
+ 
+       case XenbusStateInitWait:
+@@ -2139,7 +2142,9 @@ static int xennet_remove(struct xenbus_d
+               xenbus_switch_state(dev, XenbusStateClosing);
+               wait_event(module_unload_q,
+                          xenbus_read_driver_state(dev->otherend) ==
+-                         XenbusStateClosing);
++                         XenbusStateClosing ||
++                         xenbus_read_driver_state(dev->otherend) ==
++                         XenbusStateUnknown);
+ 
+               xenbus_switch_state(dev, XenbusStateClosed);
+               wait_event(module_unload_q,