]> git.ipfire.org Git - thirdparty/kernel/stable-queue.git/commitdiff
3.10-stable patches
authorGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Fri, 7 Feb 2014 04:23:19 +0000 (20:23 -0800)
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Fri, 7 Feb 2014 04:23:19 +0000 (20:23 -0800)
added patches:
acpi-init-flag-use-of-acpi-and-acpi-idioms-for-power-supplies-to-regulator-api.patch
slub-fix-calculation-of-cpu-slabs.patch
turbostat-don-t-put-unprocessed-uapi-headers-in-the-include-path.patch
turbostat-use-gcc-s-cpuid-functions-to-support-pic.patch

queue-3.10/acpi-init-flag-use-of-acpi-and-acpi-idioms-for-power-supplies-to-regulator-api.patch [new file with mode: 0644]
queue-3.10/series
queue-3.10/slub-fix-calculation-of-cpu-slabs.patch [new file with mode: 0644]
queue-3.10/turbostat-don-t-put-unprocessed-uapi-headers-in-the-include-path.patch [new file with mode: 0644]
queue-3.10/turbostat-use-gcc-s-cpuid-functions-to-support-pic.patch [new file with mode: 0644]

diff --git a/queue-3.10/acpi-init-flag-use-of-acpi-and-acpi-idioms-for-power-supplies-to-regulator-api.patch b/queue-3.10/acpi-init-flag-use-of-acpi-and-acpi-idioms-for-power-supplies-to-regulator-api.patch
new file mode 100644 (file)
index 0000000..0dd025d
--- /dev/null
@@ -0,0 +1,66 @@
+From 49a12877d2777cadcb838981c3c4f5a424aef310 Mon Sep 17 00:00:00 2001
+From: Mark Brown <broonie@linaro.org>
+Date: Mon, 27 Jan 2014 00:32:14 +0000
+Subject: ACPI / init: Flag use of ACPI and ACPI idioms for power supplies to regulator API
+
+From: Mark Brown <broonie@linaro.org>
+
+commit 49a12877d2777cadcb838981c3c4f5a424aef310 upstream.
+
+There is currently no facility in ACPI to express the hookup of voltage
+regulators, the expectation is that the regulators that exist in the
+system will be handled transparently by firmware if they need software
+control at all. This means that if for some reason the regulator API is
+enabled on such a system it should assume that any supplies that devices
+need are provided by the system at all relevant times without any software
+intervention.
+
+Tell the regulator core to make this assumption by calling
+regulator_has_full_constraints(). Do this as soon as we know we are using
+ACPI so that the information is available to the regulator core as early
+as possible. This will cause the regulator core to pretend that there is
+an always on regulator supplying any supply that is requested but that has
+not otherwise been mapped which is the behaviour expected on a system with
+ACPI.
+
+Should the ability to specify regulators be added in future revisions of
+ACPI then once we have support for ACPI mappings in the kernel the same
+assumptions will apply. It is also likely that systems will default to a
+mode of operation which does not require any interpretation of these
+mappings in order to be compatible with existing operating system releases
+so it should remain safe to make these assumptions even if the mappings
+exist but are not supported by the kernel.
+
+Signed-off-by: Mark Brown <broonie@linaro.org>
+Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/acpi/bus.c |    9 +++++++++
+ 1 file changed, 9 insertions(+)
+
+--- a/drivers/acpi/bus.c
++++ b/drivers/acpi/bus.c
+@@ -33,6 +33,7 @@
+ #include <linux/proc_fs.h>
+ #include <linux/acpi.h>
+ #include <linux/slab.h>
++#include <linux/regulator/machine.h>
+ #ifdef CONFIG_X86
+ #include <asm/mpspec.h>
+ #endif
+@@ -705,6 +706,14 @@ void __init acpi_early_init(void)
+               goto error0;
+       }
++      /*
++       * If the system is using ACPI then we can be reasonably
++       * confident that any regulators are managed by the firmware
++       * so tell the regulator core it has everything it needs to
++       * know.
++       */
++      regulator_has_full_constraints();
++
+       return;
+       error0:
index 1903fad3c04dfe0b18120fb6a0877eb5778c4a19..99d053936ee91ec4414c8c346c916cc7b1aea890 100644 (file)
@@ -13,3 +13,7 @@ mm-page-writeback.c-fix-dirty_balance_reserve-subtraction-from-dirtyable-memory.
 mm-page-writeback.c-do-not-count-anon-pages-as-dirtyable-memory.patch
 mmc-fix-host-release-issue-after-discard-operation.patch
 mmc-atmel-mci-fix-timeout-errors-in-sdio-mode-when-using-dma.patch
