From 0f4eeea06e7cb215ebd75e6d0d983292baa2319e Mon Sep 17 00:00:00 2001 From: Greg Kroah-Hartman Date: Sat, 26 Jul 2014 10:54:44 -0700 Subject: [PATCH] 3.4-stable patches added patches: alarmtimer-fix-bug-where-relative-alarm-timers-were-treated-as-absolute.patch drm-radeon-avoid-leaking-edid-data.patch mwifiex-fix-tx-timeout-issue.patch perf-x86-intel-ignore-condchgd-bit-to-avoid-false-nmi-handling.patch --- ...larm-timers-were-treated-as-absolute.patch | 77 +++++++++++++ .../drm-radeon-avoid-leaking-edid-data.patch | 42 +++++++ queue-3.4/mwifiex-fix-tx-timeout-issue.patch | 49 +++++++++ ...chgd-bit-to-avoid-false-nmi-handling.patch | 104 ++++++++++++++++++ queue-3.4/series | 4 + 5 files changed, 276 insertions(+) create mode 100644 queue-3.4/alarmtimer-fix-bug-where-relative-alarm-timers-were-treated-as-absolute.patch create mode 100644 queue-3.4/drm-radeon-avoid-leaking-edid-data.patch create mode 100644 queue-3.4/mwifiex-fix-tx-timeout-issue.patch create mode 100644 queue-3.4/perf-x86-intel-ignore-condchgd-bit-to-avoid-false-nmi-handling.patch diff --git a/queue-3.4/alarmtimer-fix-bug-where-relative-alarm-timers-were-treated-as-absolute.patch b/queue-3.4/alarmtimer-fix-bug-where-relative-alarm-timers-were-treated-as-absolute.patch new file mode 100644 index 00000000000..c6dd7ff114b --- /dev/null +++ b/queue-3.4/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 +@@ -569,9 +569,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); + +@@ -581,8 +586,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; + } + +@@ -714,6 +727,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.4/drm-radeon-avoid-leaking-edid-data.patch b/queue-3.4/drm-radeon-avoid-leaking-edid-data.patch new file mode 100644 index 00000000000..0c69be92a44 --- /dev/null +++ b/queue-3.4/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 +@@ -709,6 +709,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); +@@ -748,6 +752,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.4/mwifiex-fix-tx-timeout-issue.patch b/queue-3.4/mwifiex-fix-tx-timeout-issue.patch new file mode 100644 index 00000000000..d45e827fea9 --- /dev/null +++ b/queue-3.4/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 +@@ -457,6 +457,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; + mwifiex_fill_buffer(skb); diff --git a/queue-3.4/perf-x86-intel-ignore-condchgd-bit-to-avoid-false-nmi-handling.patch b/queue-3.4/perf-x86-intel-ignore-condchgd-bit-to-avoid-false-nmi-handling.patch new file mode 100644 index 00000000000..ff23e98a7b2 --- /dev/null +++ b/queue-3.4/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 +@@ -1070,6 +1070,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.4/series b/queue-3.4/series index 68986d66514..1cd20a8c969 100644 --- a/queue-3.4/series +++ b/queue-3.4/series @@ -15,3 +15,7 @@ sunvnet-clean-up-objects-created-in-vnet_new-on-vnet_exit.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-x86-intel-ignore-condchgd-bit-to-avoid-false-nmi-handling.patch +mwifiex-fix-tx-timeout-issue.patch +drm-radeon-avoid-leaking-edid-data.patch +alarmtimer-fix-bug-where-relative-alarm-timers-were-treated-as-absolute.patch -- 2.47.3