- 29 Aug, 2013 31 commits
-
-
Oleg Nesterov authored
commit bf682c31 upstream. Change remove_event_file_dir() to clear ->i_private for every file we are going to remove. We need to check file->dir != NULL because event_create_dir() can fail. debugfs_remove_recursive(NULL) is fine but the patch moves it under the same check anyway for readability. spin_lock(d_lock) and "d_inode != NULL" check are not needed afaics, but I do not understand this code enough. tracing_open_generic_file() and tracing_release_generic_file() can go away, ftrace_enable_fops and ftrace_event_filter_fops() use tracing_open_generic() but only to check tracing_disabled. This fixes all races with event_remove() or instance_delete(). f_op->read/write/whatever can never use the freed file/call, all event/* files were changed to check and use ->i_private under event_mutex. Note: this doesn't not fix other problems, event_remove() can destroy the active ftrace_event_call, we need more changes but those changes are completely orthogonal. Link: http://lkml.kernel.org/r/20130728183527.GB16723@redhat.comReviewed-by:
Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com> Signed-off-by:
Oleg Nesterov <oleg@redhat.com> Signed-off-by:
Steven Rostedt <rostedt@goodmis.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Oleg Nesterov authored
commit f6a84bdc upstream. Preparation for the next patch. Extract the common code from remove_event_from_tracers() and __trace_remove_event_dirs() into the new helper, remove_event_file_dir(). The patch looks more complicated than it actually is, it also moves remove_subsystem() up to avoid the forward declaration. Link: http://lkml.kernel.org/r/20130726172547.GA3629@redhat.comReviewed-by:
-
Oleg Nesterov authored
commit c5a44a12 upstream. trace_format_open() and trace_format_seq_ops are racy, nothing protects ftrace_event_call from trace_remove_event_call(). Change f_start() to take event_mutex and verify i_private != NULL, change f_stop() to drop this lock. This fixes nothing, but now we can change debugfs_remove("format") callers to nullify ->i_private and fix the the problem. Note: the usage of event_mutex is sub-optimal but simple, we can change this later. Link: http://lkml.kernel.org/r/20130726172543.GA3622@redhat.comReviewed-by:
-
Oleg Nesterov authored
commit e2912b09 upstream. event_filter_read/write() are racy, ftrace_event_call can be already freed by trace_remove_event_call() callers. 1. Shift mutex_lock(event_mutex) from print/apply_event_filter to the callers. 2. Change the callers, event_filter_read() and event_filter_write() to read i_private under this mutex and abort if it is NULL. This fixes nothing, but now we can change debugfs_remove("filter") callers to nullify ->i_private and fix the the problem. Link: http://lkml.kernel.org/r/20130726172540.GA3619@redhat.comReviewed-by:
-
Oleg Nesterov authored
commit bc6f6b08 upstream. tracing_open_generic_file() is racy, ftrace_event_file can be already freed by rmdir or trace_remove_event_call(). Change event_enable_read() and event_disable_read() to read and verify "file = i_private" under event_mutex. This fixes nothing, but now we can change debugfs_remove("enable") callers to nullify ->i_private and fix the the problem. Link: http://lkml.kernel.org/r/20130726172536.GA3612@redhat.comReviewed-by:
-
Oleg Nesterov authored
commit 1a11126b upstream. event_id_read() is racy, ftrace_event_call can be already freed by trace_remove_event_call() callers. Change event_create_dir() to pass "data = call->event.type", this is all event_id_read() needs. ftrace_event_id_fops no longer needs tracing_open_generic(). We add the new helper, event_file_data(), to read ->i_private, it will have more users. Note: currently ACCESS_ONCE() and "id != 0" check are not needed, but we are going to change event_remove/rmdir to clear ->i_private. Link: http://lkml.kernel.org/r/20130726172532.GA3605@redhat.comReviewed-by:
-
Steven Rostedt (Red Hat) authored
commit 195a8afc upstream. If a ftrace ops is registered with the SAVE_REGS flag set, and there's already a ops registered to one of its functions but without the SAVE_REGS flag, there's a small race window where the SAVE_REGS ops gets added to the list of callbacks to call for that function before the callback trampoline gets set to save the regs. The problem is, the function is not currently saving regs, which opens a small race window where the ops that is expecting regs to be passed to it, wont. This can cause a crash if the callback were to reference the regs, as the SAVE_REGS guarantees that regs will be set. To fix this, we add a check in the loop case where it checks if the ops has the SAVE_REGS flag set, and if so, it will ignore it if regs is not set. Signed-off-by:
-
Oleg Nesterov authored
commit 6484c71c upstream. tracing_open() and tracing_snapshot_open() are racy, the memory inode->i_private points to can be already freed. Convert these last users of "inode->i_private == trace_cpu" to use "i_private = trace_array" and rely on tracing_get_cpu(). v2: incorporate the fix from Steven, tracing_release() must not blindly dereference file->private_data unless we know that the file was opened for reading. Link: http://lkml.kernel.org/r/20130723152610.GA23737@redhat.comSigned-off-by:
-
Oleg Nesterov authored
commit 0bc392ee upstream. tracing_open_generic_tc() is racy, the memory inode->i_private points to can be already freed. 1. Change its last user, tracing_entries_fops, to use tracing_*_generic_tr() instead. 2. Change debugfs_create_file("buffer_size_kb", data) callers to pass "data = tr". 3. Change tracing_entries_read() and tracing_entries_write() to use tracing_get_cpu(). 4. Kill the no longer used tracing_open_generic_tc() and tracing_release_generic_tc(). Link: http://lkml.kernel.org/r/20130723152606.GA23730@redhat.comSigned-off-by:
-
Oleg Nesterov authored
commit 4d3435b8 upstream. tracing_open_generic_tc() is racy, the memory inode->i_private points to can be already freed. 1. Change one of its users, tracing_stats_fops, to use tracing_*_generic_tr() instead. 2. Change trace_create_cpu_file("stats", data) to pass "data = tr". 3. Change tracing_stats_read() to use tracing_get_cpu(). Link: http://lkml.kernel.org/r/20130723152603.GA23727@redhat.comSigned-off-by:
-
Oleg Nesterov authored
commit 46ef2be0 upstream. tracing_buffers_open() is racy, the memory inode->i_private points to can be already freed. Change debugfs_create_file("trace_pipe_raw", data) caller to pass "data = tr", tracing_buffers_open() can use tracing_get_cpu(). Change debugfs_create_file("snapshot_raw_fops", data) caller too, this file uses tracing_buffers_open/release. Link: http://lkml.kernel.org/r/20130723152600.GA23720@redhat.comSigned-off-by:
-
Oleg Nesterov authored
commit 15544209 upstream. tracing_open_pipe() is racy, the memory inode->i_private points to can be already freed. Change debugfs_create_file("trace_pipe", data) callers to to pass "data = tr", tracing_open_pipe() can use tracing_get_cpu(). Link: http://lkml.kernel.org/r/20130723152557.GA23717@redhat.comSigned-off-by:
-
Oleg Nesterov authored
commit 649e9c70 upstream. Every "file_operations" used by tracing_init_debugfs_percpu is buggy. f_op->open/etc does: 1. struct trace_cpu *tc = inode->i_private; struct trace_array *tr = tc->tr; 2. trace_array_get(tr) or fail; 3. do_something(tc); But tc (and tr) can be already freed before trace_array_get() is called. And it doesn't matter whether this file is per-cpu or it was created by init_tracer_debugfs(), free_percpu() or kfree() are equally bad. Note that even 1. is not safe, the freed memory can be unmapped. But even if it was safe trace_array_get() can wrongly succeed if we also race with the next new_instance_create() which can re-allocate the same tr, or tc was overwritten and ->tr points to the valid tr. In this case 3. uses the freed/reused memory. Add the new trivial helper, trace_create_cpu_file() which simply calls trace_create_file() and encodes "cpu" in "struct inode". Another helper, tracing_get_cpu() will be used to read cpu_nr-or-RING_BUFFER_ALL_CPUS. The patch abuses ->i_cdev to encode the number, it is never used unless the file is S_ISCHR(). But we could use something else, say, i_bytes or even ->d_fsdata. In any case this hack is hidden inside these 2 helpers, it would be trivial to change them if needed. This patch only changes tracing_init_debugfs_percpu() to use the new trace_create_cpu_file(), the next patches will change file_operations. Note: tracing_get_cpu(inode) is always safe but you can't trust the result unless trace_array_get() was called, without trace_types_lock which acts as a barrier it can wrongly return RING_BUFFER_ALL_CPUS. Link: http://lkml.kernel.org/r/20130723152554.GA23710@redhat.com Cc: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by:
-
Masami Hiramatsu authored
commit a232e270 upstream. Wait for disabling all running kprobe handlers when a kprobe event is disabled, since the caller, trace_remove_event_call() supposes that a removing event is disabled completely by disabling the event. With this change, ftrace can ensure that there is no running event handlers after disabling it. Link: http://lkml.kernel.org/r/20130709093526.20138.93100.stgit@mhiramat-M0-7522Signed-off-by:
-
Namhyung Kim authored
commit aaf6ac0f upstream. There's no point calling it when _alloc() failed. Link: http://lkml.kernel.org/r/1370585268-29169-1-git-send-email-namhyung@kernel.orgSigned-off-by:
Namhyung Kim <namhyung@kernel.org> Signed-off-by:
-
Johannes Berg authored
commit dfcb4c3a upstream. The D3 firmware API changed to include a new field, adjust the driver to it to avoid getting an NMI when configuring. Signed-off-by:
Johannes Berg <johannes.berg@intel.com> Signed-off-by:
-
Johannes Berg authored
commit a2d0909a upstream. As the firmware API has changed significantly and we don't have support code for the old APIs, bump the version to be able to release the version 7 API firmware. Unfortunately this means that the driver in 3.9 and 3.10 can't work, but that's still better than crashing the device/driver there. Signed-off-by:
-
Emmanuel Grumbach authored
commit b7327d89 upstream. This was missing and prevented any further attempts to load the module. Signed-off-by:
Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by:
Johannes Berg <johannes@sipsolutions.net> Signed-off-by:
-
Emmanuel Grumbach authored
commit ebea2f32 upstream. The fw is unreliable in all the cases in which the packet wasn't sent. Signed-off-by:
-
Emmanuel Grumbach authored
commit 837fb69f upstream. The MCAST queue should be enabled after DTIM only. According to fw API, the MCAST must not be attached to any station, but should appear in the mcast_qid of the AP's mac context only. Signed-off-by:
-
Emmanuel Grumbach authored
commit 5af01772 upstream. The firmware API wasn't being used correctly, fix that. Signed-off-by:
-
Emmanuel Grumbach authored
commit 9116a368 upstream. In multicast, there is no retries nor RTS since there is no specific recipient that can ACK or send CTS. This means that we must not use the rate scale table for multicast frames. This true for any frame that doesn't have a valid ieee80211_sta pointer. Signed-off-by:
-
Emmanuel Grumbach authored
commit 86a91ec7 upstream. The AP mode needs to use the MCAST fifo for the MCAST frames sent after the DTIM. This fifo needs to be configured with the same parameters as the VOICE FIFO. A separate SCD queue is mapped to this fifo - the cab_queue (cab stands for Content After Beacon). This queue isn't connected to any station, but rather to the MAC context. This queue should (and is already) be set as the MCAST queue - this is part of the of MAC context command. Signed-off-by:
Ilan Peer <ilan.peer@intel.com> Signed-off-by:
-
Samuel Ortiz authored
commit b4011239 upstream. Without the new LLCP_CONNECTING state, non blocking sockets will be woken up with a POLLHUP right after calling connect() because their state is stuck at LLCP_CLOSED. That prevents userspace from implementing any proper non blocking socket based NFC p2p client. Signed-off-by:
Samuel Ortiz <sameo@linux.intel.com> Signed-off-by:
-
Nicolas Ferre authored
commit 23fb05c6 upstream. Due to a bug with RTC IMR, we cannot consider at91sam9x5 RTC compatible with the previous one. Modify DT compatibility string, even if the driver is not yet modified to take it into account. Signed-off-by:
Nicolas Ferre <nicolas.ferre@atmel.com> Signed-off-by:
-
Vineet Gupta authored
[Based on mainline commit 352c1d95: "ARC: stop using pt_regs->orig_r8"] Stop using orig_r8 as it could get clobbered by ST in trap_with_param, and further it is semantically not needed either. Signed-off-by:
Vineet Gupta <vgupta@synopsys.com> Signed-off-by:
-
Vineet Gupta authored
[Based on mainline commit 502a0c77: "ARC: pt_regs update #5"] gdbserver needs @stop_pc, served by ptrace, but fetched from pt_regs differently, based on in_brkpt_traps(), which in turn relies on additional machine state in pt_regs->event bitfield. unsigned long orig_r8:16, event:16; For big endian config, this macro was returning false, despite being in breakpoint Trap exception, causing wrong @stop_pc to be returned to gdb. Issue #1: In BE, @event above is at offset 2 in word, while a STW insn at offset 0 was used to update it. Resort to using ST insn which updates the half-word at right location. Issue #2: The union involving bitfields causes all the members to be laid out at offset 0. So with fix #1 above, ASM was now updating at offset 2, "C" code was still referencing at offset 0. Fixed by wrapping bitfield in a struct. Reported-by:
Noam Camus <noamc@ezchip.com> Tested-by:
Anton Kolesov <akolesov@synopsys.com> Signed-off-by:
-
Rafael J. Wysocki authored
commit 60f75b8e upstream. In theory, under a given ACPI namespace node there should be only one child device object with _ADR whose value matches a given bus address exactly. In practice, however, there are systems in which multiple child device objects under a given parent have _ADR matching exactly the same address. In those cases we use _STA to determine which of the multiple matching devices is enabled, since some systems are known to indicate which ACPI device object to associate with the given physical (usually PCI) device this way. Unfortunately, as it turns out, there are systems in which many device objects under the same parent have _ADR matching exactly the same bus address and none of them has _STA, in which case they all should be regarded as enabled according to the spec. Still, if those device objects are supposed to represent bridges (e.g. this is the case for device objects corresponding to PCIe ports), we can try harder and skip the ones that have no child device objects in the ACPI namespace. With luck, we can avoid using device objects that we are not expected to use this way. Although this only works for bridges whose children also have ACPI namespace representation, it is sufficient to address graphics adapter detection issues on some systems, so rework the code finding a matching device ACPI handle for a given bus address to implement this idea. Introduce a new function, acpi_find_child(), taking three arguments: the ACPI handle of the device's parent, a bus address suitable for the device's bus type and a bool indicating if the device is a bridge and make it work as outlined above. Reimplement the function currently used for this purpose, acpi_get_child(), as a call to acpi_find_child() with the last argument set to 'false' and make the PCI subsystem use acpi_find_child() with the bridge information passed as the last argument to it. [Lan Tianyu notices that it is not sufficient to use pci_is_bridge() for that, because the device's subordinate pointer hasn't been set yet at this point, so use hdr_type instead.] This change fixes a regression introduced inadvertently by commit 33f767d7 (ACPI: Rework acpi_get_child() to be more efficient) which overlooked the fact that for acpi_walk_namespace() "post-order" means "after all children have been visited" rather than "on the way back", so for device objects without children and for namespace walks of depth 1, as in the acpi_get_child() case, the "post-order" callbacks ordering is actually the same as the ordering of "pre-order" ones. Since that commit changed the namespace walk in acpi_get_child() to terminate after finding the first matching object instead of going through all of them and returning the last one, it effectively changed the result returned by that function in some rare cases and that led to problems (the switch from a "pre-order" to a "post-order" callback was supposed to prevent that from happening, but it was ineffective). As it turns out, the systems where the change made by commit 33f767d7 actually matters are those where there are multiple ACPI device objects representing the same PCIe port (which effectively is a bridge). Moreover, only one of them, and the one we are expected to use, has child device objects in the ACPI namespace, so the regression can be addressed as described above. References: https://bugzilla.kernel.org/show_bug.cgi?id=60561Reported-by:
Peter Wu <lekensteyn@gmail.com> Tested-by:
Vladimir Lalov <mail@vlalov.com> Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by:
Bjorn Helgaas <bhelgaas@google.com> Cc: Peter Wu <lekensteyn@gmail.com> Signed-off-by:
-
Jeff Wu authored
commit c7d9ca90 upstream. Once do_acpi_find_child() has found the first matching handle, it makes the acpi_get_child() loop stop and return that handle. On some platforms, though, there are multiple devices with the same value of "_ADR" in the same namespace scope, and if one of them is enabled, the others will be disabled. For example: Address : 0x1FFFF ; path : SB_PCI0.SATA.DEV0 Address : 0x1FFFF ; path : SB_PCI0.SATA.DEV1 Address : 0x1FFFF ; path : SB_PCI0.SATA.DEV2 If DEV0 and DEV1 are disabled and DEV2 is enabled, the handle of DEV2 should be returned, but actually the function always returns the handle of DEV0. To address that issue, make do_acpi_find_child() evaluate _STA to check the device status. If a matching device object exists, but is disabled, acpi_get_child() will continue to walk the namespace in the hope of finding an enabled one. If one is found, its handle will be returned, but otherwise the function will return the handle of the disabled object found before (in case it is enabled going forward). [rjw: Changelog] Signed-off-by:
Jeff Wu <zlinuxkernel@gmail.com> Signed-off-by:
-
Johannes Berg authored
commit cb236d2d upstream. TX status notification can get lost, or the frames could get stuck on the queue, so don't wait for the callback from the driver forever and instead time out after half a second. Signed-off-by:
Luciano Coelho <luciano.coelho@intel.com> Signed-off-by:
-
Dominik Dingel authored
commit 2b29a9fd upstream. Any uaccess between guest_enter and guest_exit could trigger a page fault, the page fault handler would handle it as a guest fault and translate a user address as guest address. Signed-off-by:
Dominik Dingel <dingel@linux.vnet.ibm.com> Signed-off-by:
Christian Borntraeger <borntraeger@de.ibm.com> Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com> Signed-off-by:
-
- 20 Aug, 2013 9 commits
-
-
Greg Kroah-Hartman authored
-
Greg Kroah-Hartman authored
This reverts commit aab4f8d4, commit 58ad436f upstream, as it causes problems. Cc: Johannes Berg <johannes.berg@intel.com> Cc: Andrei Otcheretianski <andrei.otcheretianski@intel.com> Cc: David S. Miller <davem@davemloft.net> Signed-off-by:
-
Greg Kroah-Hartman authored
-
Li Zefan authored
commit a903f086 upstream. Writing to this file always returns -ENODEV: # echo 1 > cpuset.memory_pressure_enabled -bash: echo: write error: No such device Signed-off-by:
Li Zefan <lizefan@huawei.com> Signed-off-by:
Tejun Heo <tj@kernel.org> Signed-off-by:
-
Jan Kara authored
commit 91aa11fa upstream. When jbd2_journal_dirty_metadata() returns error, __ext4_handle_dirty_metadata() stops the handle. However callers of this function do not count with that fact and still happily used now freed handle. This use after free can result in various issues but very likely we oops soon. The motivation of adding __ext4_journal_stop() into __ext4_handle_dirty_metadata() in commit 9ea7a0df seems to be only to improve error reporting. So replace __ext4_journal_stop() with ext4_journal_abort_handle() which was there before that commit and add WARN_ON_ONCE() to dump stack to provide useful information. Reported-by:
Sage Weil <sage@inktank.com> Signed-off-by:
Jan Kara <jack@suse.cz> Signed-off-by:
"Theodore Ts'o" <tytso@mit.edu> Signed-off-by:
-
Guenter Roeck authored
commit 215b28a5 upstream. Fix this build error: In file included from fs/exec.c:61:0: arch/s390/include/asm/tlb.h:35:23: error: expected identifier or '(' before 'unsigned' arch/s390/include/asm/tlb.h:36:1: warning: no semicolon at end of struct or union [enabled by default] arch/s390/include/asm/tlb.h: In function 'tlb_gather_mmu': arch/s390/include/asm/tlb.h:57:5: error: 'struct mmu_gather' has no member named 'end' Broken due to commit 2b047252 ("Fix TLB gather virtual address range invalidation corner cases"). Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
Guenter Roeck <linux@roeck-us.net> [ Oh well. We had build testing for ppc amd um, but no s390 - Linus ] Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Geert Uytterhoeven authored
commit e8184e10 upstream. As pointed out by Andreas Schwab, pointers passed to ARAnyM NatFeat calls should be physical addresses, not virtual addresses. Fortunately on Atari, physical and virtual kernel addresses are the same, as long as normal kernel memory is concerned, so this usually worked fine without conversion. But for modules, pointers to literal strings are located in vmalloc()ed memory. Depending on the version of ARAnyM, this causes the nf_get_id() call to just fail, or worse, crash ARAnyM itself with e.g. Gotcha! Illegal memory access. Atari PC = $968c This is a big issue for distro kernels, who want to have all drivers as loadable modules in an initrd. Add a wrapper for nf_get_id() that copies the literal to the stack to work around this issue. Reported-by:
Thorsten Glaser <tg@debian.org> Signed-off-by:
Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by:
-
Andreas Schwab authored
commit ea077b1b upstream. Explicitly truncate the second operand of do_div() to 32 bits to guard against bogus code calling it with a 64-bit divisor. [Thorsten] After upgrading from 3.2 to 3.10, mounting a btrfs volume fails with: btrfs: setting nodatacow, compression disabled btrfs: enabling auto recovery btrfs: disk space caching is enabled *** ZERO DIVIDE *** FORMAT=2 Current process id is 722 BAD KERNEL TRAP: 00000000 Modules linked in: evdev mac_hid ext4 crc16 jbd2 mbcache btrfs xor lzo_compress zlib_deflate raid6_pq crc32c libcrc32c PC: [<319535b2>] __btrfs_map_block+0x11c/0x119a [btrfs] SR: 2000 SP: 30c1fab4 a2: 30f0faf0 d0: 00000000 d1: 00001000 d2: 00000000 d3: 00000000 d4: 00010000 d5: 00000000 a0: 3085c72c a1: 3085c72c Process mount (pid: 722, task=30f0faf0) Frame format=2 instr addr=319535ae Stack from 30c1faec: 00000000 00000020 00000000 00001000 00000000 01401000 30253928 300ffc00 00a843ac 3026f640 00000000 00010000 0009e250 00d106c0 00011220 00000000 00001000 301c6830 0009e32a 000000ff 00000009 3085c72c 00000000 00000000 30c1fd14 00000000 00000020 00000000 30c1fd14 0009e26c 00000020 00000003 00000000 0009dd8a 300b0b6c 30253928 00a843ac 00001000 00000000 00000000 0000a008 3194e76a 30253928 00a843ac 00001000 00000000 00000000 00000002 Call Trace: [<00001000>] kernel_pg_dir+0x0/0x1000 [...] Code: 222e ff74 2a2e ff5c 2c2e ff60 4c45 1402 <2d40> ff64 2d41 ff68 2205 4c2e 1800 ff68 4c04 0800 2041 d1c0 2206 4c2e 1400 ff68 [Geert] As diagnosed by Andreas, fs/btrfs/volumes.c:__btrfs_map_block() calls do_div(stripe_nr, stripe_len); with stripe_len u64, while do_div() assumes the divisor is a 32-bit number. Due to the lack of truncation in the m68k-specific implementation of do_div(), the division is performed using the upper 32-bit word of stripe_len, which is zero. This was introduced by commit 53b381b3 ("Btrfs: RAID5 and RAID6"), which changed the divisor from map->stripe_len (struct map_lookup.stripe_len is int) to a 64-bit temporary. Reported-by:
Andreas Schwab <schwab@linux-m68k.org> Tested-by:
-
Will Deacon authored
commit c95eb318 upstream. It is possible to construct an event group with a software event as a group leader and then subsequently add a hardware event to the group. This results in the event group being validated by adding all members of the group to a fake PMU and attempting to allocate each event on their respective PMU. Unfortunately, for software events wthout a corresponding arm_pmu, this results in a kernel crash attempting to dereference the ->get_event_idx function pointer. This patch fixes the problem by checking explicitly for software events and ignoring those in event validation (since they can always be scheduled). We will probably want to revisit this for 3.12, since the validation checks don't appear to work correctly when dealing with multiple hardware PMUs anyway. Reported-by:
Vince Weaver <vincent.weaver@maine.edu> Tested-by:
Mark Rutland <mark.rutland@arm.com> Signed-off-by:
Will Deacon <will.deacon@arm.com> Signed-off-by:
Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by:
-
