--- /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
+@@ -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;
+
--- /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
+@@ -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);
--- /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
+@@ -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);
--- /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
+@@ -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)) {
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
projects / thirdparty / kernel / stable-queue.git / commitdiff
