--- /dev/null
+From 12729f14d8357fb845d75155228b21e76360272d Mon Sep 17 00:00:00 2001
+From: Petr Mladek <pmladek@suse.cz>
+Date: Mon, 24 Feb 2014 17:12:20 +0100
+Subject: ftrace/x86: One more missing sync after fixup of function modification failure
+
+From: Petr Mladek <pmladek@suse.cz>
+
+commit 12729f14d8357fb845d75155228b21e76360272d upstream.
+
+If a failure occurs while modifying ftrace function, it bails out and will
+remove the tracepoints to be back to what the code originally was.
+
+There is missing the final sync run across the CPUs after the fix up is done
+and before the ftrace int3 handler flag is reset.
+
+Here's the description of the problem:
+
+ CPU0 CPU1
+ ---- ----
+ remove_breakpoint();
+ modifying_ftrace_code = 0;
+
+ [still sees breakpoint]
+ <takes trap>
+ [sees modifying_ftrace_code as zero]
+ [no breakpoint handler]
+ [goto failed case]
+ [trap exception - kernel breakpoint, no
+ handler]
+ BUG()
+
+Link: http://lkml.kernel.org/r/1393258342-29978-2-git-send-email-pmladek@suse.cz
+
+Fixes: 8a4d0a687a5 "ftrace: Use breakpoint method to update ftrace caller"
+Acked-by: Frederic Weisbecker <fweisbec@gmail.com>
+Acked-by: H. Peter Anvin <hpa@linux.intel.com>
+Signed-off-by: Petr Mladek <pmladek@suse.cz>
+Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/x86/kernel/ftrace.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/arch/x86/kernel/ftrace.c
++++ b/arch/x86/kernel/ftrace.c
+@@ -659,8 +659,8 @@ ftrace_modify_code(unsigned long ip, uns
+ ret = -EPERM;
+ goto out;
+ }
+- run_sync();
+ out:
++ run_sync();
+ return ret;
+
+ fail_update:
--- /dev/null
+From a35ff2861690eaf9dbb38fa744a8a9e6f4ebfd61 Mon Sep 17 00:00:00 2001
+From: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
+Date: Tue, 18 Mar 2014 10:49:17 +0000
+Subject: regulator: arizona-ldo1: Correct default regulator init_data
+
+From: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
+
+commit a35ff2861690eaf9dbb38fa744a8a9e6f4ebfd61 upstream.
+
+Both 5102 and 8997 have the regulator capable of supplying 1.8V, and the
+voltage step from the 5110 regulator is different from what is specified
+in the default description. This patch updates the default regulator
+description to match 5110 and selects the 1.8V capable description for
+8997.
+
+Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
+Signed-off-by: Mark Brown <broonie@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/regulator/arizona-ldo1.c | 7 +++----
+ 1 file changed, 3 insertions(+), 4 deletions(-)
+
+--- a/drivers/regulator/arizona-ldo1.c
++++ b/drivers/regulator/arizona-ldo1.c
+@@ -153,11 +153,9 @@ static const struct regulator_desc arizo
+
+ .vsel_reg = ARIZONA_LDO1_CONTROL_1,
+ .vsel_mask = ARIZONA_LDO1_VSEL_MASK,
+- .bypass_reg = ARIZONA_LDO1_CONTROL_1,
+- .bypass_mask = ARIZONA_LDO1_BYPASS,
+ .min_uV = 900000,
+- .uV_step = 50000,
+- .n_voltages = 7,
++ .uV_step = 25000,
++ .n_voltages = 13,
+ .enable_time = 500,
+
+ .owner = THIS_MODULE,
+@@ -203,6 +201,7 @@ static int arizona_ldo1_probe(struct pla
+ */
+ switch (arizona->type) {
+ case WM5102:
++ case WM8997:
+ desc = &arizona_ldo1_hc;
+ ldo1->init_data = arizona_ldo1_dvfs;
+ break;
staging-serqt_usb2-fix-sparse-warning-restricted-__le16-degrades-to-integer.patch
staging-r8712u-fix-case-where-ethtype-was-never-obtained-and-always-be-checked-against-0.patch
xfs-fix-directory-hash-ordering-bug.patch
+ftrace-x86-one-more-missing-sync-after-fixup-of-function-modification-failure.patch
+x86-64-modify_ldt-ban-16-bit-segments-on-64-bit-kernels.patch
+regulator-arizona-ldo1-correct-default-regulator-init_data.patch
+usb-fix-crash-during-hotplug-of-pci-usb-controller-card.patch
--- /dev/null
+From a2ff864b53eac9a0e9b05bfe9d1781ccd6c2af71 Mon Sep 17 00:00:00 2001
+From: Alan Stern <stern@rowland.harvard.edu>
+Date: Mon, 14 Apr 2014 13:48:47 -0400
+Subject: USB: fix crash during hotplug of PCI USB controller card
+
+From: Alan Stern <stern@rowland.harvard.edu>
+
+commit a2ff864b53eac9a0e9b05bfe9d1781ccd6c2af71 upstream.
+
+The code in hcd-pci.c that matches up EHCI controllers with their
+companion UHCI or OHCI controllers assumes that the private drvdata
+fields don't get set too early. However, it turns out that this field
+gets set by usb_create_hcd(), before hcd-pci expects it, and this can
+result in a crash when two controllers are probed in parallel (as can
+happen when a new controller card is hotplugged).
+
+The companions_rwsem lock was supposed to prevent this sort of thing,
+but usb_create_hcd() is called outside the scope of the rwsem.
+
+A simple solution is to check that the root-hub pointer has been
+initialized as well as the drvdata field. This doesn't happen until
+usb_add_hcd() is called; that call and the check are both protected by
+the rwsem.
+
+This patch should be applied to stable kernels from 3.10 onward.
+
+Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
+Reported-by: Stefani Seibold <stefani@seibold.net>
+Tested-by: Stefani Seibold <stefani@seibold.net>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/usb/core/hcd-pci.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/usb/core/hcd-pci.c
++++ b/drivers/usb/core/hcd-pci.c
+@@ -75,7 +75,7 @@ static void for_each_companion(struct pc
+ PCI_SLOT(companion->devfn) != slot)
+ continue;
+ companion_hcd = pci_get_drvdata(companion);
+- if (!companion_hcd)
++ if (!companion_hcd || !companion_hcd->self.root_hub)
+ continue;
+ fn(pdev, hcd, companion, companion_hcd);
+ }
--- /dev/null
+From b3b42ac2cbae1f3cecbb6229964a4d48af31d382 Mon Sep 17 00:00:00 2001
+From: "H. Peter Anvin" <hpa@linux.intel.com>
+Date: Sun, 16 Mar 2014 15:31:54 -0700
+Subject: x86-64, modify_ldt: Ban 16-bit segments on 64-bit kernels
+
+From: "H. Peter Anvin" <hpa@linux.intel.com>
+
+commit b3b42ac2cbae1f3cecbb6229964a4d48af31d382 upstream.
+
+The IRET instruction, when returning to a 16-bit segment, only
+restores the bottom 16 bits of the user space stack pointer. We have
+a software workaround for that ("espfix") for the 32-bit kernel, but
+it relies on a nonzero stack segment base which is not available in
+32-bit mode.
+
+Since 16-bit support is somewhat crippled anyway on a 64-bit kernel
+(no V86 mode), and most (if not quite all) 64-bit processors support
+virtualization for the users who really need it, simply reject
+attempts at creating a 16-bit segment when running on top of a 64-bit
+kernel.
+
+Cc: Linus Torvalds <torvalds@linux-foundation.org>
+Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
+Link: http://lkml.kernel.org/n/tip-kicdm89kzw9lldryb1br9od0@git.kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/x86/kernel/ldt.c | 11 +++++++++++
+ 1 file changed, 11 insertions(+)
+
+--- a/arch/x86/kernel/ldt.c
++++ b/arch/x86/kernel/ldt.c
+@@ -229,6 +229,17 @@ static int write_ldt(void __user *ptr, u
+ }
+ }
+
++ /*
++ * On x86-64 we do not support 16-bit segments due to
++ * IRET leaking the high bits of the kernel stack address.
++ */
++#ifdef CONFIG_X86_64
++ if (!ldt_info.seg_32bit) {
++ error = -EINVAL;
++ goto out_unlock;
++ }
++#endif
++
+ fill_ldt(&ldt, &ldt_info);
+ if (oldmode)
+ ldt.avl = 0;
projects / thirdparty / kernel / stable-queue.git / commitdiff