+slub-fix-calculation-of-cpu-slabs.patch
+turbostat-don-t-put-unprocessed-uapi-headers-in-the-include-path.patch
+turbostat-use-gcc-s-cpuid-functions-to-support-pic.patch
+acpi-init-flag-use-of-acpi-and-acpi-idioms-for-power-supplies-to-regulator-api.patch
diff --git a/queue-3.10/slub-fix-calculation-of-cpu-slabs.patch b/queue-3.10/slub-fix-calculation-of-cpu-slabs.patch
new file mode 100644 (file)
index 0000000..72aad05
--- /dev/null
@@ -0,0 +1,54 @@
+From 8afb1474db4701d1ab80cd8251137a3260e6913e Mon Sep 17 00:00:00 2001
+From: Li Zefan <lizefan@huawei.com>
+Date: Tue, 10 Sep 2013 11:43:37 +0800
+Subject: slub: Fix calculation of cpu slabs
+
+From: Li Zefan <lizefan@huawei.com>
+
+commit 8afb1474db4701d1ab80cd8251137a3260e6913e upstream.
+
+  /sys/kernel/slab/:t-0000048 # cat cpu_slabs
+  231 N0=16 N1=215
+  /sys/kernel/slab/:t-0000048 # cat slabs
+  145 N0=36 N1=109
+
+See, the number of slabs is smaller than that of cpu slabs.
+
+The bug was introduced by commit 49e2258586b423684f03c278149ab46d8f8b6700
+("slub: per cpu cache for partial pages").
+
+We should use page->pages instead of page->pobjects when calculating
+the number of cpu partial slabs. This also fixes the mapping of slabs
+and nodes.
+
+As there's no variable storing the number of total/active objects in
+cpu partial slabs, and we don't have user interfaces requiring those
+statistics, I just add WARN_ON for those cases.
+
+Acked-by: Christoph Lameter <cl@linux.com>
+Reviewed-by: Wanpeng Li <liwanp@linux.vnet.ibm.com>
+Signed-off-by: Li Zefan <lizefan@huawei.com>
+Signed-off-by: Pekka Enberg <penberg@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ mm/slub.c |    8 +++++++-
+ 1 file changed, 7 insertions(+), 1 deletion(-)
+
+--- a/mm/slub.c
++++ b/mm/slub.c
+@@ -4285,7 +4285,13 @@ static ssize_t show_slab_objects(struct
+                       page = ACCESS_ONCE(c->partial);
+                       if (page) {
+-                              x = page->pobjects;
++                              node = page_to_nid(page);
++                              if (flags & SO_TOTAL)
++                                      WARN_ON_ONCE(1);
++                              else if (flags & SO_OBJECTS)
++                                      WARN_ON_ONCE(1);
++                              else
++                                      x = page->pages;
+                               total += x;
+                               nodes[node] += x;
+                       }
diff --git a/queue-3.10/turbostat-don-t-put-unprocessed-uapi-headers-in-the-include-path.patch b/queue-3.10/turbostat-don-t-put-unprocessed-uapi-headers-in-the-include-path.patch
new file mode 100644 (file)
index 0000000..1146dde
--- /dev/null
@@ -0,0 +1,68 @@
+From b731f3119de57144e16c19fd593b8daeb637843e Mon Sep 17 00:00:00 2001
+From: Josh Triplett <josh@joshtriplett.org>
+Date: Tue, 20 Aug 2013 17:20:12 -0700
+Subject: turbostat: Don't put unprocessed uapi headers in the include path
+
+From: Josh Triplett <josh@joshtriplett.org>
+
+commit b731f3119de57144e16c19fd593b8daeb637843e upstream.
+
+turbostat's Makefile puts arch/x86/include/uapi/ in the include path, so
+that it can include <asm/msr.h> from it.  It isn't in general safe to
+include even uapi headers directly from the kernel tree without
+processing them through scripts/headers_install.sh, but asm/msr.h
+happens to work.
+
+However, that include path can break with some versions of system
+headers, by overriding some system headers with the unprocessed versions
+directly from the kernel source.  For instance:
+
+In file included from /build/x86-generic/usr/include/bits/sigcontext.h:28:0,
+                 from /build/x86-generic/usr/include/signal.h:339,
+                 from /build/x86-generic/usr/include/sys/wait.h:31,
+                 from turbostat.c:27:
+../../../../arch/x86/include/uapi/asm/sigcontext.h:4:28: fatal error: linux/compiler.h: No such file or directory
+
+This occurs because the system bits/sigcontext.h on that build system
+includes <asm/sigcontext.h>, and asm/sigcontext.h in the kernel source
+includes <linux/compiler.h>, which scripts/headers_install.sh would have
+filtered out.
+
+Since turbostat really only wants a single header, just include that one
+header rather than putting an entire directory of kernel headers on the
+include path.
+
+In the process, switch from msr.h to msr-index.h, since turbostat just
+wants the MSR numbers.
+
+Signed-off-by: Josh Triplett <josh@joshtriplett.org>
+Signed-off-by: Len Brown <len.brown@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ tools/power/x86/turbostat/Makefile    |    2 +-
+ tools/power/x86/turbostat/turbostat.c |    2 +-
+ 2 files changed, 2 insertions(+), 2 deletions(-)
+
+--- a/tools/power/x86/turbostat/Makefile
++++ b/tools/power/x86/turbostat/Makefile
+@@ -5,7 +5,7 @@ DESTDIR                :=
+ turbostat : turbostat.c
+ CFLAGS +=     -Wall
+-CFLAGS +=     -I../../../../arch/x86/include/uapi/
++CFLAGS +=     -DMSRHEADER='"../../../../arch/x86/include/uapi/asm/msr-index.h"'
+ %: %.c
+       @mkdir -p $(BUILD_OUTPUT)
+--- a/tools/power/x86/turbostat/turbostat.c
++++ b/tools/power/x86/turbostat/turbostat.c
+@@ -20,7 +20,7 @@
+  */
+ #define _GNU_SOURCE
+-#include <asm/msr.h>
++#include MSRHEADER
+ #include <stdio.h>
+ #include <unistd.h>
+ #include <sys/types.h>
diff --git a/queue-3.10/turbostat-use-gcc-s-cpuid-functions-to-support-pic.patch b/queue-3.10/turbostat-use-gcc-s-cpuid-functions-to-support-pic.patch
new file mode 100644 (file)
index 0000000..cf8c1cd
--- /dev/null
@@ -0,0 +1,88 @@
+From 2b92865e648ce04a39fda4f903784a5d01ecb0dc Mon Sep 17 00:00:00 2001
+From: Josh Triplett <josh@joshtriplett.org>
+Date: Tue, 20 Aug 2013 17:20:14 -0700
+Subject: turbostat: Use GCC's CPUID functions to support PIC
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Josh Triplett <josh@joshtriplett.org>
+
+commit 2b92865e648ce04a39fda4f903784a5d01ecb0dc upstream.
+
+turbostat uses inline assembly to call cpuid.  On 32-bit x86, on systems
+that have certain security features enabled by default that make -fPIC
+the default, this causes a build error:
+
+turbostat.c: In function ‘check_cpuid’:
+turbostat.c:1906:2: error: PIC register clobbered by ‘ebx’ in ‘asm’
+  asm("cpuid" : "=a" (fms), "=c" (ecx), "=d" (edx) : "a" (1) : "ebx");
+  ^
+
+GCC provides a header cpuid.h, containing a __get_cpuid function that
+works with both PIC and non-PIC.  (On PIC, it saves and restores ebx
+around the cpuid instruction.)  Use that instead.
+
+Signed-off-by: Josh Triplett <josh@joshtriplett.org>
+Signed-off-by: Len Brown <len.brown@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ tools/power/x86/turbostat/turbostat.c |   11 ++++++-----
+ 1 file changed, 6 insertions(+), 5 deletions(-)
+
+--- a/tools/power/x86/turbostat/turbostat.c
++++ b/tools/power/x86/turbostat/turbostat.c
+@@ -35,6 +35,7 @@
+ #include <string.h>
+ #include <ctype.h>
+ #include <sched.h>
++#include <cpuid.h>
+ char *proc_stat = "/proc/stat";
+ unsigned int interval_sec = 5;        /* set with -i interval_sec */
+@@ -1894,7 +1895,7 @@ void check_cpuid()
+       eax = ebx = ecx = edx = 0;
+-      asm("cpuid" : "=a" (max_level), "=b" (ebx), "=c" (ecx), "=d" (edx) : "a" (0));
++      __get_cpuid(0, &max_level, &ebx, &ecx, &edx);
+       if (ebx == 0x756e6547 && edx == 0x49656e69 && ecx == 0x6c65746e)
+               genuine_intel = 1;
+@@ -1903,7 +1904,7 @@ void check_cpuid()
+               fprintf(stderr, "CPUID(0): %.4s%.4s%.4s ",
+                       (char *)&ebx, (char *)&edx, (char *)&ecx);
+-      asm("cpuid" : "=a" (fms), "=c" (ecx), "=d" (edx) : "a" (1) : "ebx");
++      __get_cpuid(1, &fms, &ebx, &ecx, &edx);
+       family = (fms >> 8) & 0xf;
+       model = (fms >> 4) & 0xf;
+       stepping = fms & 0xf;
+@@ -1925,7 +1926,7 @@ void check_cpuid()
+        * This check is valid for both Intel and AMD.
+        */
+       ebx = ecx = edx = 0;
+-      asm("cpuid" : "=a" (max_level), "=b" (ebx), "=c" (ecx), "=d" (edx) : "a" (0x80000000));
++      __get_cpuid(0x80000000, &max_level, &ebx, &ecx, &edx);
+       if (max_level < 0x80000007) {
+               fprintf(stderr, "CPUID: no invariant TSC (max_level 0x%x)\n", max_level);
+@@ -1936,7 +1937,7 @@ void check_cpuid()
+        * Non-Stop TSC is advertised by CPUID.EAX=0x80000007: EDX.bit8
+        * this check is valid for both Intel and AMD
+        */
+-      asm("cpuid" : "=a" (eax), "=b" (ebx), "=c" (ecx), "=d" (edx) : "a" (0x80000007));
++      __get_cpuid(0x80000007, &eax, &ebx, &ecx, &edx);
+       has_invariant_tsc = edx & (1 << 8);
+       if (!has_invariant_tsc) {
+@@ -1949,7 +1950,7 @@ void check_cpuid()
+        * this check is valid for both Intel and AMD
+        */
+-      asm("cpuid" : "=a" (eax), "=b" (ebx), "=c" (ecx), "=d" (edx) : "a" (0x6));
++      __get_cpuid(0x6, &eax, &ebx, &ecx, &edx);
+       has_aperf = ecx & (1 << 0);
+       do_dts = eax & (1 << 0);
+       do_ptm = eax & (1 << 6);