From: Greg Kroah-Hartman Date: Sat, 26 Jul 2014 17:57:58 +0000 (-0700) Subject: 3.14-stable patches X-Git-Tag: v3.4.100~10 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=309b02ea0f4e7dbbd898fc2b7e2d3cd99da6cb3a;p=thirdparty%2Fkernel%2Fstable-queue.git 3.14-stable patches added patches: alarmtimer-fix-bug-where-relative-alarm-timers-were-treated-as-absolute.patch drm-qxl-return-irq_none-if-it-was-not-our-irq.patch drm-radeon-avoid-leaking-edid-data.patch drm-radeon-set-default-bl-level-to-something-reasonable.patch irqchip-gic-add-binding-probe-for-arm-gic400.patch irqchip-gic-add-support-for-cortex-a7-compatible-string.patch irqchip-gic-fix-core-id-calculation-when-topology-is-read-from-dt.patch mtd-devices-elm-fix-elm_context_save-and-elm_context_restore-functions.patch mwifiex-fix-tx-timeout-issue.patch perf-do-not-allow-optimized-switch-for-non-cloned-events.patch perf-x86-intel-ignore-condchgd-bit-to-avoid-false-nmi-handling.patch ring-buffer-fix-polling-on-trace_pipe.patch x86-tsc-fix-cpufreq-lockup.patch --- diff --git a/queue-3.14/alarmtimer-fix-bug-where-relative-alarm-timers-were-treated-as-absolute.patch b/queue-3.14/alarmtimer-fix-bug-where-relative-alarm-timers-were-treated-as-absolute.patch new file mode 100644 index 00000000000..484e46fc098 --- /dev/null +++ b/queue-3.14/alarmtimer-fix-bug-where-relative-alarm-timers-were-treated-as-absolute.patch @@ -0,0 +1,77 @@ +From 16927776ae757d0d132bdbfabbfe2c498342bd59 Mon Sep 17 00:00:00 2001 +From: John Stultz +Date: Mon, 7 Jul 2014 14:06:11 -0700 +Subject: alarmtimer: Fix bug where relative alarm timers were treated as absolute + +From: John Stultz + +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 +Signed-off-by: John Stultz +Cc: Thomas Gleixner +Cc: Ingo Molnar +Cc: Prarit Bhargava +Cc: Sharvil Nanavati +Link: http://lkml.kernel.org/r/1404767171-6902-1-git-send-email-john.stultz@linaro.org +Signed-off-by: Thomas Gleixner +Signed-off-by: Greg Kroah-Hartman + +--- + 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; + diff --git a/queue-3.14/drm-qxl-return-irq_none-if-it-was-not-our-irq.patch b/queue-3.14/drm-qxl-return-irq_none-if-it-was-not-our-irq.patch new file mode 100644 index 00000000000..814cb10ba59 --- /dev/null +++ b/queue-3.14/drm-qxl-return-irq_none-if-it-was-not-our-irq.patch @@ -0,0 +1,37 @@ +From fbb60fe35ad579b511de8604b06a30b43846473b Mon Sep 17 00:00:00 2001 +From: Jason Wang +Date: Mon, 12 May 2014 16:35:39 +0800 +Subject: drm/qxl: return IRQ_NONE if it was not our irq + +From: Jason Wang + +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 +Signed-off-by: Jason Wang +Signed-off-by: Dave Airlie +Signed-off-by: Greg Kroah-Hartman + +--- + 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) { diff --git a/queue-3.14/drm-radeon-avoid-leaking-edid-data.patch b/queue-3.14/drm-radeon-avoid-leaking-edid-data.patch new file mode 100644 index 00000000000..da42f1e3918 --- /dev/null +++ b/queue-3.14/drm-radeon-avoid-leaking-edid-data.patch @@ -0,0 +1,42 @@ +From 0ac66effe7fcdee55bda6d5d10d3372c95a41920 Mon Sep 17 00:00:00 2001 +From: Alex Deucher +Date: Mon, 14 Jul 2014 17:57:19 -0400 +Subject: drm/radeon: avoid leaking edid data + +From: Alex Deucher + +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 +Signed-off-by: Greg Kroah-Hartman + +--- + 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); diff --git a/queue-3.14/drm-radeon-set-default-bl-level-to-something-reasonable.patch b/queue-3.14/drm-radeon-set-default-bl-level-to-something-reasonable.patch new file mode 100644 index 00000000000..0b725d0c27c --- /dev/null +++ b/queue-3.14/drm-radeon-set-default-bl-level-to-something-reasonable.patch @@ -0,0 +1,57 @@ +From 201bb62402e0227375c655446ea04fcd0acf7287 Mon Sep 17 00:00:00 2001 +From: Alex Deucher +Date: Tue, 15 Jul 2014 09:48:53 -0400 +Subject: drm/radeon: set default bl level to something reasonable + +From: Alex Deucher + +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 +Tested-by: David Heidelberger +Signed-off-by: Greg Kroah-Hartman + +--- + 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); + diff --git a/queue-3.14/irqchip-gic-add-binding-probe-for-arm-gic400.patch b/queue-3.14/irqchip-gic-add-binding-probe-for-arm-gic400.patch new file mode 100644 index 00000000000..25d5629ddf0 --- /dev/null +++ b/queue-3.14/irqchip-gic-add-binding-probe-for-arm-gic400.patch @@ -0,0 +1,40 @@ +From 144cb08864ed44be52d8634ac69cd98e5efcf527 Mon Sep 17 00:00:00 2001 +From: Suravee Suthikulpanit +Date: Tue, 15 Jul 2014 00:03:03 +0200 +Subject: irqchip: gic: Add binding probe for ARM GIC400 + +From: Suravee Suthikulpanit + +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 +Signed-off-by: Greg Kroah-Hartman + +Removed additional empty line and adapted commit message to mark it +as fixing an issue. +Signed-off-by: Heiko Stuebner +Acked-by: Will Deacon +Fixes: 3ab72f9156bb ("dt-bindings: add GIC-400 binding") +Link: https://lkml.kernel.org/r/2621565.f5eISveXXJ@diego +Signed-off-by: Jason Cooper + +--- + 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); diff --git a/queue-3.14/irqchip-gic-add-support-for-cortex-a7-compatible-string.patch b/queue-3.14/irqchip-gic-add-support-for-cortex-a7-compatible-string.patch new file mode 100644 index 00000000000..b9807f99b3c --- /dev/null +++ b/queue-3.14/irqchip-gic-add-support-for-cortex-a7-compatible-string.patch @@ -0,0 +1,35 @@ +From a97e8027b1d28eafe6bafe062556c1ec926a49c6 Mon Sep 17 00:00:00 2001 +From: Matthias Brugger +Date: Thu, 3 Jul 2014 13:58:52 +0200 +Subject: irqchip: gic: Add support for cortex a7 compatible string + +From: Matthias Brugger + +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 +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 +Signed-off-by: Greg Kroah-Hartman + +--- + 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); + diff --git a/queue-3.14/irqchip-gic-fix-core-id-calculation-when-topology-is-read-from-dt.patch b/queue-3.14/irqchip-gic-fix-core-id-calculation-when-topology-is-read-from-dt.patch new file mode 100644 index 00000000000..d2c87b02fab --- /dev/null +++ b/queue-3.14/irqchip-gic-fix-core-id-calculation-when-topology-is-read-from-dt.patch @@ -0,0 +1,58 @@ +From 29e697b11853d3f83b1864ae385abdad4aa2c361 Mon Sep 17 00:00:00 2001 +From: Tomasz Figa +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 + +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 +Reported-by: Bartlomiej Zolnierkiewicz +Signed-off-by: Tomasz Figa +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 +Signed-off-by: Greg Kroah-Hartman + +--- + 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 + #include + ++#include + #include + #include + #include +@@ -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; + } diff --git a/queue-3.14/mtd-devices-elm-fix-elm_context_save-and-elm_context_restore-functions.patch b/queue-3.14/mtd-devices-elm-fix-elm_context_save-and-elm_context_restore-functions.patch new file mode 100644 index 00000000000..63e30911f9b --- /dev/null +++ b/queue-3.14/mtd-devices-elm-fix-elm_context_save-and-elm_context_restore-functions.patch @@ -0,0 +1,39 @@ +From 6938ad40cb97a52d88a763008935340729a4acc7 Mon Sep 17 00:00:00 2001 +From: Ted Juan +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 + +commit 6938ad40cb97a52d88a763008935340729a4acc7 upstream. + +These two function's switch case lack the 'break' that make them always +return error. + +Signed-off-by: Ted Juan +Acked-by: Pekon Gupta +Signed-off-by: Brian Norris +Signed-off-by: Greg Kroah-Hartman + +--- + 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; + } diff --git a/queue-3.14/mwifiex-fix-tx-timeout-issue.patch b/queue-3.14/mwifiex-fix-tx-timeout-issue.patch new file mode 100644 index 00000000000..0180f2305a8 --- /dev/null +++ b/queue-3.14/mwifiex-fix-tx-timeout-issue.patch @@ -0,0 +1,49 @@ +From d76744a93246eccdca1106037e8ee29debf48277 Mon Sep 17 00:00:00 2001 +From: Amitkumar Karwar +Date: Fri, 20 Jun 2014 11:45:25 -0700 +Subject: mwifiex: fix Tx timeout issue + +From: Amitkumar Karwar + +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 +Reported-by: Linus Gasser +Reported-by: Michael Hirsch +Tested-by: Xinming Hu +Signed-off-by: Amitkumar Karwar +Signed-off-by: Maithili Hinge +Signed-off-by: Avinash Patil +Signed-off-by: Bing Zhao +Signed-off-by: John W. Linville +Signed-off-by: Greg Kroah-Hartman + +--- + 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; diff --git a/queue-3.14/perf-do-not-allow-optimized-switch-for-non-cloned-events.patch b/queue-3.14/perf-do-not-allow-optimized-switch-for-non-cloned-events.patch new file mode 100644 index 00000000000..d679e8208fe --- /dev/null +++ b/queue-3.14/perf-do-not-allow-optimized-switch-for-non-cloned-events.patch @@ -0,0 +1,50 @@ +From 1f9a7268c67f0290837aada443d28fd953ddca90 Mon Sep 17 00:00:00 2001 +From: Jiri Olsa +Date: Tue, 24 Jun 2014 10:20:25 +0200 +Subject: perf: Do not allow optimized switch for non-cloned events + +From: Jiri Olsa + +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 +Signed-off-by: Peter Zijlstra +Cc: Arnaldo Carvalho de Melo +Cc: Paul Mackerras +Cc: Frederic Weisbecker +Cc: Namhyung Kim +Cc: Paul Mackerras +Cc: Corey Ashford +Cc: David Ahern +Cc: Jiri Olsa +Cc: Linus Torvalds +Link: http://lkml.kernel.org/r/1403598026-2310-2-git-send-email-jolsa@kernel.org +Signed-off-by: Ingo Molnar +Signed-off-by: Greg Kroah-Hartman + +--- + 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) { diff --git a/queue-3.14/perf-x86-intel-ignore-condchgd-bit-to-avoid-false-nmi-handling.patch b/queue-3.14/perf-x86-intel-ignore-condchgd-bit-to-avoid-false-nmi-handling.patch new file mode 100644 index 00000000000..993199ec3f4 --- /dev/null +++ b/queue-3.14/perf-x86-intel-ignore-condchgd-bit-to-avoid-false-nmi-handling.patch @@ -0,0 +1,104 @@ +From b292d7a10487aee6e74b1c18b8d95b92f40d4a4f Mon Sep 17 00:00:00 2001 +From: HATAYAMA Daisuke +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 + +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 +Acked-by: Don Zickus +Signed-off-by: Peter Zijlstra +Cc: Arnaldo Carvalho de Melo +Cc: Linus Torvalds +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 +Signed-off-by: Greg Kroah-Hartman + +--- + 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)) { diff --git a/queue-3.14/ring-buffer-fix-polling-on-trace_pipe.patch b/queue-3.14/ring-buffer-fix-polling-on-trace_pipe.patch new file mode 100644 index 00000000000..b9dfab3cf44 --- /dev/null +++ b/queue-3.14/ring-buffer-fix-polling-on-trace_pipe.patch @@ -0,0 +1,59 @@ +From 97b8ee845393701edc06e27ccec2876ff9596019 Mon Sep 17 00:00:00 2001 +From: Martin Lau +Date: Mon, 9 Jun 2014 23:06:42 -0700 +Subject: ring-buffer: Fix polling on trace_pipe + +From: Martin Lau + +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 +Signed-off-by: Martin Lau +Signed-off-by: Steven Rostedt +Signed-off-by: Greg Kroah-Hartman + +--- + 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 { diff --git a/queue-3.14/series b/queue-3.14/series index f4aeb2c9502..ec9be573938 100644 --- a/queue-3.14/series +++ b/queue-3.14/series @@ -62,3 +62,16 @@ net-huawei_cdc_ncm-add-subclass-3-devices.patch 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 diff --git a/queue-3.14/x86-tsc-fix-cpufreq-lockup.patch b/queue-3.14/x86-tsc-fix-cpufreq-lockup.patch new file mode 100644 index 00000000000..3b4f74cf984 --- /dev/null +++ b/queue-3.14/x86-tsc-fix-cpufreq-lockup.patch @@ -0,0 +1,56 @@ +From 3896c329df8092661dac80f55a8c3f60136fd61a Mon Sep 17 00:00:00 2001 +From: Peter Zijlstra +Date: Tue, 24 Jun 2014 14:48:19 +0200 +Subject: x86, tsc: Fix cpufreq lockup + +From: Peter Zijlstra + +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 +Tested-by: Mauro +Fixes: 20d1c86a5776 ("sched/clock, x86: Rewrite cyc2ns() to avoid the need to disable IRQs") +Cc: "Rafael J. Wysocki" +Cc: Viresh Kumar +Cc: Bin Gao +Cc: Linus Torvalds +Cc: Mika Westerberg +Cc: Paul Gortmaker +Cc: Stefani Seibold +Cc: linux-kernel@vger.kernel.org +Signed-off-by: Peter Zijlstra +Signed-off-by: Ingo Molnar +Signed-off-by: Greg Kroah-Hartman + +--- + 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; + }