commit 81a464838675307c9fc7909fc840f248ed2caed5 Author: Greg Kroah-Hartman Date: Thu Jul 25 15:16:45 2013 -0700 Linux 3.10.3 commit fc82a11a9ce5ddc1cc49ac7bb2a099b9b18b85c0 Author: Steven Rostedt (Red Hat) Date: Tue Jul 2 15:30:53 2013 -0400 tracing: Add trace_array_get/put() to event handling commit 8e2e2fa47129532a30cff6c25a47078dc97d9260 upstream. Commit a695cb58162 "tracing: Prevent deleting instances when they are being read" tried to fix a race between deleting a trace instance and reading contents of a trace file. But it wasn't good enough. The following could crash the kernel: # cd /sys/kernel/debug/tracing/instances # ( while :; do mkdir foo; rmdir foo; done ) & # ( while :; do echo 1 > foo/events/sched/sched_switch 2> /dev/null; done ) & Luckily this can only be done by root user, but it should be fixed regardless. The problem is that a delete of the file can happen after the write to the event is opened, but before the enabling happens. The solution is to make sure the trace_array is available before succeeding in opening for write, and incerment the ref counter while opened. Now the instance can be deleted when the events are writing to the buffer, but the deletion of the instance will disable all events before the instance is actually deleted. Reported-by: Alexander Lam Signed-off-by: Steven Rostedt Signed-off-by: Greg Kroah-Hartman commit 68cebd265c91873277cf100e7ac1d047c6598ddf Author: Steven Rostedt (Red Hat) Date: Tue Jul 2 14:48:23 2013 -0400 tracing: Fix race between deleting buffer and setting events commit 2a6c24afab70dbcfee49f4c76e1511eec1a3298b upstream. While analyzing the code, I discovered that there's a potential race between deleting a trace instance and setting events. There are a few races that can occur if events are being traced as the buffer is being deleted. Mostly the problem comes with freeing the descriptor used by the trace event callback. To prevent problems like this, the events are disabled before the buffer is deleted. The problem with the current solution is that the event_mutex is let go between disabling the events and freeing the files, which means that the events could be enabled again while the freeing takes place. Signed-off-by: Steven Rostedt Signed-off-by: Greg Kroah-Hartman commit 6492334c86dfb441af456337dc3217c2a430f141 Author: Steven Rostedt (Red Hat) Date: Mon Jul 1 23:34:22 2013 -0400 tracing: Get trace_array ref counts when accessing trace files commit 7b85af63034818e43aee6c1d7bf1c7c6796a9073 upstream. When a trace file is opened that may access a trace array, it must increment its ref count to prevent it from being deleted. Reported-by: Alexander Lam Signed-off-by: Steven Rostedt Signed-off-by: Greg Kroah-Hartman commit 59d8f48855856c5e2e112bab78f1b1e6a14c216b Author: Steven Rostedt (Red Hat) Date: Mon Jul 1 22:50:29 2013 -0400 tracing: Add trace_array_get/put() to handle instance refs better commit ff451961a8b2a17667a7bfa39c86fb9b351445db upstream. Commit a695cb58162 "tracing: Prevent deleting instances when they are being read" tried to fix a race between deleting a trace instance and reading contents of a trace file. But it wasn't good enough. The following could crash the kernel: # cd /sys/kernel/debug/tracing/instances # ( while :; do mkdir foo; rmdir foo; done ) & # ( while :; do cat foo/trace &> /dev/null; done ) & Luckily this can only be done by root user, but it should be fixed regardless. The problem is that a delete of the file can happen after the reader starts to open the file but before it grabs the trace_types_mutex. The solution is to validate the trace array before using it. If the trace array does not exist in the list of trace arrays, then it returns -ENODEV. There's a possibility that a trace_array could be deleted and a new one created and the open would open its file instead. But that is very minor as it will just return the data of the new trace array, it may confuse the user but it will not crash the system. As this can only be done by root anyway, the race will only occur if root is deleting what its trying to read at the same time. Reported-by: Alexander Lam Signed-off-by: Steven Rostedt Signed-off-by: Greg Kroah-Hartman commit 9713f78568d0053621530fb9cf06756394b4403c Author: Alexander Z Lam Date: Mon Jul 1 19:37:54 2013 -0700 tracing: Protect ftrace_trace_arrays list in trace_events.c commit a82274151af2b075163e3c42c828529dee311487 upstream. There are multiple places where the ftrace_trace_arrays list is accessed in trace_events.c without the trace_types_lock held. Link: http://lkml.kernel.org/r/1372732674-22726-1-git-send-email-azl@google.com Signed-off-by: Alexander Z Lam Cc: Vaibhav Nagarnaik Cc: David Sharp Cc: Alexander Z Lam Signed-off-by: Steven Rostedt Signed-off-by: Greg Kroah-Hartman commit b7f15519edb2e3c3d7d07d6a0780a4386ef23085 Author: Alexander Z Lam Date: Mon Jul 1 15:31:24 2013 -0700 tracing: Make trace_marker use the correct per-instance buffer commit 2d71619c59fac95a5415a326162fa046161b938c upstream. The trace_marker file was present for each new instance created, but it added the trace mark to the global trace buffer instead of to the instance's buffer. Link: http://lkml.kernel.org/r/1372717885-4543-2-git-send-email-azl@google.com Signed-off-by: Alexander Z Lam Cc: David Sharp Cc: Vaibhav Nagarnaik Cc: Alexander Z Lam Signed-off-by: Steven Rostedt Signed-off-by: Greg Kroah-Hartman commit 86515381237a7f3c88a4a36e3e4d32d58635b972 Author: zhangwei(Jovi) Date: Wed Apr 10 11:26:23 2013 +0800 tracing: Fix irqs-off tag display in syscall tracing commit 11034ae9c20f4057a6127fc965906417978e69b2 upstream. All syscall tracing irqs-off tags are wrong, the syscall enter entry doesn't disable irqs. [root@jovi tracing]#echo "syscalls:sys_enter_open" > set_event [root@jovi tracing]# cat trace # tracer: nop # # entries-in-buffer/entries-written: 13/13 #P:2 # # _-----=> irqs-off # / _----=> need-resched # | / _---=> hardirq/softirq # || / _--=> preempt-depth # ||| / delay # TASK-PID CPU# |||| TIMESTAMP FUNCTION # | | | |||| | | irqbalance-513 [000] d... 56115.496766: sys_open(filename: 804e1a6, flags: 0, mode: 1b6) irqbalance-513 [000] d... 56115.497008: sys_open(filename: 804e1bb, flags: 0, mode: 1b6) sendmail-771 [000] d... 56115.827982: sys_open(filename: b770e6d1, flags: 0, mode: 1b6) The reason is syscall tracing doesn't record irq_flags into buffer. The proper display is: [root@jovi tracing]#echo "syscalls:sys_enter_open" > set_event [root@jovi tracing]# cat trace # tracer: nop # # entries-in-buffer/entries-written: 14/14 #P:2 # # _-----=> irqs-off # / _----=> need-resched # | / _---=> hardirq/softirq # || / _--=> preempt-depth # ||| / delay # TASK-PID CPU# |||| TIMESTAMP FUNCTION # | | | |||| | | irqbalance-514 [001] .... 46.213921: sys_open(filename: 804e1a6, flags: 0, mode: 1b6) irqbalance-514 [001] .... 46.214160: sys_open(filename: 804e1bb, flags: 0, mode: 1b6) <...>-920 [001] .... 47.307260: sys_open(filename: 4e82a0c5, flags: 80000, mode: 0) Link: http://lkml.kernel.org/r/1365564393-10972-3-git-send-email-jovi.zhangwei@huawei.com Signed-off-by: zhangwei(Jovi) Signed-off-by: Steven Rostedt Signed-off-by: Greg Kroah-Hartman commit e6929efa3320454d9a572300a4eb97a576c7d556 Author: Steven Rostedt Date: Thu Jun 27 10:58:31 2013 -0400 tracing: Failed to create system directory commit 6e94a780374ed31b280f939d4757e8d7858dff16 upstream. Running the following: # cd /sys/kernel/debug/tracing # echo p:i do_sys_open > kprobe_events # echo p:j schedule >> kprobe_events # cat kprobe_events p:kprobes/i do_sys_open p:kprobes/j schedule # echo p:i do_sys_open >> kprobe_events # cat kprobe_events p:kprobes/j schedule p:kprobes/i do_sys_open # ls /sys/kernel/debug/tracing/events/kprobes/ enable filter j Notice that the 'i' is missing from the kprobes directory. The console produces: "Failed to create system directory kprobes" This is because kprobes passes in a allocated name for the system and the ftrace event subsystem saves off that name instead of creating a duplicate for it. But the kprobes may free the system name making the pointer to it invalid. This bug was introduced by 92edca073c37 "tracing: Use direct field, type and system names" which switched from using kstrdup() on the system name in favor of just keeping apointer to it, as the internal ftrace event system names are static and exist for the life of the computer being booted. Instead of reverting back to duplicating system names again, we can use core_kernel_data() to determine if the passed in name was allocated or static. Then use the MSB of the ref_count to be a flag to keep track if the name was allocated or not. Then we can still save from having to duplicate strings that will always exist, but still copy the ones that may be freed. Reported-by: "zhangwei(Jovi)" Reported-by: Masami Hiramatsu Tested-by: Masami Hiramatsu Signed-off-by: Steven Rostedt Signed-off-by: Greg Kroah-Hartman commit 65e303d786e20460c3d67d362f989f59944fb744 Author: Peter Zijlstra Date: Fri Jul 12 11:08:33 2013 +0200 perf: Fix perf_lock_task_context() vs RCU commit 058ebd0eba3aff16b144eabf4510ed9510e1416e upstream. Jiri managed to trigger this warning: [] ====================================================== [] [ INFO: possible circular locking dependency detected ] [] 3.10.0+ #228 Tainted: G W [] ------------------------------------------------------- [] p/6613 is trying to acquire lock: [] (rcu_node_0){..-...}, at: [] rcu_read_unlock_special+0xa7/0x250 [] [] but task is already holding lock: [] (&ctx->lock){-.-...}, at: [] perf_lock_task_context+0xd9/0x2c0 [] [] which lock already depends on the new lock. [] [] the existing dependency chain (in reverse order) is: [] [] -> #4 (&ctx->lock){-.-...}: [] -> #3 (&rq->lock){-.-.-.}: [] -> #2 (&p->pi_lock){-.-.-.}: [] -> #1 (&rnp->nocb_gp_wq[1]){......}: [] -> #0 (rcu_node_0){..-...}: Paul was quick to explain that due to preemptible RCU we cannot call rcu_read_unlock() while holding scheduler (or nested) locks when part of the read side critical section was preemptible. Therefore solve it by making the entire RCU read side non-preemptible. Also pull out the retry from under the non-preempt to play nice with RT. Reported-by: Jiri Olsa Helped-out-by: Paul E. McKenney Signed-off-by: Peter Zijlstra Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit b2412679ab3e923437e2ee109560c151c9b0cedc Author: Jiri Olsa Date: Tue Jul 9 17:44:11 2013 +0200 perf: Remove WARN_ON_ONCE() check in __perf_event_enable() for valid scenario commit 06f417968beac6e6b614e17b37d347aa6a6b1d30 upstream. The '!ctx->is_active' check has a valid scenario, so there's no need for the warning. The reason is that there's a time window between the 'ctx->is_active' check in the perf_event_enable() function and the __perf_event_enable() function having: - IRQs on - ctx->lock unlocked where the task could be killed and 'ctx' deactivated by perf_event_exit_task(), ending up with the warning below. So remove the WARN_ON_ONCE() check and add comments to explain it all. This addresses the following warning reported by Vince Weaver: [ 324.983534] ------------[ cut here ]------------ [ 324.984420] WARNING: at kernel/events/core.c:1953 __perf_event_enable+0x187/0x190() [ 324.984420] Modules linked in: [ 324.984420] CPU: 19 PID: 2715 Comm: nmi_bug_snb Not tainted 3.10.0+ #246 [ 324.984420] Hardware name: Supermicro X8DTN/X8DTN, BIOS 4.6.3 01/08/2010 [ 324.984420] 0000000000000009 ffff88043fce3ec8 ffffffff8160ea0b ffff88043fce3f00 [ 324.984420] ffffffff81080ff0 ffff8802314fdc00 ffff880231a8f800 ffff88043fcf7860 [ 324.984420] 0000000000000286 ffff880231a8f800 ffff88043fce3f10 ffffffff8108103a [ 324.984420] Call Trace: [ 324.984420] [] dump_stack+0x19/0x1b [ 324.984420] [] warn_slowpath_common+0x70/0xa0 [ 324.984420] [] warn_slowpath_null+0x1a/0x20 [ 324.984420] [] __perf_event_enable+0x187/0x190 [ 324.984420] [] remote_function+0x40/0x50 [ 324.984420] [] generic_smp_call_function_single_interrupt+0xbe/0x130 [ 324.984420] [] smp_call_function_single_interrupt+0x27/0x40 [ 324.984420] [] call_function_single_interrupt+0x6f/0x80 [ 324.984420] [] ? _raw_spin_unlock_irqrestore+0x41/0x70 [ 324.984420] [] perf_event_exit_task+0x14d/0x210 [ 324.984420] [] ? switch_task_namespaces+0x24/0x60 [ 324.984420] [] do_exit+0x2b6/0xa40 [ 324.984420] [] ? _raw_spin_unlock_irq+0x2c/0x30 [ 324.984420] [] do_group_exit+0x49/0xc0 [ 324.984420] [] get_signal_to_deliver+0x254/0x620 [ 324.984420] [] do_signal+0x57/0x5a0 [ 324.984420] [] ? __do_page_fault+0x2a4/0x4e0 [ 324.984420] [] ? retint_restore_args+0xe/0xe [ 324.984420] [] ? retint_signal+0x11/0x84 [ 324.984420] [] do_notify_resume+0x65/0x80 [ 324.984420] [] retint_signal+0x46/0x84 [ 324.984420] ---[ end trace 442ec2f04db3771a ]--- Reported-by: Vince Weaver Signed-off-by: Jiri Olsa Suggested-by: Peter Zijlstra Cc: Corey Ashford Cc: Frederic Weisbecker Cc: Ingo Molnar Cc: Namhyung Kim Cc: Paul Mackerras Cc: Arnaldo Carvalho de Melo Signed-off-by: Peter Zijlstra Link: http://lkml.kernel.org/r/1373384651-6109-2-git-send-email-jolsa@redhat.com Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit f38bac3d6d1fc1a726e4381f0423dcd85885b3d4 Author: Jiri Olsa Date: Tue Jul 9 17:44:10 2013 +0200 perf: Clone child context from parent context pmu commit 734df5ab549ca44f40de0f07af1c8803856dfb18 upstream. Currently when the child context for inherited events is created, it's based on the pmu object of the first event of the parent context. This is wrong for the following scenario: - HW context having HW and SW event - HW event got removed (closed) - SW event stays in HW context as the only event and its pmu is used to clone the child context The issue starts when the cpu context object is touched based on the pmu context object (__get_cpu_context). In this case the HW context will work with SW cpu context ending up with following WARN below. Fixing this by using parent context pmu object to clone from child context. Addresses the following warning reported by Vince Weaver: [ 2716.472065] ------------[ cut here ]------------ [ 2716.476035] WARNING: at kernel/events/core.c:2122 task_ctx_sched_out+0x3c/0x) [ 2716.476035] Modules linked in: nfsd auth_rpcgss oid_registry nfs_acl nfs locn [ 2716.476035] CPU: 0 PID: 3164 Comm: perf_fuzzer Not tainted 3.10.0-rc4 #2 [ 2716.476035] Hardware name: AOpen DE7000/nMCP7ALPx-DE R1.06 Oct.19.2012, BI2 [ 2716.476035] 0000000000000000 ffffffff8102e215 0000000000000000 ffff88011fc18 [ 2716.476035] ffff8801175557f0 0000000000000000 ffff880119fda88c ffffffff810ad [ 2716.476035] ffff880119fda880 ffffffff810af02a 0000000000000009 ffff880117550 [ 2716.476035] Call Trace: [ 2716.476035] [] ? warn_slowpath_common+0x5b/0x70 [ 2716.476035] [] ? task_ctx_sched_out+0x3c/0x5f [ 2716.476035] [] ? perf_event_exit_task+0xbf/0x194 [ 2716.476035] [] ? do_exit+0x3e7/0x90c [ 2716.476035] [] ? __do_fault+0x359/0x394 [ 2716.476035] [] ? do_group_exit+0x66/0x98 [ 2716.476035] [] ? get_signal_to_deliver+0x479/0x4ad [ 2716.476035] [] ? __perf_event_task_sched_out+0x230/0x2d1 [ 2716.476035] [] ? do_signal+0x3c/0x432 [ 2716.476035] [] ? ctx_sched_in+0x43/0x141 [ 2716.476035] [] ? perf_event_context_sched_in+0x7a/0x90 [ 2716.476035] [] ? __perf_event_task_sched_in+0x31/0x118 [ 2716.476035] [] ? mmdrop+0xd/0x1c [ 2716.476035] [] ? finish_task_switch+0x7d/0xa6 [ 2716.476035] [] ? do_notify_resume+0x20/0x5d [ 2716.476035] [] ? retint_signal+0x3d/0x78 [ 2716.476035] ---[ end trace 827178d8a5966c3d ]--- Reported-by: Vince Weaver Signed-off-by: Jiri Olsa Cc: Corey Ashford Cc: Frederic Weisbecker Cc: Ingo Molnar Cc: Namhyung Kim Cc: Paul Mackerras Cc: Arnaldo Carvalho de Melo Signed-off-by: Peter Zijlstra Link: http://lkml.kernel.org/r/1373384651-6109-1-git-send-email-jolsa@redhat.com Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit df3b055c92883b04459c54888b4bbb169ccb1b62 Author: Takashi Iwai Date: Thu Jul 11 18:02:38 2013 +0200 staging: line6: Fix unlocked snd_pcm_stop() call commit 86f0b5b86d142b9323432fef078a6cf0fb5dda74 upstream. snd_pcm_stop() must be called in the PCM substream lock context. Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit d6d10b1dceba6ed2b3d74207b2a454c2f4427785 Author: David Daney Date: Wed Jun 12 17:28:33 2013 +0000 MIPS: Octeon: Don't clobber bootloader data structures. commit d949b4fe6d23dd92b5fa48cbf7af90ca32beed2e upstream. Commit abe77f90dc (MIPS: Octeon: Add kexec and kdump support) added a bootmem region for the kernel image itself. The problem is that this is rounded up to a 0x100000 boundary, which is memory that may not be owned by the kernel. Depending on the kernel's configuration based size, this 'extra' memory may contain data passed from the bootloader to the kernel itself, which if clobbered makes the kernel crash in various ways. The fix: Quit rounding the size up, so that we only use memory assigned to the kernel. Signed-off-by: David Daney Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/5449/ Signed-off-by: Ralf Baechle Signed-off-by: Greg Kroah-Hartman commit d8724a91bc631690af241588936971214e55927e Author: Arnd Bergmann Date: Fri Jul 5 17:40:13 2013 +0200 thermal: cpu_cooling: fix stub function commit e8d39240d635ed9bcaddbec898b1c9f063c5dbb2 upstream. The function stub for cpufreq_cooling_get_level introduced in 57df81069 "Thermal: exynos: fix cooling state translation" is not syntactically correct C and needs to be fixed to avoid this error: In file included from drivers/thermal/db8500_thermal.c:20:0: include/linux/cpu_cooling.h: In function 'cpufreq_cooling_get_level': include/linux/cpu_cooling.h:57:1: error: parameter name omitted unsigned long cpufreq_cooling_get_level(unsigned int, unsigned int) ^ include/linux/cpu_cooling.h:57:1: error: parameter name omitted Signed-off-by: Arnd Bergmann Acked-by: Eduardo Valentin Cc: Zhang Rui Cc: Amit Daniel kachhap Signed-off-by: Eduardo Valentin Signed-off-by: Greg Kroah-Hartman commit 3ea8ad44cea35afc010942b448472fc993f24722 Author: Max Filippov Date: Sun Jun 9 04:52:11 2013 +0400 xtensa: adjust boot parameters address when INITIALIZE_XTENSA_MMU_INSIDE_VMLINUX is selected commit c5a771d0678f9613e9f89cf1a5bdcfa5b08b225b upstream. The virtual address of boot parameters chain is passed to the kernel via a2 register. Adjust it in case it is remapped during MMUv3 -> MMUv2 mapping change, i.e. when it is in the first 128M. Also fix interpretation of initrd and FDT addresses passed in the boot parameters: these are physical addresses. Reported-by: Baruch Siach Signed-off-by: Max Filippov Signed-off-by: Chris Zankel Signed-off-by: Greg Kroah-Hartman commit ed2f079599f3d9e5e27a516771d3d53afa7e7773 Author: Alex Williamson Date: Fri Jun 21 14:33:19 2013 -0600 iommu/amd: Only unmap large pages from the first pte commit 60d0ca3cfd199b6612bbbbf4999a3470dad38bb1 upstream. If we use a large mapping, the expectation is that only unmaps from the first pte in the superpage are supported. Unmaps from offsets into the superpage should fail (ie. return zero sized unmap). In the current code, unmapping from an offset clears the size of the full mapping starting from an offset. For instance, if we map a 16k physically contiguous range at IOVA 0x0 with a large page, then attempt to unmap 4k at offset 12k, 4 ptes are cleared (12k - 28k) and the unmap returns 16k unmapped. This potentially incorrectly clears valid mappings and confuses drivers like VFIO that use the unmap size to release pinned pages. Fix by refusing to unmap from offsets into the page. Signed-off-by: Alex Williamson Signed-off-by: Joerg Roedel Signed-off-by: Greg Kroah-Hartman commit 64dd8fc12c34e39e82b77109bb5b328ad5b24268 Author: Emil Velikov Date: Tue Jul 2 14:44:12 2013 +0100 drm/nv50-/disp: Use output specific mask in interrupt commit 378f2bcdf7c971453d11580936dc0ffe845f5880 upstream. The commit commit 476e84e126171d809f9c0b5d97137f5055f95ca8 Author: Ben Skeggs Date: Mon Feb 11 09:24:23 2013 +1000 drm/nv50-/disp: initial supervisor support for off-chip encoders changed the write mask in one of the interrupt functions for on-chip encoders, causing a regression in certain VGA dual-head setups. This commit reintroduces the mask thus resolving the regression Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=66129 Reported-and-Tested-by: Yves-Alexis CC: Ben Skeggs Signed-off-by: Emil Velikov Signed-off-by: Ben Skeggs Signed-off-by: Greg Kroah-Hartman commit 3913338881a1e4898176da0008c3df80aabdc3dd Author: Ilia Mirkin Date: Wed Jul 3 03:06:02 2013 -0400 drm/nva3/disp: Fix HDMI audio regression commit bf03d1b293cc556df53545e318110505014d805e upstream. This is the nva3 counterpart to commit beba44b17 (drm/nv84/disp: Fix HDMI audio regression). The regression happened as a result of refactoring in commit 8e9e3d2de (drm/nv84/disp: move hdmi control into core). Reported-and-tested-by: Max Baldwin Signed-off-by: Ilia Mirkin Signed-off-by: Ben Skeggs Signed-off-by: Greg Kroah-Hartman commit 5c49b1cfa41e42003b481326af66806e5f1a46b9 Author: Alex Deucher Date: Mon Jun 10 09:57:07 2013 -0400 drm/radeon: add backlight quirk for hybrid mac commit 80101790670385a85aca35ecae4b89e3f2fceecc upstream. Mac laptops with multiple GPUs apparently use the gmux driver for backlight control. Don't register a radeon backlight interface. We may need to add other pci ids for other hybrid mac laptops. Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=65377 Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit 9f7fbcd61507b130afb4ec6418ce8513295d4df4 Author: Alex Deucher Date: Fri Jun 7 10:41:03 2013 -0400 drm/radeon: fix AVI infoframe generation commit f100380ecd8287b0909d3c5694784adc46e78a4a upstream. - remove adding 2 to checksum, this is incorrect. This was incorrectly introduced in: 92db7f6c860b8190571a9dc1fcbc16d003422fe8 http://lists.freedesktop.org/archives/dri-devel/2011-December/017717.html However, the off by 2 was due to adding the version twice. From the examples in the URL above: [Rafał Miłecki][RV620] fglrx: 0x7454: 00 A8 5E 79 R600_HDMI_VIDEOINFOFRAME_0 0x7458: 00 28 00 10 R600_HDMI_VIDEOINFOFRAME_1 0x745C: 00 48 00 28 R600_HDMI_VIDEOINFOFRAME_2 0x7460: 02 00 00 48 R600_HDMI_VIDEOINFOFRAME_3 =================== (0x82 + 0x2 + 0xD) + 0x1F8 = 0x289 -0x289 = 0x77 However, the payload sum is not 0x1f8, it's 0x1f6. 00 + A8 + 5E + 00 + 00 + 28 + 00 + 10 + 00 + 48 + 00 + 28 + 00 + 48 = 0x1f6 Bits 25:24 of HDMI_VIDEOINFOFRAME_3 are the packet version, not part of the payload. So the total would be: (0x82 + 0x2 + 0xD) + 0x1f6 = 0x287 -0x287 = 0x79 - properly emit the AVI infoframe version. This was not being emitted previous which is probably what caused the issue above. This should fix blank screen when HDMI audio is enabled on certain monitors. Signed-off-by: Alex Deucher Cc: Rafał Miłecki Signed-off-by: Greg Kroah-Hartman commit ef0cfe2f8ee92be33f891c238d310abfaca7e0e3 Author: Marcin Slusarz Date: Tue Jun 11 10:50:30 2013 +0200 drm/nouveau: use vmalloc for pgt allocation commit d005f51eb93d71cd40ebd11dd377453fa8c8a42a upstream. Page tables on nv50 take 48kB, which can be hard to allocate in one piece. Let's use vmalloc. Signed-off-by: Marcin Slusarz Signed-off-by: Ben Skeggs Signed-off-by: Greg Kroah-Hartman commit cd2c367cf10eab382c53bb9f39e01726c6f10253 Author: Julia Lemire Date: Thu Jun 27 13:38:59 2013 -0400 drm/mgag200: Added resolution and bandwidth limits for various G200e products. commit abbee6238775c6633a3779962e9e5b5cb9823749 upstream. At the larger resolutions, the g200e series sometimes struggles with maintaining a proper output. Problems like flickering or black bands appearing on screen can occur. In order to avoid this, limitations regarding resolutions and bandwidth have been added for the different variations of the g200e series. This code was ported from the old xorg mga driver. Signed-off-by: Julia Lemire Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman commit 657c9009705f8d22faefdecac258312c5621ea51 Author: YoungJun Cho Date: Thu Jun 27 08:58:33 2013 +0900 drm/gem: fix not to assign error value to gem name commit 2e07fb229396f99fc173d8612f0f83ea9de0341b upstream. If idr_alloc() is failed, obj->name can be error value. Also it cleans up duplicated flink processing code. This regression has been introduced in commit 2e928815c1886fe628ed54623aa98d0889cf5509 Author: Tejun Heo Date: Wed Feb 27 17:04:08 2013 -0800 drm: convert to idr_alloc() Signed-off-by: YoungJun Cho Signed-off-by: Seung-Woo Kim Signed-off-by: Kyungmin Park Reviewed-by: Chris Wilson Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman commit e69a7ee45662a1b1d698c5d758613ffbe77fd2a9 Author: Chris Wilson Date: Fri Jun 28 16:54:08 2013 +0100 drm/i915: Only clear write-domains after a successful wait-seqno commit daa13e1ca587bc773c1aae415ed1af6554117bd4 upstream. In the introduction of the non-blocking wait, I cut'n'pasted the wait completion code from normal locked path. Unfortunately, this neglected that the normal path returned early if the wait returned early. The result is that read-only waits may return whilst the GPU is still writing to the bo. Fixes regression from commit 3236f57a0162391f84b93f39fc1882c49a8998c7 [v3.7] Author: Chris Wilson Date: Fri Aug 24 09:35:09 2012 +0100 drm/i915: Use a non-blocking wait for set-to-domain ioctl Signed-off-by: Chris Wilson Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=66163 Signed-off-by: Daniel Vetter Signed-off-by: Greg Kroah-Hartman commit 915bec00d92bdceefeff77ab67d32865900b1efe Author: Ben Widawsky Date: Tue Jun 25 21:53:40 2013 -0700 drm/i915: Fix context sizes on HSW commit a0de80a0e07032a111230ec92eca563f9d93648d upstream. With updates to the spec, we can actually see the context layout, and how many dwords are allocated. That table suggests we need 70720 bytes per HW context. Rounded up, this is 18 pages. Looking at what lives after the current 4 pages we use, I can't see too much important (mostly it's d3d related), but there are a couple of things which look scary. I am hopeful this can explain some of our odd HSW failures. v2: Make the context only 17 pages. The power context space isn't used ever, and execlists aren't used in our driver, making the actual total 66944 bytes. v3: Add a comment to the code. (Jesse & Paulo) Reported-by: "Azad, Vinit" Reviewed-by: Jesse Barnes Signed-off-by: Ben Widawsky Signed-off-by: Daniel Vetter Signed-off-by: Greg Kroah-Hartman commit f8ee0e2e9db4d11d3b6593d9e2fba464caa0ff0c Author: Daniel Vetter Date: Mon Jun 24 21:33:28 2013 +0200 drm/i915: Fix up sdvo hpd pins for i965g/gm commit 4f7fd7095d85cd31c86cb9ba87bc301319630ccc upstream. Bspec seems to be full of lies, at least it disagress with reality: Two systems corrobated that SDVO hpd bits are the same as on gen3. v2: Update comment a bit. Tested-by: Chris Wilson Cc: Arthur Ranyan Reported-and-tested-by: Alex Fiestas Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=58405 Acked-by: Chris Wilson Signed-off-by: Daniel Vetter Signed-off-by: Greg Kroah-Hartman commit a5ed6be766e6ca8f83ef0afea688ef9c760916d3 Author: Benjamin Herrenschmidt Date: Wed Jul 3 16:01:10 2013 +1000 of: Fix address decoding on Bimini and js2x machines commit 6dd18e4684f3d188277bbbc27545248487472108 upstream. Commit: e38c0a1fbc5803cbacdaac0557c70ac8ca5152e7 of/address: Handle #address-cells > 2 specially broke real time clock access on Bimini, js2x, and similar powerpc machines using the "maple" platform. That code was indirectly relying on the old (broken) behaviour of the translation for the hypertransport to ISA bridge. This fixes it by treating hypertransport as a PCI bus Signed-off-by: Benjamin Herrenschmidt Acked-by: Rob Herring Signed-off-by: Grant Likely Cc: Jonghwan Choi Signed-off-by: Greg Kroah-Hartman commit 369cf4be7588876d071c86d0efb7908e9bba7f6f Author: J. Bruce Fields Date: Wed Jun 26 10:55:40 2013 -0400 svcrpc: don't error out on small tcp fragment commit 1f691b07c5dc51b2055834f58c0f351defd97f27 upstream. Though clients we care about mostly don't do this, it is possible for rpc requests to be sent in multiple fragments. Here we have a sanity check to ensure that the final received rpc isn't too small--except that the number we're actually checking is the length of just the final fragment, not of the whole rpc. So a perfectly legal rpc that's unluckily fragmented could cause the server to close the connection here. Signed-off-by: J. Bruce Fields Signed-off-by: Greg Kroah-Hartman commit 57370589c166cc8747f5e09365407d9dc04d7425 Author: J. Bruce Fields Date: Wed Jun 26 11:09:06 2013 -0400 svcrpc: fix handling of too-short rpc's commit cf3aa02cb4a0c5af5557dd47f15a08a7df33182a upstream. If we detect that an rpc is too short, we abort and close the connection. Except, there's a bug here: we're leaving sk_datalen nonzero without leaving any pages in the sk_pages array. The most likely result of the inconsistency is a subsequent crash in svc_tcp_clear_pages. Also demote the BUG_ON in svc_tcp_clear_pages to a WARN. Signed-off-by: J. Bruce Fields Signed-off-by: Greg Kroah-Hartman commit c814208bb3542333629cc3c9e79666e94425899a Author: J. Bruce Fields Date: Mon Jul 8 13:44:45 2013 -0400 svcrpc: fix failures to handle -1 uid's commit 0979292bfa301cb87d936b69af428090d2feea1b upstream. As of f025adf191924e3a75ce80e130afcd2485b53bb8 "sunrpc: Properly decode kuids and kgids in RPC_AUTH_UNIX credentials" any rpc containing a -1 (0xffff) uid or gid would fail with a badcred error. Commit afe3c3fd5392b2f0066930abc5dbd3f4b14a0f13 "svcrpc: fix failures to handle -1 uid's and gid's" fixed part of the problem, but overlooked the gid upcall--the kernel can request supplementary gid's for the -1 uid, but mountd's attempt write a response will get -EINVAL. Symptoms were nfsd failing to reply to the first attempt to use a newly negotiated krb5 context. Reported-by: Sven Geggus Tested-by: Sven Geggus Signed-off-by: J. Bruce Fields Signed-off-by: Greg Kroah-Hartman commit 3873153a61235a63517547e347db7ab90788486f Author: zhangwei(Jovi) Date: Thu Jun 13 14:21:51 2013 +0800 uprobes: Fix return value in error handling path commit fa44063f9ef163c3a4c8d8c0465bb8a056b42035 upstream. When wrong argument is passed into uprobe_events it does not return an error: [root@jovi tracing]# echo 'p:myprobe /bin/bash' > uprobe_events [root@jovi tracing]# The proper response is: [root@jovi tracing]# echo 'p:myprobe /bin/bash' > uprobe_events -bash: echo: write error: Invalid argument Link: http://lkml.kernel.org/r/51B964FF.5000106@huawei.com Signed-off-by: zhangwei(Jovi) Cc: Frederic Weisbecker Cc: Signed-off-by: Steven Rostedt Signed-off-by: Greg Kroah-Hartman commit 5df5df87f2b5f5d75825207d61a272b168d8cab6 Author: Bu, Yitian Date: Mon Feb 18 12:53:37 2013 +0000 printk: Fix rq->lock vs logbuf_lock unlock lock inversion commit dbda92d16f8655044e082930e4e9d244b87fde77 upstream. commit 07354eb1a74d1 ("locking printk: Annotate logbuf_lock as raw") reintroduced a lock inversion problem which was fixed in commit 0b5e1c5255 ("printk: Release console_sem after logbuf_lock"). This happened probably when fixing up patch rejects. Restore the ordering and unlock logbuf_lock before releasing console_sem. Signed-off-by: ybu Cc: Peter Zijlstra Link: http://lkml.kernel.org/r/E807E903FE6CBE4D95E420FBFCC273B827413C@nasanexd01h.na.qualcomm.com Signed-off-by: Thomas Gleixner Signed-off-by: Greg Kroah-Hartman commit bcaef288b2a3187de17220e86e15b762b3b0808e Author: Johannes Berg Date: Fri May 24 01:06:09 2013 +0200 mac80211: close AP_VLAN interfaces before unregistering all commit 4c8a9d4bfaf7dbc7d2168494904d79d22cc01db7 upstream. Since Eric's commit efe117ab8 ("Speedup ieee80211_remove_interfaces") there's a bug in mac80211 when it unregisters with AP_VLAN interfaces up. If the AP_VLAN interface was registered after the AP it belongs to (which is the typical case) and then we get into this code path, unregister_netdevice_many() will crash because it isn't prepared to deal with interfaces being closed in the middle of it. Exactly this happens though, because we iterate the list, find the AP master this AP_VLAN belongs to and dev_close() the dependent VLANs. After this, unregister_netdevice_many() won't pick up the fact that the AP_VLAN is already down and will do it again, causing a crash. Signed-off-by: Johannes Berg Cc: Eric Dumazet Signed-off-by: Greg Kroah-Hartman commit b84f7b3f934ea3ff0240e866f2e73b34b42c2811 Author: Hauke Mehrtens Date: Sun Jun 9 18:53:58 2013 +0200 b43: ensue that BCMA is "y" when B43 is "y" commit 693026ef2e751fd94d2e6c71028e68343cc875d5 upstream. When b43 gets build into the kernel and it should use bcma we have to ensure that bcma was also build into the kernel and not as a module. In this patch this is also done for SSB, although you can not build b43 without ssb support for now. This fixes a build problem reported by Randy Dunlap in 5187EB95.2060605@infradead.org Reported-By: Randy Dunlap Signed-off-by: Hauke Mehrtens Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit ebfc049ce8e32b5ff6bf6fec74775ac021769f37 Author: Luiz Capitulino Date: Tue Jul 2 15:35:13 2013 +0930 virtio_balloon: leak_balloon(): only tell host if we got pages deflated commit 8c6bab4f3874d31804a00782c48a8f244a0d3cc0 upstream. balloon_page_dequeue() can return NULL. If it does for the first page being freed then leak_balloon() will create a scatter list with len=0. Which in turn seems to generate an invalid virtio request. I didn't get this in practice, I found it by code review. On the other hand, such an invalid virtio request will cause errors in QEMU and fill_balloon() also performs the same check implemented by this commit. This bug was introduced in e2250429. Signed-off-by: Luiz Capitulino Acked-by: Rafael Aquini Signed-off-by: Andrew Morton Signed-off-by: Rusty Russell Signed-off-by: Greg Kroah-Hartman commit 0531603e3a0dbb7c36f2b37833add0e73b8c0c5f Author: Reddy, Sreekanth Date: Tue Feb 26 16:59:59 2013 +0530 SCSI: mpt2sas: Fix for issue Missing delay not getting set during system bootup commit b0df96a0068daee4f9c2189c29b9053eb6e46b17 upstream. Missing delay is not getting set properly. The reason is that it is not defined in the same file from where it is being invoked. The fix is to move the missing delay module parameter from mpt2sas_base.c to mpt2sas_scsh.c. Signed-off-by: Sreekanth Reddy Signed-off-by: James Bottomley Signed-off-by: Greg Kroah-Hartman commit 47c00d01fb222baaf8d248f855061da168b29c5d Author: Sreekanth Reddy Date: Sat Feb 2 00:58:20 2013 +0530 SCSI: mpt2sas: fix firmware failure with wrong task attribute commit 48ba2efc382f94fae16ca8ca011e5961a81ad1ea upstream. When SCSI command is received with task attribute not set, set it to SIMPLE. Previously it is set to untagged. This causes the firmware to fail the commands. Signed-off-by: Sreekanth Reddy Signed-off-by: James Bottomley Signed-off-by: Greg Kroah-Hartman commit 8f425c63ecda1bab9982892e7890041292e2d5ec Author: Steffen Maier Date: Fri Apr 26 17:34:54 2013 +0200 SCSI: zfcp: status read buffers on first adapter open with link down commit 9edf7d75ee5f21663a0183d21f702682d0ef132f upstream. Commit 64deb6efdc5504ce97b5c1c6f281fffbc150bd93 "[SCSI] zfcp: Use status_read_buf_num provided by FCP channel" started using a value returned by the channel but only evaluated the value if the fabric link is up. Commit 8d88cf3f3b9af4713642caeb221b6d6a42019001 "[SCSI] zfcp: Update status read mempool" introduced mempool resizings based on the above value. On setting an FCP device online for the very first time since boot, a new zeroed adapter object is allocated. If the link is down, the number of status read requests remains zero. Since just the config data exchange is incomplete, we proceed with adapter open recovery. However, we unconditionally call mempool_resize with adapter->stat_read_buf_num == 0 in this case. This causes a kernel message "kernel BUG at mm/mempool.c:131!" in process "zfcperp" with last function mempool_resize in Krnl PSW and zfcp_erp_thread in the Call Trace. Don't evaluate channel values which are invalid on link down. The number of status read requests is always valid, evaluated, and set to a positive minimum greater than zero. The adapter open recovery can proceed and the channel has status read buffers to inform us on a future link up event. While we are not aware of any other code path that could result in mempool resize attempts of size zero, we still also initialize the number of status read buffers to be posted to a static minimum number on adapter object allocation. Signed-off-by: Steffen Maier Signed-off-by: James Bottomley Signed-off-by: Greg Kroah-Hartman commit b22b8386992d886aa487b57e000b18512e639710 Author: Steffen Maier Date: Fri Apr 26 17:33:45 2013 +0200 SCSI: zfcp: block queue limits with data router commit 5fea4291deacd80188b996d2f555fc6a1940e5d4 upstream. Commit 86a9668a8d29ea711613e1cb37efa68e7c4db564 "[SCSI] zfcp: support for hardware data router" reduced the initial block queue limits in the scsi_host_template to the absolute minimum and adjusted them later on. However, the adjustment was too late for the BSG devices of Scsi_Host and fc_host. Therefore, ioctl(..., SG_IO, ...) with request or response size > 4kB to a BSG device of an fc_host or a Scsi_Host fails with EINVAL. As a result, users of such ioctl such as HBA_SendCTPassThru() in libzfcphbaapi return with error HBA_STATUS_ERROR. Initialize the block queue limits in zfcp_scsi_host_template to the greatest common denominator (GCD). While we cannot exploit the slightly enlarged maximum request size with data router, this should be neglectible. Doing so also avoids running into trouble after live guest relocation (LGR) / migration from a data router FCP device to an FCP device that does not support data router. In that case, zfcp would figure out the new limits on adapter recovery, but the fc_host and Scsi_Host (plus in fact all sdevs) still exist with the old and now too large queue limits. It should also OK, not to use half the size as in the DIX case, because fc_host and Scsi_Host do not transport FCP requests including SCSI commands using protection data. Signed-off-by: Steffen Maier Reviewed-by: Martin Peschke Signed-off-by: James Bottomley Signed-off-by: Greg Kroah-Hartman commit 88bc5928044239f6902e89798ae4ef75d23ccb3c Author: Daniel Hansel Date: Fri Apr 26 17:32:14 2013 +0200 SCSI: zfcp: fix adapter (re)open recovery while link to SAN is down commit f76ccaac4f82c463a037aa4a1e4ccb85c7011814 upstream. FCP device remains in status ERP_FAILED when device is switched online or adapter recovery is triggered while link to SAN is down. When Exchange Configuration Data command returns the FSF status FSF_EXCHANGE_CONFIG_DATA_INCOMPLETE it aborts the exchange process. The only retries are done during the common error recovery procedure (i.e. max. 3 retries with 8sec sleep between) and remains in status ERP_FAILED with QDIO down. This commit reverts the commit 0df138476c8306478d6e726f044868b4bccf411c (zfcp: Fix adapter activation on link down). When FSF status FSF_EXCHANGE_CONFIG_DATA_INCOMPLETE is received the adapter recovery will be finished without any retries. QDIO will be up now and status changes such as LINK UP will be received now. Signed-off-by: Daniel Hansel Signed-off-by: Steffen Maier Signed-off-by: James Bottomley Signed-off-by: Greg Kroah-Hartman commit 4e6b18250651a14b053508e30e731247e28e3f2a Author: Mahesh Rajashekhara Date: Tue Jun 18 17:02:07 2013 +0530 SCSI: aacraid: Fix for arrays are going offline in the system. System hangs commit c5bebd829dd95602c15f8da8cc50fa938b5e0254 upstream. One of the customer had reported that the set of raid logical arrays will become unavailable (I/O offline) after a long hours of IO stress test. The OS wouldn`t be accessible afterwards and require a hard reset. This driver patch has a fix for race condition between the doorbell and the circular buffer. The driver is modified to do an extra read after clearing the doorbell in case there had been a completion posted during the small timing window. With this fix, we ran IO stress for ~13 days. There were no IO failures. Signed-off-by: Mahesh Rajashekhara Signed-off-by: James Bottomley Signed-off-by: Greg Kroah-Hartman commit 98dcc2946adbe4349ef1ef9b99873b912831edd4 Author: Martin K. Petersen Date: Thu Jun 6 22:15:55 2013 -0400 SCSI: sd: Update WRITE SAME heuristics commit 66c28f97120e8a621afd5aa7a31c4b85c547d33d upstream. SATA drives located behind a SAS controller would incorrectly receive WRITE SAME commands. Tweak the heuristics so that: - If REPORT SUPPORTED OPERATION CODES is provided we will use that to choose between WRITE SAME(16), WRITE SAME(10) and disabled. This also fixes an issue with the old code which would issue WRITE SAME(10) despite the command not being whitelisted in REPORT SUPPORTED OPERATION CODES. - If REPORT SUPPORTED OPERATION CODES is not provided we will fall back to WRITE SAME(10) unless the device has an ATA Information VPD page. The assumption is that a SATL which is smart enough to implement WRITE SAME would also provide REPORT SUPPORTED OPERATION CODES. To facilitate the new heuristics scsi_report_opcode() has been modified to so we can distinguish between "operation not supported" and "RSOC not supported". Reported-by: H. Peter Anvin Tested-by: Bernd Schubert Signed-off-by: Martin K. Petersen Signed-off-by: James Bottomley Signed-off-by: Greg Kroah-Hartman commit 64ea2992a29aa0bdc4eaf457351b063caafb6655 Author: Sujith Manoharan Date: Mon Jun 10 13:49:40 2013 +0530 ath9k: Do not assign noise for NULL caldata commit d3bcb7b24bbf09fde8405770e676fe0c11c79662 upstream. ah->noise is maintained globally and not per-channel. This is updated in the reset() routine after the NF history has been filled for the *current channel*, just before switching to the new channel. There is no need to do it inside getnf(), since ah->noise must contain a value for the new channel. Signed-off-by: Sujith Manoharan Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit 13311514a74f520989e304b746dc7478335877f9 Author: Sujith Manoharan Date: Mon Jun 10 13:49:39 2013 +0530 ath9k: Fix noisefloor calibration commit 696df78509d1f81b651dd98ecdc1aecab616db6b upstream. The commits, "ath9k: Fix regression in channelwidth switch at the same channel" "ath9k: Fix invalid noisefloor reading due to channel update" attempted to fix noisefloor calibration when a channel switch happens due to HT20/HT40 bandwidth change. This is causing invalid readings resulting in messages like: "ath: phy16: NF[0] (-45) > MAX (-95), correcting to MAX". This results in an incorrect noise being used initially for reporting the signal level of received packets, until NF calibration is done and the history buffer is updated via the ANI timer, which happens much later. When a bandwidth change happens, it is appropriate to reset the internal history data for the channel. Do this correctly in the reset() routine by checking the "chanmode" variable. Signed-off-by: Sujith Manoharan Cc: Rajkumar Manoharan Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit e9c25a407d5c75646eb258de1363dccc1fd3ab47 Author: Sujith Manoharan Date: Mon Jun 10 13:49:38 2013 +0530 ath9k_hw: Assign default xlna config for AR9485 commit 30d5b709da23f4ab9836c7f66d2d2e780a69cf12 upstream. For AR9485 boards with XLNA, the default gpio config is not set correctly, fix this. Signed-off-by: Sujith Manoharan Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit 0530bd4a6cc3c04d1e621299e05d2da2c99736c4 Author: Gabor Juhos Date: Tue Jun 25 22:57:29 2013 +0200 rt2x00: rt2800lib: fix default TX power check for RT55xx commit 0847beb2865f5ef1c8626ec1a37def18f3d6c41a upstream. The code writes the default_power2 value into the TX field of the RFCSR50 register, however the condition in the if statement uses default_power1. Due to this, wrong TX power value might be written into the register. Use the correct value in the condition to fix the issue. Compile tested only. Signed-off-by: Gabor Juhos Acked-by: Gertjan van Wingerde Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit 24e095cdc2d7781e756b052291ef0ca7c9edac93 Author: Gabor Juhos Date: Sat Jun 22 13:13:25 2013 +0200 rt2x00: read 5GHz TX power values from the correct offset commit 0a6f3a8ebaf13407523c2c7d575b4ca2debd23ba upstream. The current code uses the same index value both for the channel information array and for the TX power table. The index starts from 14, however the index of the TX power table must start from zero. Fix it, in order to get the correct TX power value for a given channel. The changes in rt61pci.c and rt73usb.c are compile tested only. Signed-off-by: Gabor Juhos Acked-by: Stanislaw Gruszka Acked-by: Gertjan van Wingerde Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit f707f7ae37c514a3871741747bfd8c09d7badb05 Author: Baruch Siach Date: Wed May 29 10:11:17 2013 +0200 clocksource: dw_apb: Fix error check commit 1a33bd2be705cbb3f57d7223b60baea441039307 upstream. irq_of_parse_and_map() returns 0 on error, while the code checks for NO_IRQ. This breaks on platforms that have NO_IRQ != 0. Signed-off-by: Baruch Siach Signed-off-by: Daniel Lezcano Signed-off-by: Greg Kroah-Hartman commit 084c895d3c9fecf80fe02ba442b90818116b30d2 Author: Thomas Gleixner Date: Mon Jul 1 22:14:10 2013 +0200 tick: Prevent uncontrolled switch to oneshot mode commit 1f73a9806bdd07a5106409bbcab3884078bd34fe upstream. When the system switches from periodic to oneshot mode, the broadcast logic causes a possibility that a CPU which has not yet switched to oneshot mode puts its own clock event device into oneshot mode without updating the state and the timer handler. CPU0 CPU1 per cpu tickdev is in periodic mode and switched to broadcast Switch to oneshot mode tick_broadcast_switch_to_oneshot() cpumask_copy(tick_oneshot_broacast_mask, tick_broadcast_mask); broadcast device mode = oneshot Timer interrupt irq_enter() tick_check_oneshot_broadcast() dev->set_mode(ONESHOT); tick_handle_periodic() if (dev->mode == ONESHOT) dev->next_event += period; FAIL. We fail, because dev->next_event contains KTIME_MAX, if the device was in periodic mode before the uncontrolled switch to oneshot happened. We must copy the broadcast bits over to the oneshot mask, because otherwise a CPU which relies on the broadcast would not been woken up anymore after the broadcast device switched to oneshot mode. So we need to verify in tick_check_oneshot_broadcast() whether the CPU has already switched to oneshot mode. If not, leave the device untouched and let the CPU switch controlled into oneshot mode. This is a long standing bug, which was never noticed, because the main user of the broadcast x86 cannot run into that scenario, AFAICT. The nonarchitected timer mess of ARM creates a gazillion of differently broken abominations which trigger the shortcomings of that broadcast code, which better had never been necessary in the first place. Reported-and-tested-by: Stehle Vincent-B46079 Reviewed-by: Stephen Boyd Cc: John Stultz , Cc: Mark Rutland Link: http://lkml.kernel.org/r/alpine.DEB.2.02.1307012153060.4013@ionos.tec.linutronix.de Signed-off-by: Thomas Gleixner Signed-off-by: Greg Kroah-Hartman commit 1c0d08e652c18e3f3198969435fef31941b2eec3 Author: Thomas Gleixner Date: Mon Jul 1 22:14:10 2013 +0200 tick: Sanitize broadcast control logic commit 07bd1172902e782f288e4d44b1fde7dec0f08b6f upstream. The recent implementation of a generic dummy timer resulted in a different registration order of per cpu local timers which made the broadcast control logic go belly up. If the dummy timer is the first clock event device which is registered for a CPU, then it is installed, the broadcast timer is initialized and the CPU is marked as broadcast target. If a real clock event device is installed after that, we can fail to take the CPU out of the broadcast mask. In the worst case we end up with two periodic timer events firing for the same CPU. One from the per cpu hardware device and one from the broadcast. Now the problem is that we have no way to distinguish whether the system is in a state which makes broadcasting necessary or the broadcast bit was set due to the nonfunctional dummy timer installment. To solve this we need to keep track of the system state seperately and provide a more detailed decision logic whether we keep the CPU in broadcast mode or not. The old decision logic only clears the broadcast mode, if the newly installed clock event device is not affected by power states. The new logic clears the broadcast mode if one of the following is true: - The new device is not affected by power states. - The system is not in a power state affected mode - The system has switched to oneshot mode. The oneshot broadcast is controlled from the deep idle state. The CPU is not in idle at this point, so it's safe to remove it from the mask. If we clear the broadcast bit for the CPU when a new device is installed, we also shutdown the broadcast device when this was the last CPU in the broadcast mask. If the broadcast bit is kept, then we leave the new device in shutdown state and rely on the broadcast to deliver the timer interrupts via the broadcast ipis. Reported-and-tested-by: Stehle Vincent-B46079 Reviewed-by: Stephen Boyd Cc: John Stultz , Cc: Mark Rutland Link: http://lkml.kernel.org/r/alpine.DEB.2.02.1307012153060.4013@ionos.tec.linutronix.de Signed-off-by: Thomas Gleixner Signed-off-by: Greg Kroah-Hartman commit 2dc04d3333049098691eb652e06d52fbd80771d2 Author: NeilBrown Date: Tue Jul 16 16:50:47 2013 +1000 md/raid10: fix two problems with RAID10 resync. commit 7bb23c4934059c64cbee2e41d5d24ce122285176 upstream. 1/ When an different between blocks is found, data is copied from one bio to the other. However bv_len is used as the length to copy and this could be zero. So use r10_bio->sectors to calculate length instead. Using bv_len was probably always a bit dubious, but the introduction of bio_advance made it much more likely to be a problem. 2/ When preparing some blocks for sync, we don't set BIO_UPTODATE except on bios that we schedule for a read. This ensures that missing/failed devices don't confuse the loop at the top of sync_request write. Commit 8be185f2c9d54d6 "raid10: Use bio_reset()" removed a loop which set BIO_UPTDATE on all appropriate bios. So we need to re-add that flag. These bugs were introduced in 3.10, so this patch is suitable for 3.10-stable, and can remove a potential for data corruption. Reported-by: Brassow Jonathan Signed-off-by: NeilBrown Signed-off-by: Greg Kroah-Hartman commit 4b5c14511c401edf5ea78e2592c7043456deb595 Author: NeilBrown Date: Tue Jul 2 15:58:05 2013 +1000 md/raid10: fix two bugs affecting RAID10 reshape. commit 78eaa0d4cbcdb345992fa3dd22b3bcbb473cc064 upstream. 1/ If a RAID10 is being reshaped to a fewer number of devices and is stopped while this is ongoing, then when the array is reassembled the 'mirrors' array will be allocated too small. This will lead to an access error or memory corruption. 2/ A sanity test for a reshaping RAID10 array is restarted is slightly incorrect. Due to the first bug, this is suitable for any -stable kernel since 3.5 where this code was introduced. Signed-off-by: NeilBrown Signed-off-by: Greg Kroah-Hartman commit 509c317d092a551f5c26de05445fc8d5b81cc23d Author: NeilBrown Date: Thu Jul 4 16:41:53 2013 +1000 md/raid10: fix bug which causes all RAID10 reshapes to move no data. commit 1376512065b23f39d5f9a160948f313397dde972 upstream. The recent comment: commit 7e83ccbecd608b971f340e951c9e84cd0343002f md/raid10: Allow skipping recovery when clean arrays are assembled Causes raid10 to skip a recovery in certain cases where it is safe to do so. Unfortunately it also causes a reshape to be skipped which is never safe. The result is that an attempt to reshape a RAID10 will appear to complete instantly, but no data will have been moves so the array will now contain garbage. (If nothing is written, you can recovery by simple performing the reverse reshape which will also complete instantly). Bug was introduced in 3.10, so this is suitable for 3.10-stable. Signed-off-by: NeilBrown Cc: Martin Wilck Signed-off-by: Greg Kroah-Hartman commit 3bd92a9d1f82e41d781f082d710b16036a0ea25b Author: Fabio Estevam Date: Thu Jul 4 20:01:03 2013 -0300 ASoC: sglt5000: Fix SGTL5000_PLL_FRAC_DIV_MASK commit 5c78dfe87ea04b501ee000a7f03b9432ac9d008c upstream. SGTL5000_PLL_FRAC_DIV_MASK is used to mask bits 0-10 (11 bits in total) of register CHIP_PLL_CTRL, so fix the mask to accomodate all this bit range. Reported-by: Oskar Schirmer Signed-off-by: Fabio Estevam Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit b5aa3fc5730c605f4f6e1dbc45db459cfd59d1ed Author: Takashi Iwai Date: Thu Jul 11 18:00:01 2013 +0200 ASoC: atmel: Fix unlocked snd_pcm_stop() call commit 571185717f8d7f2a088a7ac38d94a9ad5fd9da5c upstream. snd_pcm_stop() must be called in the PCM substream lock context. Acked-by: Mark Brown Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit d23067e924e410875602b3427251b88cd18da73f Author: Takashi Iwai Date: Thu Jul 11 18:00:25 2013 +0200 ASoC: s6000: Fix unlocked snd_pcm_stop() call commit 61be2b9a18ec70f3cbe3deef7a5f77869c71b5ae upstream. snd_pcm_stop() must be called in the PCM substream lock context. Acked-by: Mark Brown Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 5ebc73095cf30bca82ef2983a46756ff26b1a810 Author: Shane Huang Date: Mon Jun 3 18:24:55 2013 +0800 i2c-piix4: Add AMD CZ SMBus device ID commit b996ac90f595dda271cbd858b136b45557fc1a57 upstream. To add AMD CZ SMBus controller device ID. [bhelgaas: drop pci_ids.h update] Signed-off-by: Shane Huang Signed-off-by: Bjorn Helgaas Reviewed-by: Tejun Heo Reviewed-by: Jean Delvare Signed-off-by: Greg Kroah-Hartman commit 31c1a76deb262a074b209ad14a35bef7f5b9ab81 Author: Mark Langsdorf Date: Mon Jun 3 08:22:54 2013 -0500 sata_highbank: increase retry count but shorten duration for Calxeda controller commit ddfef5de3d716f77bad32dbbba6b280158dfd721 upstream. Increase the retry count for the hard reset function to 100 but shorten the time out period to 500 ms. See the comment for ahci_highbank_hardreset for the reasons why those vaulues were chosen. Signed-off-by: Mark Langsdorf Signed-off-by: Tejun Heo Signed-off-by: Greg Kroah-Hartman commit b568411d97ec8c91eef5e512b5b2ec5df050c9c1 Author: Seth Heasley Date: Wed Jun 19 16:25:37 2013 -0700 ata_piix: IDE-mode SATA patch for Intel Coleto Creek DeviceIDs commit c7e8695bfa0611b39493a9dfe8bab9f63f9809bd upstream. This patch adds the IDE-mode SATA DeviceIDs for the Intel Coleto Creek PCH. Signed-off-by: Seth Heasley Signed-off-by: Tejun Heo Signed-off-by: Greg Kroah-Hartman commit 64a03b5c4206bb104ea69efed3c8189427fcedfe Author: Tejun Heo Date: Tue Jun 11 00:11:36 2013 -0700 libata: skip SRST for all SIMG [34]7x port-multipliers commit 7a87718d92760fc688628ad6a430643dafa16f1f upstream. For some reason, a lot of port-multipliers have issues with softreset. SIMG [34]7x series port-multipliers have been quite erratic in this regard. I recall that it was better with some firmware revisions and the current list of quirks worked fine for a while. I think it got worse with later firmwares or maybe my test coverage wasn't good enough. Anyways, HPA is reporting that his 3726 setup suffers SRST failures and then the PMP gets confused and fails to probe the last port. The hope was that we try to stick to the standard as much as possible and soonish the PMPs and their firmwares will improve in quality, so the quirk list was kept to minimum. Well, it seems like that's never gonna happen. Let's set NO_SRST for all [34]7x PMPs so that whatever remaining userbase of the device suffer the least. Maybe we should do the same for 57xx's but unfortunately I don't have any device left to test and I'm not even sure 57xx's have ever been made widely available, so let's leave those alone for now. Signed-off-by: Tejun Heo Reported-by: "H. Peter Anvin" Signed-off-by: Greg Kroah-Hartman commit fe1ebd057ddfb37a23cc37090d427fb0a68d3000 Author: Sergei Shtylyov Date: Sun Jun 23 23:25:04 2013 +0400 libata-zpodd: must use ata_tf_init() commit d0887c43f51c308b01605346e55d906ba858a6f9 upstream. There are some SATA controllers which have both devices 0 and 1 but this module just zeroes out taskfile and sets then ATA_TFLAG_DEVICE (not sure that's needed) which could lead to a wrong device being selected just before issuing command. Thus we should call ata_tf_init() which sets up the device register value properly, like all other users of ata_exec_internal() do... Signed-off-by: Sergei Shtylyov Signed-off-by: Tejun Heo Signed-off-by: Greg Kroah-Hartman commit bde3f4bb512c34609becce11f23ed6f89e3f488f Author: Guenter Roeck Date: Sun Jun 23 13:04:04 2013 -0700 hwmon: (nct6775) Drop unsupported fan alarm attributes for NCT6775 commit 41fa9a944fce1d7efd5ee3d50ac85b92f42dcc3d upstream. NCT6775 does not support alarms for fans 4 and 5. Drop the attributes. Signed-off-by: Guenter Roeck Signed-off-by: Greg Kroah-Hartman commit e00354825e75a338ced4f4eb16cf08182c116984 Author: Guenter Roeck Date: Sat Jun 22 16:15:31 2013 -0700 hwmon: (nct6775) Fix temperature alarm attributes commit b1d2bff6a61140454b9d203519cc686a2e9ef32f upstream. Driver displays wrong alarms for temperature attributes. Turns out that temperature alarm bits are not fixed, but determined by temperature source mapping. To fix the problem, walk through the temperature sources to determine the correct alarm bit associated with a given attribute. Signed-off-by: Guenter Roeck Signed-off-by: Greg Kroah-Hartman commit 1ef08eb2a9a50d9b4dd119bda4f747e1b922a4fc Author: Takashi Iwai Date: Thu Jul 11 17:58:47 2013 +0200 ALSA: usx2y: Fix unlocked snd_pcm_stop() call commit 5be1efb4c2ed79c3d7c0cbcbecae768377666e84 upstream. snd_pcm_stop() must be called in the PCM substream lock context. Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 4b06cd616f646a4257b39a1cc9a10410e7c90088 Author: Takashi Iwai Date: Thu Jul 11 17:55:57 2013 +0200 ALSA: asihpi: Fix unlocked snd_pcm_stop() call commit 60478295d6876619f8f47f6d1a5c25eaade69ee3 upstream. snd_pcm_stop() must be called in the PCM substream lock context. Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 8268d1c754169393118ae847cf6741d777e976a4 Author: Takashi Iwai Date: Thu Jul 11 17:56:56 2013 +0200 ALSA: atiixp: Fix unlocked snd_pcm_stop() call commit cc7282b8d5abbd48c81d1465925d464d9e3eaa8f upstream. snd_pcm_stop() must be called in the PCM substream lock context. Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 2306396c952129dcf127d47c0383ae28c7288ed0 Author: Takashi Iwai Date: Thu Jul 11 17:59:33 2013 +0200 ALSA: pxa2xx: Fix unlocked snd_pcm_stop() call commit 46f6c1aaf790be9ea3c8ddfc8f235a5f677d08e2 upstream. snd_pcm_stop() must be called in the PCM substream lock context. Acked-by: Mark Brown Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit c9c8dd7d3cacecd3a3f0e6e49c0a0f8f93d3d04e Author: Takashi Iwai Date: Thu Jul 11 17:58:25 2013 +0200 ALSA: ua101: Fix unlocked snd_pcm_stop() call commit 9538aa46c2427d6782aa10036c4da4c541605e0e upstream. snd_pcm_stop() must be called in the PCM substream lock context. Acked-by: Clemens Ladisch Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 2bc2f7d622af45d07980a83586c95c7530e4f6cc Author: Takashi Iwai Date: Thu Jul 11 17:57:55 2013 +0200 ALSA: 6fire: Fix unlocked snd_pcm_stop() call commit 5b9ab3f7324a1b94a5a5a76d44cf92dfeb3b5e80 upstream. snd_pcm_stop() must be called in the PCM substream lock context. Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 409972c1c8678bb0c28eb0417054e2794dd59ec9 Author: Takashi Iwai Date: Tue Jul 16 12:17:49 2013 +0200 ALSA: seq-oss: Initialize MIDI clients asynchronously commit 256ca9c3ad5013ff8a8f165e5a82fab437628c8e upstream. We've got bug reports that the module loading stuck on Debian system with 3.10 kernel. The debugging session revealed that the initial registration of OSS sequencer clients stuck at module loading time, which involves again with request_module() at the init phase. This is triggered only by special --install stuff Debian is using, but it's still not good to have such loops. As a workaround, call the registration part asynchronously. This is a better approach irrespective of the hang fix, in anyway. Reported-and-tested-by: Philipp Matthias Hahn Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 782e9cac197a38391820b425a4645e5bda7d121b Author: Aaron Plattner Date: Fri Jul 12 11:01:37 2013 -0700 ALSA: hda - Add new GPU codec ID to snd-hda commit d52392b1a80458c0510810789c7db4a39b88022a upstream. Vendor ID 0x10de0060 is used by a yet-to-be-named GPU chip. Reviewed-by: Andy Ritger Signed-off-by: Aaron Plattner Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 3a72cf75a1e32aedfd68b4467e2677bf1c0eb5d4 Author: Takashi Iwai Date: Fri Jun 28 11:51:32 2013 +0200 ALSA: hda - Fix the max length of control name in generic parser commit 0c055b3413868227f2e85701c4e6938c9581f0e2 upstream. add_control_with_pfx() in hda_generic.c assumes a shorter name string for the control element, and this resulted in the truncation of the long but valid string like "Headphone Surround Switch" in the middle. This patch aligns the max size to the actual limit of snd_ctl_elem_id, 44. Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 1f563ec40d24e0af579911dfbd6ac8856889bb89 Author: Takashi Iwai Date: Wed Jun 19 07:54:09 2013 +0200 ALSA: hda - Fix missing Mic Boost controls for VIA codecs commit d045c5dc43d829df9f067d363c3b42b14dacf434 upstream. Some VIA codecs like VT1708S have Mic boost amps in the mic pins but they aren't exposed in the capability bits. In the past driver code, we override the pin caps and create mic boost controls forcibly. While transition to the generic parser, we lost the mic boost controls although the pin caps are still overridden, because the generic parser code checks the widget caps, too. So this patch adds a new helper function to allow the override of the given widget capability bits, and makes VIA codecs driver to add the missing input-amp capability bit. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=59861 Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 27035caa37556524ef30311438cefaf1a80a5364 Author: Takashi Iwai Date: Tue Jun 18 16:14:22 2013 +0200 ALSA: hda - Cache the MUX selection for generic HDMI commit bddee96b5d0db869f47b195fe48c614ca824203c upstream. When a selection to a converter MUX is changed in hdmi_pcm_open(), it should be cached so that the given connection can be restored properly at PM resume. We need just to replace the corresponding snd_hda_codec_write() call with snd_hda_codec_write_cache(). Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 1d33b1e178d4d298150227227e079dd883f06f57 Author: Takashi Iwai Date: Tue Jun 18 07:55:02 2013 +0200 ALSA: hda - Fix return value of snd_hda_check_power_state() commit 06ec56d3c60238f27bfa50d245592fccc1b4ef0f upstream. The refactoring by commit 9040d102 introduced the new function snd_hda_check_power_state(). This function is supposed to return true if the state already reached to the target state, but it actually returns false for that. An utterly stupid typo while copy & paste. Fortunately this didn't influence on much behavior because powering up AFG usually powers up the child widgets, too. But the finer power control must have been broken by this bug. Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit c38217e1b806155493c9324345f0f1e6561e55db Author: Takashi Iwai Date: Thu Jul 4 12:54:22 2013 +0200 ALSA: hda - Fix EAPD vmaster hook for AD1884 & co commit 8f0b3b7e222383a21f7d58bd97d5552b3a5dbced upstream. ad1884_fixup_hp_eapd() tries to set the NID for controlling the speaker EAPD from the pin configuration. But the current code can't work expectedly since it sets spec->eapd_nid before calling the generic parser where the autocfg pins are set up. This patch changes the function to set spec->eapd_nid after the generic parser call while it sets vmaster hook unconditionally. The spec->eapd_nid check is moved in the hook function itself instead. Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 79d295ce5b9c322ebb40b2d7fdb9da4eee83f893 Author: Alexandre Belloni Date: Mon Jul 1 17:40:00 2013 +0100 iio: inkern: fix iio_convert_raw_to_processed_unlocked commit f91d1b63a4e096d3023aaaafec9d9d3aff25997f upstream. When reading IIO_CHAN_INFO_OFFSET, the return value of iio_channel_read() for success will be IIO_VAL*, checking for 0 is not correct. Without this fix the offset applied by iio drivers will be ignored when converting a raw value to one in appropriate base units (e.g mV) in a IIO client drivers that use iio_convert_raw_to_processed including iio-hwmon. Signed-off-by: Alexandre Belloni Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 8b68eefae0dbd8cdddb54af08c2b424f6da6f6ba Author: Alexandre Belloni Date: Mon Jul 1 15:20:00 2013 +0100 iio: Fix iio_channel_has_info commit 1c297a66654a3295ae87e2b7f3724d214eb2b5ec upstream. Since the info_mask split, iio_channel_has_info() is not working correctly. info_mask_separate and info_mask_shared_by_type, it is not possible to compare them directly with the iio_chan_info_enum enum. Correct that bit using the BIT() macro. Signed-off-by: Alexandre Belloni Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 88c0a794e5d9bcc29926e636cd1d6eb5c9dcb235 Author: Will Deacon Date: Fri Jul 19 15:37:12 2013 +0100 arm64: mm: don't treat user cache maintenance faults as writes commit db6f41063cbdb58b14846e600e6bc3f4e4c2e888 upstream. On arm64, cache maintenance faults appear as data aborts with the CM bit set in the ESR. The WnR bit, usually used to distinguish between faulting loads and stores, always reads as 1 and (slightly confusingly) the instructions are treated as reads by the architecture. This patch fixes our fault handling code to treat cache maintenance faults in the same way as loads. Signed-off-by: Will Deacon Signed-off-by: Catalin Marinas Signed-off-by: Greg Kroah-Hartman commit 916f4dbc2a827677212a3bf3ffcc22745fa6e0b1 Author: Srivatsa S. Bhat Date: Tue Jul 16 22:46:48 2013 +0200 cpufreq: Revert commit 2f7021a8 to fix CPU hotplug regression commit e8d05276f236ee6435e78411f62be9714e0b9377 upstream. commit 2f7021a8 "cpufreq: protect 'policy->cpus' from offlining during __gov_queue_work()" caused a regression in CPU hotplug, because it lead to a deadlock between cpufreq governor worker thread and the CPU hotplug writer task. Lockdep splat corresponding to this deadlock is shown below: [ 60.277396] ====================================================== [ 60.277400] [ INFO: possible circular locking dependency detected ] [ 60.277407] 3.10.0-rc7-dbg-01385-g241fd04-dirty #1744 Not tainted [ 60.277411] ------------------------------------------------------- [ 60.277417] bash/2225 is trying to acquire lock: [ 60.277422] ((&(&j_cdbs->work)->work)){+.+...}, at: [] flush_work+0x5/0x280 [ 60.277444] but task is already holding lock: [ 60.277449] (cpu_hotplug.lock){+.+.+.}, at: [] cpu_hotplug_begin+0x2b/0x60 [ 60.277465] which lock already depends on the new lock. [ 60.277472] the existing dependency chain (in reverse order) is: [ 60.277477] -> #2 (cpu_hotplug.lock){+.+.+.}: [ 60.277490] [] lock_acquire+0xa4/0x200 [ 60.277503] [] mutex_lock_nested+0x67/0x410 [ 60.277514] [] get_online_cpus+0x3c/0x60 [ 60.277522] [] gov_queue_work+0x2a/0xb0 [ 60.277532] [] cs_dbs_timer+0xc1/0xe0 [ 60.277543] [] process_one_work+0x1cd/0x6a0 [ 60.277552] [] worker_thread+0x121/0x3a0 [ 60.277560] [] kthread+0xdb/0xe0 [ 60.277569] [] ret_from_fork+0x7c/0xb0 [ 60.277580] -> #1 (&j_cdbs->timer_mutex){+.+...}: [ 60.277592] [] lock_acquire+0xa4/0x200 [ 60.277600] [] mutex_lock_nested+0x67/0x410 [ 60.277608] [] cs_dbs_timer+0x8d/0xe0 [ 60.277616] [] process_one_work+0x1cd/0x6a0 [ 60.277624] [] worker_thread+0x121/0x3a0 [ 60.277633] [] kthread+0xdb/0xe0 [ 60.277640] [] ret_from_fork+0x7c/0xb0 [ 60.277649] -> #0 ((&(&j_cdbs->work)->work)){+.+...}: [ 60.277661] [] __lock_acquire+0x1766/0x1d30 [ 60.277669] [] lock_acquire+0xa4/0x200 [ 60.277677] [] flush_work+0x3d/0x280 [ 60.277685] [] __cancel_work_timer+0x8a/0x120 [ 60.277693] [] cancel_delayed_work_sync+0x13/0x20 [ 60.277701] [] cpufreq_governor_dbs+0x529/0x6f0 [ 60.277709] [] cs_cpufreq_governor_dbs+0x17/0x20 [ 60.277719] [] __cpufreq_governor+0x48/0x100 [ 60.277728] [] __cpufreq_remove_dev.isra.14+0x80/0x3c0 [ 60.277737] [] cpufreq_cpu_callback+0x38/0x4c [ 60.277747] [] notifier_call_chain+0x5d/0x110 [ 60.277759] [] __raw_notifier_call_chain+0xe/0x10 [ 60.277768] [] _cpu_down+0x88/0x330 [ 60.277779] [] cpu_down+0x36/0x50 [ 60.277788] [] store_online+0x98/0xd0 [ 60.277796] [] dev_attr_store+0x18/0x30 [ 60.277806] [] sysfs_write_file+0xdb/0x150 [ 60.277818] [] vfs_write+0xbd/0x1f0 [ 60.277826] [] SyS_write+0x4c/0xa0 [ 60.277834] [] tracesys+0xd0/0xd5 [ 60.277842] other info that might help us debug this: [ 60.277848] Chain exists of: (&(&j_cdbs->work)->work) --> &j_cdbs->timer_mutex --> cpu_hotplug.lock [ 60.277864] Possible unsafe locking scenario: [ 60.277869] CPU0 CPU1 [ 60.277873] ---- ---- [ 60.277877] lock(cpu_hotplug.lock); [ 60.277885] lock(&j_cdbs->timer_mutex); [ 60.277892] lock(cpu_hotplug.lock); [ 60.277900] lock((&(&j_cdbs->work)->work)); [ 60.277907] *** DEADLOCK *** [ 60.277915] 6 locks held by bash/2225: [ 60.277919] #0: (sb_writers#6){.+.+.+}, at: [] vfs_write+0x1c3/0x1f0 [ 60.277937] #1: (&buffer->mutex){+.+.+.}, at: [] sysfs_write_file+0x3c/0x150 [ 60.277954] #2: (s_active#61){.+.+.+}, at: [] sysfs_write_file+0xc3/0x150 [ 60.277972] #3: (x86_cpu_hotplug_driver_mutex){+.+...}, at: [] cpu_hotplug_driver_lock+0x17/0x20 [ 60.277990] #4: (cpu_add_remove_lock){+.+.+.}, at: [] cpu_down+0x22/0x50 [ 60.278007] #5: (cpu_hotplug.lock){+.+.+.}, at: [] cpu_hotplug_begin+0x2b/0x60 [ 60.278023] stack backtrace: [ 60.278031] CPU: 3 PID: 2225 Comm: bash Not tainted 3.10.0-rc7-dbg-01385-g241fd04-dirty #1744 [ 60.278037] Hardware name: Acer Aspire 5741G /Aspire 5741G , BIOS V1.20 02/08/2011 [ 60.278042] ffffffff8204e110 ffff88014df6b9f8 ffffffff815b3d90 ffff88014df6ba38 [ 60.278055] ffffffff815b0a8d ffff880150ed3f60 ffff880150ed4770 3871c4002c8980b2 [ 60.278068] ffff880150ed4748 ffff880150ed4770 ffff880150ed3f60 ffff88014df6bb00 [ 60.278081] Call Trace: [ 60.278091] [] dump_stack+0x19/0x1b [ 60.278101] [] print_circular_bug+0x2b6/0x2c5 [ 60.278111] [] __lock_acquire+0x1766/0x1d30 [ 60.278123] [] ? __kernel_text_address+0x58/0x80 [ 60.278134] [] lock_acquire+0xa4/0x200 [ 60.278142] [] ? flush_work+0x5/0x280 [ 60.278151] [] flush_work+0x3d/0x280 [ 60.278159] [] ? flush_work+0x5/0x280 [ 60.278169] [] ? mark_held_locks+0x94/0x140 [ 60.278178] [] ? __cancel_work_timer+0x77/0x120 [ 60.278188] [] ? trace_hardirqs_on_caller+0xfd/0x1c0 [ 60.278196] [] __cancel_work_timer+0x8a/0x120 [ 60.278206] [] cancel_delayed_work_sync+0x13/0x20 [ 60.278214] [] cpufreq_governor_dbs+0x529/0x6f0 [ 60.278225] [] cs_cpufreq_governor_dbs+0x17/0x20 [ 60.278234] [] __cpufreq_governor+0x48/0x100 [ 60.278244] [] __cpufreq_remove_dev.isra.14+0x80/0x3c0 [ 60.278255] [] cpufreq_cpu_callback+0x38/0x4c [ 60.278265] [] notifier_call_chain+0x5d/0x110 [ 60.278275] [] __raw_notifier_call_chain+0xe/0x10 [ 60.278284] [] _cpu_down+0x88/0x330 [ 60.278292] [] ? cpu_hotplug_driver_lock+0x17/0x20 [ 60.278302] [] cpu_down+0x36/0x50 [ 60.278311] [] store_online+0x98/0xd0 [ 60.278320] [] dev_attr_store+0x18/0x30 [ 60.278329] [] sysfs_write_file+0xdb/0x150 [ 60.278337] [] vfs_write+0xbd/0x1f0 [ 60.278347] [] ? fget_light+0x320/0x4b0 [ 60.278355] [] SyS_write+0x4c/0xa0 [ 60.278364] [] tracesys+0xd0/0xd5 [ 60.280582] smpboot: CPU 1 is now offline The intention of that commit was to avoid warnings during CPU hotplug, which indicated that offline CPUs were getting IPIs from the cpufreq governor's work items. But the real root-cause of that problem was commit a66b2e5 (cpufreq: Preserve sysfs files across suspend/resume) because it totally skipped all the cpufreq callbacks during CPU hotplug in the suspend/resume path, and hence it never actually shut down the cpufreq governor's worker threads during CPU offline in the suspend/resume path. Reflecting back, the reason why we never suspected that commit as the root-cause earlier, was that the original issue was reported with just the halt command and nobody had brought in suspend/resume to the equation. The reason for _that_ in turn, as it turns out, is that earlier halt/shutdown was being done by disabling non-boot CPUs while tasks were frozen, just like suspend/resume.... but commit cf7df378a (reboot: migrate shutdown/reboot to boot cpu) which came somewhere along that very same time changed that logic: shutdown/halt no longer takes CPUs offline. Thus, the test-cases for reproducing the bug were vastly different and thus we went totally off the trail. Overall, it was one hell of a confusion with so many commits affecting each other and also affecting the symptoms of the problems in subtle ways. Finally, now since the original problematic commit (a66b2e5) has been completely reverted, revert this intermediate fix too (2f7021a8), to fix the CPU hotplug deadlock. Phew! Reported-by: Sergey Senozhatsky Reported-by: Bartlomiej Zolnierkiewicz Signed-off-by: Srivatsa S. Bhat Tested-by: Peter Wu Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit 9d3ce4af3be0235d4cf41ea9fd774205a32e58a2 Author: Srivatsa S. Bhat Date: Fri Jul 12 03:45:37 2013 +0530 cpufreq: Revert commit a66b2e to fix suspend/resume regression commit aae760ed21cd690fe8a6db9f3a177ad55d7e12ab upstream. commit a66b2e (cpufreq: Preserve sysfs files across suspend/resume) has unfortunately caused several things in the cpufreq subsystem to break subtly after a suspend/resume cycle. The intention of that patch was to retain the file permissions of the cpufreq related sysfs files across suspend/resume. To achieve that, the commit completely removed the calls to cpufreq_add_dev() and __cpufreq_remove_dev() during suspend/resume transitions. But the problem is that those functions do 2 kinds of things: 1. Low-level initialization/tear-down that are critical to the correct functioning of cpufreq-core. 2. Kobject and sysfs related initialization/teardown. Ideally we should have reorganized the code to cleanly separate these two responsibilities, and skipped only the sysfs related parts during suspend/resume. Since we skipped the entire callbacks instead (which also included some CPU and cpufreq-specific critical components), cpufreq subsystem started behaving erratically after suspend/resume. So revert the commit to fix the regression. We'll revisit and address the original goal of that commit separately, since it involves quite a bit of careful code reorganization and appears to be non-trivial. (While reverting the commit, note that another commit f51e1eb (cpufreq: Fix cpufreq regression after suspend/resume) already reverted part of the original set of changes. So revert only the remaining ones). Signed-off-by: Srivatsa S. Bhat Acked-by: Viresh Kumar Tested-by: Paul Bolle Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit 382b9efb7be2d07e51f0a491ecd0a985e1ceb86e Author: Michael Ellerman Date: Fri Jun 28 18:15:14 2013 +1000 powerpc/perf: Don't enable if we have zero events commit 4ea355b5368bde0574c12430df53334c4be3bdcf upstream. In power_pmu_enable() we still enable the PMU even if we have zero events. This should have no effect but doesn't make much sense. Instead just return after telling the hypervisor that we are not using the PMCs. Signed-off-by: Michael Ellerman Signed-off-by: Benjamin Herrenschmidt Signed-off-by: Greg Kroah-Hartman commit b26eb91187fdfa37b304b30003f799899e6373c9 Author: Michael Ellerman Date: Fri Jun 28 18:15:13 2013 +1000 powerpc/perf: Use existing out label in power_pmu_enable() commit 0a48843d6c5114cfa4a9540ee4d6af87628cec01 upstream. In power_pmu_enable() we can use the existing out label to reduce the number of return paths. Signed-off-by: Michael Ellerman Signed-off-by: Benjamin Herrenschmidt Signed-off-by: Greg Kroah-Hartman commit 8f6c5b6c1264c6cec9b04848d0744aac0853d641 Author: Michael Ellerman Date: Fri Jun 28 18:15:12 2013 +1000 powerpc/perf: Freeze PMC5/6 if we're not using them commit 7a7a41f9d5b28ac3a916b057a7d3cd3f435ee9a6 upstream. On Power8 we can freeze PMC5 and 6 if we're not using them. Normally they run all the time. As noticed by Anshuman, we should unfreeze them when we disable the PMU as there are legacy tools which expect them to run all the time. Signed-off-by: Michael Ellerman Signed-off-by: Benjamin Herrenschmidt Signed-off-by: Greg Kroah-Hartman commit 8cf3478f19143d4e2ece4947603bff7dbd360a36 Author: Michael Ellerman Date: Fri Jun 28 18:15:11 2013 +1000 powerpc/perf: Rework disable logic in pmu_disable() commit 378a6ee99e4a431ec84e4e61893445c041c93007 upstream. In pmu_disable() we disable the PMU by setting the FC (Freeze Counters) bit in MMCR0. In order to do this we have to read/modify/write MMCR0. It's possible that we read a value from MMCR0 which has PMAO (PMU Alert Occurred) set. When we write that value back it will cause an interrupt to occur. We will then end up in the PMU interrupt handler even though we are supposed to have just disabled the PMU. We can avoid this by making sure we never write PMAO back. We should not lose interrupts because when the PMU is re-enabled the overflowed values will cause another interrupt. We also reorder the clearing of SAMPLE_ENABLE so that is done after the PMU is frozen. Otherwise there is a small window between the clearing of SAMPLE_ENABLE and the setting of FC where we could take an interrupt and incorrectly see SAMPLE_ENABLE not set. This would for example change the logic in perf_read_regs(). Signed-off-by: Michael Ellerman Signed-off-by: Benjamin Herrenschmidt Signed-off-by: Greg Kroah-Hartman commit a9514fe520175d13cba23cf3c9dbba4df9691c86 Author: Michael Ellerman Date: Fri Jun 28 18:15:10 2013 +1000 powerpc/perf: Check that events only include valid bits on Power8 commit d8bec4c9cd58f6d3679e09b7293851fb92ad7557 upstream. A mistake we have made in the past is that we pull out the fields we need from the event code, but don't check that there are no unknown bits set. This means that we can't ever assign meaning to those unknown bits in future. Although we have once again failed to do this at release, it is still early days for Power8 so I think we can still slip this in and get away with it. Signed-off-by: Michael Ellerman Signed-off-by: Benjamin Herrenschmidt Signed-off-by: Greg Kroah-Hartman commit 910a165889c9e0c79cb96883db3948c5eea204e2 Author: Nathan Fontenot Date: Mon Jun 24 22:08:05 2013 -0500 powerpc/numa: Do not update sysfs cpu registration from invalid context commit dd023217e17e72b46fb4d49c7734c426938c3dba upstream. The topology update code that updates the cpu node registration in sysfs should not be called while in stop_machine(). The register/unregister calls take a lock and may sleep. This patch moves these calls outside of the call to stop_machine(). Signed-off-by: Nathan Fontenot Signed-off-by: Benjamin Herrenschmidt Signed-off-by: Greg Kroah-Hartman commit 0288917da5e378ea1fc0290f824d85ac9e07570d Author: Chen Gang Date: Wed Mar 20 14:30:12 2013 +0800 powerpc/smp: Section mismatch from smp_release_cpus to __initdata spinning_secondaries commit 8246aca7058f3f2c2ae503081777965cd8df7b90 upstream. the smp_release_cpus is a normal funciton and called in normal environments, but it calls the __initdata spinning_secondaries. need modify spinning_secondaries to match smp_release_cpus. the related warning: (the linker report boot_paca.33377, but it should be spinning_secondaries) ----------------------------------------------------------------------------- WARNING: arch/powerpc/kernel/built-in.o(.text+0x23176): Section mismatch in reference from the function .smp_release_cpus() to the variable .init.data:boot_paca.33377 The function .smp_release_cpus() references the variable __initdata boot_paca.33377. This is often because .smp_release_cpus lacks a __initdata annotation or the annotation of boot_paca.33377 is wrong. WARNING: arch/powerpc/kernel/built-in.o(.text+0x231fe): Section mismatch in reference from the function .smp_release_cpus() to the variable .init.data:boot_paca.33377 The function .smp_release_cpus() references the variable __initdata boot_paca.33377. This is often because .smp_release_cpus lacks a __initdata annotation or the annotation of boot_paca.33377 is wrong. ----------------------------------------------------------------------------- Signed-off-by: Chen Gang Signed-off-by: Benjamin Herrenschmidt Signed-off-by: Greg Kroah-Hartman commit d24966cf890f3b22e379654ba70a38ad9a67d9db Author: Michael Ellerman Date: Tue Jun 25 17:47:57 2013 +1000 powerpc: Wire up the HV facility unavailable exception commit b14b6260efeee6eb8942c6e6420e31281892acb6 upstream. Similar to the facility unavailble exception, except the facilities are controlled by HFSCR. Adapt the facility_unavailable_exception() so it can be called for either the regular or Hypervisor facility unavailable exceptions. Signed-off-by: Michael Ellerman Signed-off-by: Benjamin Herrenschmidt Signed-off-by: Greg Kroah-Hartman commit 8e0af91a12c135f6c22e472660f3400d46ed78ac Author: Michael Ellerman Date: Tue Jun 25 17:47:56 2013 +1000 powerpc: Rename and flesh out the facility unavailable exception handler commit 021424a1fce335e05807fd770eb8e1da30a63eea upstream. The exception at 0xf60 is not the TM (Transactional Memory) unavailable exception, it is the "Facility Unavailable Exception", rename it as such. Flesh out the handler to acknowledge the fact that it can be called for many reasons, one of which is TM being unavailable. Use STD_EXCEPTION_COMMON() for the exception body, for some reason we had it open-coded, I've checked the generated code is identical. Signed-off-by: Michael Ellerman Signed-off-by: Benjamin Herrenschmidt Signed-off-by: Greg Kroah-Hartman commit 77d8caacd2924ca7cbb989c30709503e93c7f026 Author: Michael Ellerman Date: Tue Jun 25 17:47:55 2013 +1000 powerpc: Remove KVMTEST from RELON exception handlers commit c9f69518e5f08170bc857984a077f693d63171df upstream. KVMTEST is a macro which checks whether we are taking an exception from guest context, if so we branch out of line and eventually call into the KVM code to handle the switch. When running real guests on bare metal (HV KVM) the hardware ensures that we never take a relocation on exception when transitioning from guest to host. For PR KVM we disable relocation on exceptions ourself in kvmppc_core_init_vm(), as of commit a413f47 "Disable relocation on exceptions whenever PR KVM is active". So convert all the RELON macros to use NOTEST, and drop the remaining KVM_HANDLER() definitions we have for 0xe40 and 0xe80. Signed-off-by: Michael Ellerman Signed-off-by: Benjamin Herrenschmidt Signed-off-by: Greg Kroah-Hartman commit 497f0957430403bc4e3a0c776da3907fe769b64f Author: Michael Ellerman Date: Tue Jun 25 17:47:54 2013 +1000 powerpc: Remove unreachable relocation on exception handlers commit 1d567cb4bd42d560a7621cac6f6aebe87343689e upstream. We have relocation on exception handlers defined for h_data_storage and h_instr_storage. However we will never take relocation on exceptions for these because they can only come from a guest, and we never take relocation on exceptions when we transition from guest to host. We also have a handler for hmi_exception (Hypervisor Maintenance) which is defined in the architecture to never be delivered with relocation on, see see v2.07 Book III-S section 6.5. So remove the handlers, leaving a branch to self just to be double extra paranoid. Signed-off-by: Michael Ellerman Signed-off-by: Benjamin Herrenschmidt Signed-off-by: Greg Kroah-Hartman commit 81bcd526fea6383be0361b1827fcac656d276d57 Author: Michael Neuling Date: Sun Jun 9 21:23:19 2013 +1000 powerpc/tm: Fix return of active 64bit signals commit 87b4e5393af77f5cba124638f19f6c426e210aec upstream. Currently we only restore signals which are transactionally suspended but it's possible that the transaction can be restored even when it's active. Most likely this will result in a transactional rollback by the hardware as the transaction will have been doomed by an earlier treclaim. The current code is a legacy of earlier kernel implementations which did software rollback of active transactions in the kernel. That code has now gone but we didn't correctly fix up this part of the signals code which still makes assumptions based on having software rollback. This changes the signal return code to always restore both contexts on 64 bit signal return. It also ensures that the MSR TM bits are properly restored from the signal context which they are not currently. Signed-off-by: Michael Neuling Signed-off-by: Benjamin Herrenschmidt Signed-off-by: Greg Kroah-Hartman commit f6ff89fc47b05a061017200128ce154ae7165469 Author: Michael Neuling Date: Sun Jun 9 21:23:18 2013 +1000 powerpc/tm: Fix return of 32bit rt signals to active transactions commit 55e4341850ac56e63a3eefe9583a9000042164fa upstream. Currently we only restore signals which are transactionally suspended but it's possible that the transaction can be restored even when it's active. Most likely this will result in a transactional rollback by the hardware as the transaction will have been doomed by an earlier treclaim. The current code is a legacy of earlier kernel implementations which did software rollback of active transactions in the kernel. That code has now gone but we didn't correctly fix up this part of the signals code which still makes assumptions based on having software rollback. This changes the signal return code to always restore both contexts on 32 bit rt signal return. Signed-off-by: Michael Neuling Signed-off-by: Benjamin Herrenschmidt Signed-off-by: Greg Kroah-Hartman commit bc8ae5222e9e42582bd32028c638a5b4517e69e2 Author: Michael Neuling Date: Sun Jun 9 21:23:17 2013 +1000 powerpc/tm: Fix restoration of MSR on 32bit signal return commit 2c27a18f8736da047bef2b997bdd48efc667e3c9 upstream. Currently we clear out the MSR TM bits on signal return assuming that the signal should never return to an active transaction. This is bogus as the user may do this. It's most likely the transaction will be doomed due to a treclaim but that's a problem for the HW not the kernel. The current code is a legacy of earlier kernel implementations which did software rollback of active transactions in the kernel. That code has now gone but we didn't correctly fix up this part of the signals code which still makes the assumption that it must be returning to a suspended transaction. This pulls out both MSR TM bits from the user supplied context rather than just setting TM suspend. We pull out only the bits needed to ensure the user can't do anything dangerous to the MSR. Signed-off-by: Michael Neuling Signed-off-by: Benjamin Herrenschmidt Signed-off-by: Greg Kroah-Hartman commit 743834135bc07e3bb9d6166607b874443fe1537c Author: Michael Neuling Date: Sun Jun 9 21:23:16 2013 +1000 powerpc/tm: Fix 32 bit non-rt signals commit fee55450710dff32a13ae30b4129ec7b5a4b44d0 upstream. Currently sys_sigreturn() is TM unaware. Therefore, if we take a 32 bit signal without SIGINFO (non RT) inside a transaction, on signal return we don't restore the signal frame correctly. This checks if the signal frame being restoring is an active transaction, and if so, it copies the additional state to ptregs so it can be restored. Signed-off-by: Michael Neuling Signed-off-by: Benjamin Herrenschmidt Signed-off-by: Greg Kroah-Hartman commit d6ea4422c89da1b08029d4db10635942a3b29b2a Author: Michael Neuling Date: Sun Jun 9 21:23:15 2013 +1000 powerpc/tm: Fix writing top half of MSR on 32 bit signals commit 1d25f11fdbcc5390d68efd98c28900bfd29b264c upstream. The MSR TM controls are in the top 32 bits of the MSR hence on 32 bit signals, we stick the top half of the MSR in the checkpointed signal context so that the user can access it. Unfortunately, we don't currently write anything to the checkpointed signal context when coming in a from a non transactional process and hence the top MSR bits can contain junk. This updates the 32 bit signal handling code to always write something to the top MSR bits so that users know if the process is transactional or not and the kernel can use it on signal return. Signed-off-by: Michael Neuling Signed-off-by: Benjamin Herrenschmidt Signed-off-by: Greg Kroah-Hartman commit e544a74525b9accf4919822196f29cd967e7e5c0 Author: Benjamin Herrenschmidt Date: Mon Jul 1 17:54:09 2013 +1000 powerpc/powernv: Fix iommu initialization again commit 74251fe21bfa9310ddba9e0436d1fcf389e602ee upstream. So because those things always end up in trainwrecks... In 7846de406 we moved back the iommu initialization earlier, essentially undoing 37f02195b which was causing us endless trouble... except that in the meantime we had merged 959c9bdd58 (to workaround the original breakage) which is now ... broken :-) This fixes it by doing a partial revert of the latter (we keep the ppc_md. path which will be needed in the hotplug case, which happens also during some EEH error recovery situations). Signed-off-by: Benjamin Herrenschmidt Signed-off-by: Greg Kroah-Hartman commit 3b743326ed2edd5e118950874f7bdaed5759f977 Author: Michael Neuling Date: Mon Jul 1 14:19:50 2013 +1000 powerpc/hw_brk: Fix off by one error when validating DAWR region end commit e2a800beaca1f580945773e57d1a0e7cd37b1056 upstream. The Data Address Watchpoint Register (DAWR) on POWER8 can take a 512 byte range but this range must not cross a 512 byte boundary. Unfortunately we were off by one when calculating the end of the region, hence we were not allowing some breakpoint regions which were actually valid. This fixes this error. Signed-off-by: Michael Neuling Reported-by: Edjunior Barbosa Machado Signed-off-by: Benjamin Herrenschmidt Signed-off-by: Greg Kroah-Hartman commit 277b5ae153a96d594ae6d61b244b936d6f77ff56 Author: Michael Neuling Date: Mon Jun 24 15:47:23 2013 +1000 powerpc/hw_brk: Fix clearing of extraneous IRQ commit 540e07c67efe42ef6b6be4f1956931e676d58a15 upstream. In 9422de3 "powerpc: Hardware breakpoints rewrite to handle non DABR breakpoint registers" we changed the way we mark extraneous irqs with this: - info->extraneous_interrupt = !((bp->attr.bp_addr <= dar) && - (dar - bp->attr.bp_addr < bp->attr.bp_len)); + if (!((bp->attr.bp_addr <= dar) && + (dar - bp->attr.bp_addr < bp->attr.bp_len))) + info->type |= HW_BRK_TYPE_EXTRANEOUS_IRQ; Unfortunately this is bogus as it never clears extraneous IRQ if it's already set. This correctly clears extraneous IRQ before possibly setting it. Signed-off-by: Michael Neuling Reported-by: Edjunior Barbosa Machado Signed-off-by: Benjamin Herrenschmidt Signed-off-by: Greg Kroah-Hartman commit b101957a5871ec616e18a8a6f0330d0e06a05754 Author: Michael Neuling Date: Mon Jun 24 15:47:22 2013 +1000 powerpc/hw_brk: Fix setting of length for exact mode breakpoints commit b0b0aa9c7faf94e92320eabd8a1786c7747e40a8 upstream. The smallest match region for both the DABR and DAWR is 8 bytes, so the kernel needs to filter matches when users want to look at regions smaller than this. Currently we set the length of PPC_BREAKPOINT_MODE_EXACT breakpoints to 8. This is wrong as in exact mode we should only match on 1 address, hence the length should be 1. This ensures that the kernel will filter out any exact mode hardware breakpoint matches on any addresses other than the requested one. Signed-off-by: Michael Neuling Reported-by: Edjunior Barbosa Machado Signed-off-by: Benjamin Herrenschmidt Signed-off-by: Greg Kroah-Hartman