--- /dev/null
+From 16927776ae757d0d132bdbfabbfe2c498342bd59 Mon Sep 17 00:00:00 2001
+From: John Stultz <john.stultz@linaro.org>
+Date: Mon, 7 Jul 2014 14:06:11 -0700
+Subject: alarmtimer: Fix bug where relative alarm timers were treated as absolute
+
+From: John Stultz <john.stultz@linaro.org>
+
+commit 16927776ae757d0d132bdbfabbfe2c498342bd59 upstream.
+
+Sharvil noticed with the posix timer_settime interface, using the
+CLOCK_REALTIME_ALARM or CLOCK_BOOTTIME_ALARM clockid, if the users
+tried to specify a relative time timer, it would incorrectly be
+treated as absolute regardless of the state of the flags argument.
+
+This patch corrects this, properly checking the absolute/relative flag,
+as well as adds further error checking that no invalid flag bits are set.
+
+Reported-by: Sharvil Nanavati <sharvil@google.com>
+Signed-off-by: John Stultz <john.stultz@linaro.org>
+Cc: Thomas Gleixner <tglx@linutronix.de>
+Cc: Ingo Molnar <mingo@kernel.org>
+Cc: Prarit Bhargava <prarit@redhat.com>
+Cc: Sharvil Nanavati <sharvil@google.com>
+Link: http://lkml.kernel.org/r/1404767171-6902-1-git-send-email-john.stultz@linaro.org
+Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ kernel/time/alarmtimer.c | 20 ++++++++++++++++++--
+ 1 file changed, 18 insertions(+), 2 deletions(-)
+
+--- a/kernel/time/alarmtimer.c
++++ b/kernel/time/alarmtimer.c
+@@ -585,9 +585,14 @@ static int alarm_timer_set(struct k_itim
+ struct itimerspec *new_setting,
+ struct itimerspec *old_setting)
+ {
++ ktime_t exp;
++
+ if (!rtcdev)
+ return -ENOTSUPP;
+
++ if (flags & ~TIMER_ABSTIME)
++ return -EINVAL;
++
+ if (old_setting)
+ alarm_timer_get(timr, old_setting);
+
+@@ -597,8 +602,16 @@ static int alarm_timer_set(struct k_itim
+
+ /* start the timer */
+ timr->it.alarm.interval = timespec_to_ktime(new_setting->it_interval);
+- alarm_start(&timr->it.alarm.alarmtimer,
+- timespec_to_ktime(new_setting->it_value));
++ exp = timespec_to_ktime(new_setting->it_value);
++ /* Convert (if necessary) to absolute time */
++ if (flags != TIMER_ABSTIME) {
++ ktime_t now;
++
++ now = alarm_bases[timr->it.alarm.alarmtimer.type].gettime();
++ exp = ktime_add(now, exp);
++ }
++
++ alarm_start(&timr->it.alarm.alarmtimer, exp);
+ return 0;
+ }
+
+@@ -730,6 +743,9 @@ static int alarm_timer_nsleep(const cloc
+ if (!alarmtimer_get_rtcdev())
+ return -ENOTSUPP;
+
++ if (flags & ~TIMER_ABSTIME)
++ return -EINVAL;
++
+ if (!capable(CAP_WAKE_ALARM))
+ return -EPERM;
+
--- /dev/null
+From fbb60fe35ad579b511de8604b06a30b43846473b Mon Sep 17 00:00:00 2001
+From: Jason Wang <jasowang@redhat.com>
+Date: Mon, 12 May 2014 16:35:39 +0800
+Subject: drm/qxl: return IRQ_NONE if it was not our irq
+
+From: Jason Wang <jasowang@redhat.com>
+
+commit fbb60fe35ad579b511de8604b06a30b43846473b upstream.
+
+Return IRQ_NONE if it was not our irq. This is necessary for the case
+when qxl is sharing irq line with a device A in a crash kernel. If qxl
+is initialized before A and A's irq was raised during this gap,
+returning IRQ_HANDLED in this case will cause this irq to be raised
+again after EOI since kernel think it was handled but in fact it was
+not.
+
+Cc: Gerd Hoffmann <kraxel@redhat.com>
+Signed-off-by: Jason Wang <jasowang@redhat.com>
+Signed-off-by: Dave Airlie <airlied@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/gpu/drm/qxl/qxl_irq.c | 3 +++
+ 1 file changed, 3 insertions(+)
+
+--- a/drivers/gpu/drm/qxl/qxl_irq.c
++++ b/drivers/gpu/drm/qxl/qxl_irq.c
+@@ -33,6 +33,9 @@ irqreturn_t qxl_irq_handler(int irq, voi
+
+ pending = xchg(&qdev->ram_header->int_pending, 0);
+
++ if (!pending)
++ return IRQ_NONE;
++
+ atomic_inc(&qdev->irq_received);
+
+ if (pending & QXL_INTERRUPT_DISPLAY) {
--- /dev/null
+From 0ac66effe7fcdee55bda6d5d10d3372c95a41920 Mon Sep 17 00:00:00 2001
+From: Alex Deucher <alexander.deucher@amd.com>
+Date: Mon, 14 Jul 2014 17:57:19 -0400
+Subject: drm/radeon: avoid leaking edid data
+
+From: Alex Deucher <alexander.deucher@amd.com>
+
+commit 0ac66effe7fcdee55bda6d5d10d3372c95a41920 upstream.
+
+In some cases we fetch the edid in the detect() callback
+in order to determine what sort of monitor is connected.
+If that happens, don't fetch the edid again in the get_modes()
+callback or we will leak the edid.
+
+Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/gpu/drm/radeon/radeon_display.c | 5 +++++
+ 1 file changed, 5 insertions(+)
+
+--- a/drivers/gpu/drm/radeon/radeon_display.c
++++ b/drivers/gpu/drm/radeon/radeon_display.c
+@@ -755,6 +755,10 @@ int radeon_ddc_get_modes(struct radeon_c
+ struct radeon_device *rdev = dev->dev_private;
+ int ret = 0;
+
++ /* don't leak the edid if we already fetched it in detect() */
++ if (radeon_connector->edid)
++ goto got_edid;
++
+ /* on hw with routers, select right port */
+ if (radeon_connector->router.ddc_valid)
+ radeon_router_select_ddc_port(radeon_connector);
+@@ -794,6 +798,7 @@ int radeon_ddc_get_modes(struct radeon_c
+ radeon_connector->edid = radeon_bios_get_hardcoded_edid(rdev);
+ }
+ if (radeon_connector->edid) {
++got_edid:
+ drm_mode_connector_update_edid_property(&radeon_connector->base, radeon_connector->edid);
+ ret = drm_add_edid_modes(&radeon_connector->base, radeon_connector->edid);
+ drm_edid_to_eld(&radeon_connector->base, radeon_connector->edid);
--- /dev/null
+From 201bb62402e0227375c655446ea04fcd0acf7287 Mon Sep 17 00:00:00 2001
+From: Alex Deucher <alexander.deucher@amd.com>
+Date: Tue, 15 Jul 2014 09:48:53 -0400
+Subject: drm/radeon: set default bl level to something reasonable
+
+From: Alex Deucher <alexander.deucher@amd.com>
+
+commit 201bb62402e0227375c655446ea04fcd0acf7287 upstream.
+
+If the value in the scratch register is 0, set it to the
+max level. This fixes an issue where the console fb blanking
+code calls back into the backlight driver on unblank and then
+sets the backlight level to 0 after the driver has already
+set the mode and enabled the backlight.
+
+bugs:
+https://bugs.freedesktop.org/show_bug.cgi?id=81382
+https://bugs.freedesktop.org/show_bug.cgi?id=70207
+
+Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
+Tested-by: David Heidelberger <david.heidelberger@ixit.cz>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/gpu/drm/radeon/atombios_encoders.c | 10 +++++++---
+ 1 file changed, 7 insertions(+), 3 deletions(-)
+
+--- a/drivers/gpu/drm/radeon/atombios_encoders.c
++++ b/drivers/gpu/drm/radeon/atombios_encoders.c
+@@ -183,7 +183,6 @@ void radeon_atom_backlight_init(struct r
+ struct backlight_properties props;
+ struct radeon_backlight_privdata *pdata;
+ struct radeon_encoder_atom_dig *dig;
+- u8 backlight_level;
+ char bl_name[16];
+
+ /* Mac laptops with multiple GPUs use the gmux driver for backlight
+@@ -222,12 +221,17 @@ void radeon_atom_backlight_init(struct r
+
+ pdata->encoder = radeon_encoder;
+
+- backlight_level = radeon_atom_get_backlight_level_from_reg(rdev);
+-
+ dig = radeon_encoder->enc_priv;
+ dig->bl_dev = bd;
+
+ bd->props.brightness = radeon_atom_backlight_get_brightness(bd);
++ /* Set a reasonable default here if the level is 0 otherwise
++ * fbdev will attempt to turn the backlight on after console
++ * unblanking and it will try and restore 0 which turns the backlight
++ * off again.
++ */
++ if (bd->props.brightness == 0)
++ bd->props.brightness = RADEON_MAX_BL_LEVEL;
+ bd->props.power = FB_BLANK_UNBLANK;
+ backlight_update_status(bd);
+
--- /dev/null
+From 144cb08864ed44be52d8634ac69cd98e5efcf527 Mon Sep 17 00:00:00 2001
+From: Suravee Suthikulpanit <Suravee.Suthikulpanit@amd.com>
+Date: Tue, 15 Jul 2014 00:03:03 +0200
+Subject: irqchip: gic: Add binding probe for ARM GIC400
+
+From: Suravee Suthikulpanit <Suravee.Suthikulpanit@amd.com>
+
+commit 144cb08864ed44be52d8634ac69cd98e5efcf527 upstream.
+
+Commit 3ab72f9156bb "dt-bindings: add GIC-400 binding" added the
+"arm,gic-400" compatible string, but the corresponding IRQCHIP_DECLARE
+was never added to the gic driver.
+
+Therefore add the missing irqchip declaration for it.
+
+Signed-off-by: Suravee Suthikulpanit <Suravee.Suthikulpanit@amd.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+Removed additional empty line and adapted commit message to mark it
+as fixing an issue.
+Signed-off-by: Heiko Stuebner <heiko@sntech.de>
+Acked-by: Will Deacon <will.deacon@arm.com>
+Fixes: 3ab72f9156bb ("dt-bindings: add GIC-400 binding")
+Link: https://lkml.kernel.org/r/2621565.f5eISveXXJ@diego
+Signed-off-by: Jason Cooper <jason@lakedaemon.net>
+
+---
+ drivers/irqchip/irq-gic.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/drivers/irqchip/irq-gic.c
++++ b/drivers/irqchip/irq-gic.c
+@@ -1008,6 +1008,7 @@ int __init gic_of_init(struct device_nod
+ gic_cnt++;
+ return 0;
+ }
++IRQCHIP_DECLARE(gic_400, "arm,gic-400", gic_of_init);
+ IRQCHIP_DECLARE(cortex_a15_gic, "arm,cortex-a15-gic", gic_of_init);
+ IRQCHIP_DECLARE(cortex_a9_gic, "arm,cortex-a9-gic", gic_of_init);
+ IRQCHIP_DECLARE(cortex_a7_gic, "arm,cortex-a7-gic", gic_of_init);
--- /dev/null
+From a97e8027b1d28eafe6bafe062556c1ec926a49c6 Mon Sep 17 00:00:00 2001
+From: Matthias Brugger <matthias.bgg@gmail.com>
+Date: Thu, 3 Jul 2014 13:58:52 +0200
+Subject: irqchip: gic: Add support for cortex a7 compatible string
+
+From: Matthias Brugger <matthias.bgg@gmail.com>
+
+commit a97e8027b1d28eafe6bafe062556c1ec926a49c6 upstream.
+
+Patch 0a68214b "ARM: DT: Add binding for GIC virtualization extentions (VGIC)" added
+the "arm,cortex-a7-gic" compatible string, but the corresponding IRQCHIP_DECLARE
+was never added to the gic driver.
+
+To let real Cortex-A7 SoCs use it, add the necessary declaration to the device driver.
+
+Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
+Link: https://lkml.kernel.org/r/1404388732-28890-1-git-send-email-matthias.bgg@gmail.com
+Fixes: 0a68214b76ca ("ARM: DT: Add binding for GIC virtualization extentions (VGIC)")
+Signed-off-by: Jason Cooper <jason@lakedaemon.net>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/irqchip/irq-gic.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/drivers/irqchip/irq-gic.c
++++ b/drivers/irqchip/irq-gic.c
+@@ -1010,6 +1010,7 @@ int __init gic_of_init(struct device_nod
+ }
+ IRQCHIP_DECLARE(cortex_a15_gic, "arm,cortex-a15-gic", gic_of_init);
+ IRQCHIP_DECLARE(cortex_a9_gic, "arm,cortex-a9-gic", gic_of_init);
++IRQCHIP_DECLARE(cortex_a7_gic, "arm,cortex-a7-gic", gic_of_init);
+ IRQCHIP_DECLARE(msm_8660_qgic, "qcom,msm-8660-qgic", gic_of_init);
+ IRQCHIP_DECLARE(msm_qgic2, "qcom,msm-qgic2", gic_of_init);
+
--- /dev/null
+From 29e697b11853d3f83b1864ae385abdad4aa2c361 Mon Sep 17 00:00:00 2001
+From: Tomasz Figa <t.figa@samsung.com>
+Date: Thu, 17 Jul 2014 17:23:44 +0200
+Subject: irqchip: gic: Fix core ID calculation when topology is read from DT
+
+From: Tomasz Figa <t.figa@samsung.com>
+
+commit 29e697b11853d3f83b1864ae385abdad4aa2c361 upstream.
+
+Certain GIC implementation, namely those found on earlier, single
+cluster, Exynos SoCs, have registers mapped without per-CPU banking,
+which means that the driver needs to use different offset for each CPU.
+
+Currently the driver calculates the offset by multiplying value returned
+by cpu_logical_map() by CPU offset parsed from DT. This is correct when
+CPU topology is not specified in DT and aforementioned function returns
+core ID alone. However when DT contains CPU topology, the function
+changes to return cluster ID as well, which is non-zero on mentioned
+SoCs and so breaks the calculation in GIC driver.
+
+This patch fixes this by masking out cluster ID in CPU offset
+calculation so that only core ID is considered. Multi-cluster Exynos
+SoCs already have banked GIC implementations, so this simple fix should
+be enough.
+
+Reported-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
+Reported-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
+Signed-off-by: Tomasz Figa <t.figa@samsung.com>
+Fixes: db0d4db22a78d ("ARM: gic: allow GIC to support non-banked setups")
+Link: https://lkml.kernel.org/r/1405610624-18722-1-git-send-email-t.figa@samsung.com
+Signed-off-by: Jason Cooper <jason@lakedaemon.net>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/irqchip/irq-gic.c | 5 ++++-
+ 1 file changed, 4 insertions(+), 1 deletion(-)
+
+--- a/drivers/irqchip/irq-gic.c
++++ b/drivers/irqchip/irq-gic.c
+@@ -42,6 +42,7 @@
+ #include <linux/irqchip/chained_irq.h>
+ #include <linux/irqchip/arm-gic.h>
+
++#include <asm/cputype.h>
+ #include <asm/irq.h>
+ #include <asm/exception.h>
+ #include <asm/smp_plat.h>
+@@ -903,7 +904,9 @@ void __init gic_init_bases(unsigned int
+ }
+
+ for_each_possible_cpu(cpu) {
+- unsigned long offset = percpu_offset * cpu_logical_map(cpu);
++ u32 mpidr = cpu_logical_map(cpu);
++ u32 core_id = MPIDR_AFFINITY_LEVEL(mpidr, 0);
++ unsigned long offset = percpu_offset * core_id;
+ *per_cpu_ptr(gic->dist_base.percpu_base, cpu) = dist_base + offset;
+ *per_cpu_ptr(gic->cpu_base.percpu_base, cpu) = cpu_base + offset;
+ }
--- /dev/null
+From 6938ad40cb97a52d88a763008935340729a4acc7 Mon Sep 17 00:00:00 2001
+From: Ted Juan <ted.juan@gmail.com>
+Date: Fri, 20 Jun 2014 17:32:05 +0800
+Subject: mtd: devices: elm: fix elm_context_save() and elm_context_restore() functions
+
+From: Ted Juan <ted.juan@gmail.com>
+
+commit 6938ad40cb97a52d88a763008935340729a4acc7 upstream.
+
+These two function's switch case lack the 'break' that make them always
+return error.
+
+Signed-off-by: Ted Juan <ted.juan@gmail.com>
+Acked-by: Pekon Gupta <pekon@ti.com>
+Signed-off-by: Brian Norris <computersforpeace@gmail.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/mtd/devices/elm.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+--- a/drivers/mtd/devices/elm.c
++++ b/drivers/mtd/devices/elm.c
+@@ -428,6 +428,7 @@ static int elm_context_save(struct elm_i
+ ELM_SYNDROME_FRAGMENT_1 + offset);
+ regs->elm_syndrome_fragment_0[i] = elm_read_reg(info,
+ ELM_SYNDROME_FRAGMENT_0 + offset);
++ break;
+ default:
+ return -EINVAL;
+ }
+@@ -466,6 +467,7 @@ static int elm_context_restore(struct el
+ regs->elm_syndrome_fragment_1[i]);
+ elm_write_reg(info, ELM_SYNDROME_FRAGMENT_0 + offset,
+ regs->elm_syndrome_fragment_0[i]);
++ break;
+ default:
+ return -EINVAL;
+ }
--- /dev/null
+From d76744a93246eccdca1106037e8ee29debf48277 Mon Sep 17 00:00:00 2001
+From: Amitkumar Karwar <akarwar@marvell.com>
+Date: Fri, 20 Jun 2014 11:45:25 -0700
+Subject: mwifiex: fix Tx timeout issue
+
+From: Amitkumar Karwar <akarwar@marvell.com>
+
+commit d76744a93246eccdca1106037e8ee29debf48277 upstream.
+
+https://bugzilla.kernel.org/show_bug.cgi?id=70191
+https://bugzilla.kernel.org/show_bug.cgi?id=77581
+
+It is observed that sometimes Tx packet is downloaded without
+adding driver's txpd header. This results in firmware parsing
+garbage data as packet length. Sometimes firmware is unable
+to read the packet if length comes out as invalid. This stops
+further traffic and timeout occurs.
+
+The root cause is uninitialized fields in tx_info(skb->cb) of
+packet used to get garbage values. In this case if
+MWIFIEX_BUF_FLAG_REQUEUED_PKT flag is mistakenly set, txpd
+header was skipped. This patch makes sure that tx_info is
+correctly initialized to fix the problem.
+
+Reported-by: Andrew Wiley <wiley.andrew.j@gmail.com>
+Reported-by: Linus Gasser <list@markas-al-nour.org>
+Reported-by: Michael Hirsch <hirsch@teufel.de>
+Tested-by: Xinming Hu <huxm@marvell.com>
+Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
+Signed-off-by: Maithili Hinge <maithili@marvell.com>
+Signed-off-by: Avinash Patil <patila@marvell.com>
+Signed-off-by: Bing Zhao <bzhao@marvell.com>
+Signed-off-by: John W. Linville <linville@tuxdriver.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/net/wireless/mwifiex/main.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/drivers/net/wireless/mwifiex/main.c
++++ b/drivers/net/wireless/mwifiex/main.c
+@@ -646,6 +646,7 @@ mwifiex_hard_start_xmit(struct sk_buff *
+ }
+
+ tx_info = MWIFIEX_SKB_TXCB(skb);
++ memset(tx_info, 0, sizeof(*tx_info));
+ tx_info->bss_num = priv->bss_num;
+ tx_info->bss_type = priv->bss_type;
+ tx_info->pkt_len = skb->len;
--- /dev/null
+From 1f9a7268c67f0290837aada443d28fd953ddca90 Mon Sep 17 00:00:00 2001
+From: Jiri Olsa <jolsa@redhat.com>
+Date: Tue, 24 Jun 2014 10:20:25 +0200
+Subject: perf: Do not allow optimized switch for non-cloned events
+
+From: Jiri Olsa <jolsa@redhat.com>
+
+commit 1f9a7268c67f0290837aada443d28fd953ddca90 upstream.
+
+The context check in perf_event_context_sched_out allows
+non-cloned context to be part of the optimized schedule
+out switch.
+
+This could move non-cloned context into another workload
+child. Once this child exits, the context is closed and
+leaves all original (parent) events in closed state.
+
+Any other new cloned event will have closed state and not
+measure anything. And probably causing other odd bugs.
+
+Signed-off-by: Jiri Olsa <jolsa@kernel.org>
+Signed-off-by: Peter Zijlstra <peterz@infradead.org>
+Cc: Arnaldo Carvalho de Melo <acme@kernel.org>
+Cc: Paul Mackerras <paulus@samba.org>
+Cc: Frederic Weisbecker <fweisbec@gmail.com>
+Cc: Namhyung Kim <namhyung@kernel.org>
+Cc: Paul Mackerras <paulus@samba.org>
+Cc: Corey Ashford <cjashfor@linux.vnet.ibm.com>
+Cc: David Ahern <dsahern@gmail.com>
+Cc: Jiri Olsa <jolsa@redhat.com>
+Cc: Linus Torvalds <torvalds@linux-foundation.org>
+Link: http://lkml.kernel.org/r/1403598026-2310-2-git-send-email-jolsa@kernel.org
+Signed-off-by: Ingo Molnar <mingo@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ kernel/events/core.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/kernel/events/core.c
++++ b/kernel/events/core.c
+@@ -2311,7 +2311,7 @@ static void perf_event_context_sched_out
+ next_parent = rcu_dereference(next_ctx->parent_ctx);
+
+ /* If neither context have a parent context; they cannot be clones. */
+- if (!parent && !next_parent)
++ if (!parent || !next_parent)
+ goto unlock;
+
+ if (next_parent == ctx || next_ctx == parent || next_parent == parent) {
--- /dev/null
+From b292d7a10487aee6e74b1c18b8d95b92f40d4a4f Mon Sep 17 00:00:00 2001
+From: HATAYAMA Daisuke <d.hatayama@jp.fujitsu.com>
+Date: Wed, 25 Jun 2014 10:09:07 +0900
+Subject: perf/x86/intel: ignore CondChgd bit to avoid false NMI handling
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: HATAYAMA Daisuke <d.hatayama@jp.fujitsu.com>
+
+commit b292d7a10487aee6e74b1c18b8d95b92f40d4a4f upstream.
+
+Currently, any NMI is falsely handled by a NMI handler of NMI watchdog
+if CondChgd bit in MSR_CORE_PERF_GLOBAL_STATUS MSR is set.
+
+For example, we use external NMI to make system panic to get crash
+dump, but in this case, the external NMI is falsely handled do to the
+issue.
+
+This commit deals with the issue simply by ignoring CondChgd bit.
+
+Here is explanation in detail.
+
+On x86 NMI watchdog uses performance monitoring feature to
+periodically signal NMI each time performance counter gets overflowed.
+
+intel_pmu_handle_irq() is called as a NMI_LOCAL handler from a NMI
+handler of NMI watchdog, perf_event_nmi_handler(). It identifies an
+owner of a given NMI by looking at overflow status bits in
+MSR_CORE_PERF_GLOBAL_STATUS MSR. If some of the bits are set, then it
+handles the given NMI as its own NMI.
+
+The problem is that the intel_pmu_handle_irq() doesn't distinguish
+CondChgd bit from other bits. Unlike the other status bits, CondChgd
+bit doesn't represent overflow status for performance counters. Thus,
+CondChgd bit cannot be thought of as a mark indicating a given NMI is
+NMI watchdog's.
+
+As a result, if CondChgd bit is set, any NMI is falsely handled by the
+NMI handler of NMI watchdog. Also, if type of the falsely handled NMI
+is either NMI_UNKNOWN, NMI_SERR or NMI_IO_CHECK, the corresponding
+action is never performed until CondChgd bit is cleared.
+
+I noticed this behavior on systems with Ivy Bridge processors: Intel
+Xeon CPU E5-2630 v2 and Intel Xeon CPU E7-8890 v2. On both systems,
+CondChgd bit in MSR_CORE_PERF_GLOBAL_STATUS MSR has already been set
+in the beginning at boot. Then the CondChgd bit is immediately cleared
+by next wrmsr to MSR_CORE_PERF_GLOBAL_CTRL MSR and appears to remain
+0.
+
+On the other hand, on older processors such as Nehalem, Xeon E7540,
+CondChgd bit is not set in the beginning at boot.
+
+I'm not sure about exact behavior of CondChgd bit, in particular when
+this bit is set. Although I read Intel System Programmer's Manual to
+figure out that, the descriptions I found are:
+
+ In 18.9.1:
+
+ "The MSR_PERF_GLOBAL_STATUS MSR also provides a ¡sticky bit¢ to
+ indicate changes to the state of performancmonitoring hardware"
+
+ In Table 35-2 IA-32 Architectural MSRs
+
+ 63 CondChg: status bits of this register has changed.
+
+These are different from the bahviour I see on the actual system as I
+explained above.
+
+At least, I think ignoring CondChgd bit should be enough for NMI
+watchdog perspective.
+
+Signed-off-by: HATAYAMA Daisuke <d.hatayama@jp.fujitsu.com>
+Acked-by: Don Zickus <dzickus@redhat.com>
+Signed-off-by: Peter Zijlstra <peterz@infradead.org>
+Cc: Arnaldo Carvalho de Melo <acme@kernel.org>
+Cc: Linus Torvalds <torvalds@linux-foundation.org>
+Cc: linux-kernel@vger.kernel.org
+Link: http://lkml.kernel.org/r/20140625.103503.409316067.d.hatayama@jp.fujitsu.com
+Signed-off-by: Ingo Molnar <mingo@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/x86/kernel/cpu/perf_event_intel.c | 9 +++++++++
+ 1 file changed, 9 insertions(+)
+
+--- a/arch/x86/kernel/cpu/perf_event_intel.c
++++ b/arch/x86/kernel/cpu/perf_event_intel.c
+@@ -1383,6 +1383,15 @@ again:
+ intel_pmu_lbr_read();
+
+ /*
++ * CondChgd bit 63 doesn't mean any overflow status. Ignore
++ * and clear the bit.
++ */
++ if (__test_and_clear_bit(63, (unsigned long *)&status)) {
++ if (!status)
++ goto done;
++ }
++
++ /*
+ * PEBS overflow sets bit 62 in the global status register
+ */
+ if (__test_and_clear_bit(62, (unsigned long *)&status)) {
--- /dev/null
+From 97b8ee845393701edc06e27ccec2876ff9596019 Mon Sep 17 00:00:00 2001
+From: Martin Lau <kafai@fb.com>
+Date: Mon, 9 Jun 2014 23:06:42 -0700
+Subject: ring-buffer: Fix polling on trace_pipe
+
+From: Martin Lau <kafai@fb.com>
+
+commit 97b8ee845393701edc06e27ccec2876ff9596019 upstream.
+
+ring_buffer_poll_wait() should always put the poll_table to its wait_queue
+even there is immediate data available. Otherwise, the following epoll and
+read sequence will eventually hang forever:
+
+1. Put some data to make the trace_pipe ring_buffer read ready first
+2. epoll_ctl(efd, EPOLL_CTL_ADD, trace_pipe_fd, ee)
+3. epoll_wait()
+4. read(trace_pipe_fd) till EAGAIN
+5. Add some more data to the trace_pipe ring_buffer
+6. epoll_wait() -> this epoll_wait() will block forever
+
+~ During the epoll_ctl(efd, EPOLL_CTL_ADD,...) call in step 2,
+ ring_buffer_poll_wait() returns immediately without adding poll_table,
+ which has poll_table->_qproc pointing to ep_poll_callback(), to its
+ wait_queue.
+~ During the epoll_wait() call in step 3 and step 6,
+ ring_buffer_poll_wait() cannot add ep_poll_callback() to its wait_queue
+ because the poll_table->_qproc is NULL and it is how epoll works.
+~ When there is new data available in step 6, ring_buffer does not know
+ it has to call ep_poll_callback() because it is not in its wait queue.
+ Hence, block forever.
+
+Other poll implementation seems to call poll_wait() unconditionally as the very
+first thing to do. For example, tcp_poll() in tcp.c.
+
+Link: http://lkml.kernel.org/p/20140610060637.GA14045@devbig242.prn2.facebook.com
+
+Fixes: 2a2cc8f7c4d0 "ftrace: allow the event pipe to be polled"
+Reviewed-by: Chris Mason <clm@fb.com>
+Signed-off-by: Martin Lau <kafai@fb.com>
+Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ kernel/trace/ring_buffer.c | 4 ----
+ 1 file changed, 4 deletions(-)
+
+--- a/kernel/trace/ring_buffer.c
++++ b/kernel/trace/ring_buffer.c
+@@ -616,10 +616,6 @@ int ring_buffer_poll_wait(struct ring_bu
+ struct ring_buffer_per_cpu *cpu_buffer;
+ struct rb_irq_work *work;
+
+- if ((cpu == RING_BUFFER_ALL_CPUS && !ring_buffer_empty(buffer)) ||
+- (cpu != RING_BUFFER_ALL_CPUS && !ring_buffer_empty_cpu(buffer, cpu)))
+- return POLLIN | POLLRDNORM;
+-
+ if (cpu == RING_BUFFER_ALL_CPUS)
+ work = &buffer->irq_work;
+ else {
dns_resolver-assure-that-dns_query-result-is-null-terminated.patch
dns_resolver-null-terminate-the-right-string.patch
ipv4-fix-buffer-overflow-in-ip_options_compile.patch
+perf-do-not-allow-optimized-switch-for-non-cloned-events.patch
+perf-x86-intel-ignore-condchgd-bit-to-avoid-false-nmi-handling.patch
+mwifiex-fix-tx-timeout-issue.patch
+ring-buffer-fix-polling-on-trace_pipe.patch
+irqchip-gic-add-support-for-cortex-a7-compatible-string.patch
+irqchip-gic-add-binding-probe-for-arm-gic400.patch
+irqchip-gic-fix-core-id-calculation-when-topology-is-read-from-dt.patch
+drm-radeon-set-default-bl-level-to-something-reasonable.patch
+drm-qxl-return-irq_none-if-it-was-not-our-irq.patch
+drm-radeon-avoid-leaking-edid-data.patch
+alarmtimer-fix-bug-where-relative-alarm-timers-were-treated-as-absolute.patch
+x86-tsc-fix-cpufreq-lockup.patch
+mtd-devices-elm-fix-elm_context_save-and-elm_context_restore-functions.patch
--- /dev/null
+From 3896c329df8092661dac80f55a8c3f60136fd61a Mon Sep 17 00:00:00 2001
+From: Peter Zijlstra <peterz@infradead.org>
+Date: Tue, 24 Jun 2014 14:48:19 +0200
+Subject: x86, tsc: Fix cpufreq lockup
+
+From: Peter Zijlstra <peterz@infradead.org>
+
+commit 3896c329df8092661dac80f55a8c3f60136fd61a upstream.
+
+Mauro reported that his AMD X2 using the powernow-k8 cpufreq driver
+locked up when doing cpu hotplug.
+
+Because we called set_cyc2ns_scale() from the time_cpufreq_notifier()
+unconditionally, it gets called multiple times for each freq change,
+instead of only the once, when the tsc_khz value actually changes.
+
+Because it gets called more than once, we run out of cyc2ns data slots
+and stall, waiting for a free one, but because we're half way offline,
+there's no consumers to free slots.
+
+By placing the call inside the condition that actually changes tsc_khz
+we avoid superfluous calls and avoid the problem.
+
+Reported-by: Mauro <registosites@hotmail.com>
+Tested-by: Mauro <registosites@hotmail.com>
+Fixes: 20d1c86a5776 ("sched/clock, x86: Rewrite cyc2ns() to avoid the need to disable IRQs")
+Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
+Cc: Viresh Kumar <viresh.kumar@linaro.org>
+Cc: Bin Gao <bin.gao@intel.com>
+Cc: Linus Torvalds <torvalds@linux-foundation.org>
+Cc: Mika Westerberg <mika.westerberg@linux.intel.com>
+Cc: Paul Gortmaker <paul.gortmaker@windriver.com>
+Cc: Stefani Seibold <stefani@seibold.net>
+Cc: linux-kernel@vger.kernel.org
+Signed-off-by: Peter Zijlstra <peterz@infradead.org>
+Signed-off-by: Ingo Molnar <mingo@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/x86/kernel/tsc.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/arch/x86/kernel/tsc.c
++++ b/arch/x86/kernel/tsc.c
+@@ -921,9 +921,9 @@ static int time_cpufreq_notifier(struct
+ tsc_khz = cpufreq_scale(tsc_khz_ref, ref_freq, freq->new);
+ if (!(freq->flags & CPUFREQ_CONST_LOOPS))
+ mark_tsc_unstable("cpufreq changes");
+- }
+
+- set_cyc2ns_scale(tsc_khz, freq->cpu);
++ set_cyc2ns_scale(tsc_khz, freq->cpu);
++ }
+
+ return 0;
+ }
projects / thirdparty / kernel / stable-queue.git / commitdiff
