- 19 Jun, 2015 7 commits
-
-
Ingo Molnar authored
Merge tag 'perf-urgent-for-mingo' of git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux into perf/urgent Pull perf/urgent fix from Arnaldo Carvalho de Melo: - Fix build breakage if prefix= is specified, this introduced a regression for a build idiom used by the Debian "linux-tools" package, that does: MAKE_PERF := $(MAKE) prefix=/usr V=1 ARCH=$(KERNEL_ARCH_PERF) ... Fix it. (Lukas Wunner) Signed-off-by:
Arnaldo Carvalho de Melo <acme@redhat.com> Signed-off-by:
Ingo Molnar <mingo@kernel.org>
-
Lukas Wunner authored
Invoking Makefile.perf with prefix= breaks the build since Makefile.perf hands that variable down to Makefile.build where it overrides prefix := $(subst ./,,$(OUTPUT)$(dir)/) leading to errors like this: No rule to make target '/usrabspath.o', needed by '/usrlibperf-in.o' Signed-off-by:
Lukas Wunner <lukas@wunner.de> Acked-by:
Jiri Olsa <jolsa@kernel.org> Cc: David Ahern <dsahern@gmail.com> Fixes: c819e2cf Link: http://lkml.kernel.org/r/5582c48a.84a22b0a.a918.5285SMTPIN_ADDED_MISSING@mx.google.comSigned-off-by:
Arnaldo Carvalho de Melo <acme@redhat.com>
-
Palik, Imre authored
Architectural performance monitoring, version 1, doesn't support fixed counters. Currently, even if a hypervisor advertises support for architectural performance monitoring version 1, perf may still try to use the fixed counters, as the constraints are set up based on the CPU model. This patch ensures that perf honors the architectural performance monitoring version returned by CPUID, and it only uses the fixed counters for version 2 and above. (Some of the ideas in this patch came from Peter Zijlstra.) Signed-off-by:
Imre Palik <imrep@amazon.de> Signed-off-by:
Peter Zijlstra (Intel) <peterz@infradead.org> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Andy Lutomirski <luto@amacapital.net> Cc: Anthony Liguori <aliguori@amazon.com> Cc: Arnaldo Carvalho de Melo <acme@kernel.org> Cc: Borislav Petkov <bp@alien8.de> Cc: Brian Gerst <brgerst@gmail.com> Cc: Denys Vlasenko <dvlasenk@redhat.com> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Oleg Nesterov <oleg@redhat.com> Cc: Paul Mackerras <paulus@samba.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Link: http://lkml.kernel.org/r/1433767609-1039-1-git-send-email-imrep.amz@gmail.comSigned-off-by:
Ingo Molnar <mingo@kernel.org>
-
Alexander Shishkin authored
Intel PT is a separate PMU and it is not using any of the x86_pmu code paths, which means in particular that the active_events counter remains intact when new PT events are created. However, PT uses the generic x86_pmu PMI handler for its PMI handling needs. The problem here is that the latter checks active_events and in case of it being zero, exits without calling the actual x86_pmu.handle_nmi(), which results in unknown NMI errors and massive data loss for PT. The effect is not visible if there are other perf events in the system at the same time that keep active_events counter non-zero, for instance if the NMI watchdog is running, so one needs to disable it to reproduce the problem. At the same time, the active_events counter besides doing what the name suggests also implicitly serves as a PMC hardware and DS area reference counter. This patch adds a separate reference counter for the PMC hardware, leaving active_events for actually counting the events and makes sure it also counts PT and BTS events. Signed-off-by:
Alexander Shishkin <alexander.shishkin@linux.intel.com> Signed-off-by:
Peter Zijlstra (Intel) <peterz@infradead.org> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Andy Lutomirski <luto@amacapital.net> Cc: Borislav Petkov <bp@alien8.de> Cc: Brian Gerst <brgerst@gmail.com> Cc: Denys Vlasenko <dvlasenk@redhat.com> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Oleg Nesterov <oleg@redhat.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: acme@infradead.org Cc: adrian.hunter@intel.com Link: http://lkml.kernel.org/r/87k2v92t0s.fsf@ashishki-desk.ger.corp.intel.comSigned-off-by:
Ingo Molnar <mingo@kernel.org>
-
Alexander Shishkin authored
Currently, the intel_bts driver relies on the DS area allocated by the x86_pmu code in its event_init() path, which is a bug: creating a BTS event while no x86_pmu events are present results in a NULL pointer dereference. The same DS area is also used by PEBS sampling, which makes it quite a bit trickier to have a separate one for intel_bts' purposes. This patch makes intel_bts driver use the same DS allocation and reference counting code as x86_pmu to make sure it is always present when either intel_bts or x86_pmu need it. Signed-off-by:
Alexander Shishkin <alexander.shishkin@linux.intel.com> Signed-off-by:
Peter Zijlstra (Intel) <peterz@infradead.org> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Andy Lutomirski <luto@amacapital.net> Cc: Borislav Petkov <bp@alien8.de> Cc: Brian Gerst <brgerst@gmail.com> Cc: Denys Vlasenko <dvlasenk@redhat.com> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Oleg Nesterov <oleg@redhat.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: acme@infradead.org Cc: adrian.hunter@intel.com Link: http://lkml.kernel.org/r/1434024837-9916-2-git-send-email-alexander.shishkin@linux.intel.comSigned-off-by:
Ingo Molnar <mingo@kernel.org>
-
Andi Kleen authored
This patch adds additional model numbers for Broadwell to perf. Support for Broadwell with Iris Pro (Intel Core i7-57xxC) and support for Broadwell Server Xeon. Signed-off-by:
Andi Kleen <ak@linux.intel.com> Signed-off-by:
Peter Zijlstra (Intel) <peterz@infradead.org> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Andy Lutomirski <luto@amacapital.net> Cc: Borislav Petkov <bp@alien8.de> Cc: Brian Gerst <brgerst@gmail.com> Cc: Denys Vlasenko <dvlasenk@redhat.com> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Oleg Nesterov <oleg@redhat.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Link: http://lkml.kernel.org/r/1434055942-28253-1-git-send-email-andi@firstfloor.orgSigned-off-by:
Ingo Molnar <mingo@kernel.org>
-
Oleg Nesterov authored
While looking for other users of get_state/cond_sync. I Found ring_buffer_attach() and it looks obviously buggy? Don't we need to ensure that we have "synchronize" _between_ list_del() and list_add() ? IOW. Suppose that ring_buffer_attach() preempts right_after get_state_synchronize_rcu() and gp completes before spin_lock(). In this case cond_synchronize_rcu() does nothing and we reuse ->rb_entry without waiting for gp in between? It also moves the ->rcu_pending check under "if (rb)", to make it more readable imo. Signed-off-by:
Oleg Nesterov <oleg@redhat.com> Signed-off-by:
Peter Zijlstra (Intel) <peterz@infradead.org> Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Andy Lutomirski <luto@amacapital.net> Cc: Borislav Petkov <bp@alien8.de> Cc: Brian Gerst <brgerst@gmail.com> Cc: Denys Vlasenko <dvlasenk@redhat.com> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: dave@stgolabs.net Cc: der.herr@hofr.at Cc: josh@joshtriplett.org Cc: tj@kernel.org Fixes: b69cf536 ("perf: Fix a race between ring_buffer_detach() and ring_buffer_attach()") Link: http://lkml.kernel.org/r/20150530200425.GA15748@redhat.comSigned-off-by:
Ingo Molnar <mingo@kernel.org>
-
- 18 Jun, 2015 5 commits
-
-
Linus Torvalds authored
Merge tag 'trace-fix-filter-4.1-rc8' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace Pull tracing filter fix from Steven Rostedt: "Vince Weaver reported a warning when he added perf event filters into his fuzzer tests. There's a missing check of balanced operations when parenthesis are used, and this triggers a WARN_ON() and when reading the failure, the filter reports no failure occurred. The operands were not being checked if they match, this adds that" * tag 'trace-fix-filter-4.1-rc8' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace: tracing: Have filter check for balanced ops
-
git://git.kernel.org/pub/scm/virt/kvm/kvmLinus Torvalds authored
Pull kvm bugfix from Marcelo Tosatti: "Rrestore APIC migration functionality" * git://git.kernel.org/pub/scm/virt/kvm/kvm: KVM: x86: fix lapic.timer_mode on restore
-
Mauro Carvalho Chehab authored
Since when we start discussions about the usage Media Controller for complex hardware, one thing become clear: the way it is, MC fails to map anything different than capture/output/m2m video-only streaming. The point is that MC has entities named as devnodes, but the only devnode used (before the DVB patches) is MEDIA_ENT_T_DEVNODE_V4L. Due to the way MC got implemented, however, this entity actually doesn't represent the devnode, but the hardware I/O engine that receives data via DMA. By coincidence, such DMA is associated with the V4L device node on webcam hardware, but this is not true even for other V4L2 devices. For example, on USB hardware, the DMA is done via the USB controller. The data passes though a in-kernel filter that strips off the URB headers. Other V4L2 devices like radio may not even have DMA. When it have, the DMA is done via ALSA, and not via the V4L devnode. In other words, MC is broken as a whole, but tagging it as BROKEN right now would do more harm than good. So, instead, let's mark, for now, the DVB part as broken and block all new changes to MC while we fix this mess, whith we hopefully will do for the next Kernel version. Requested-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by:
Hans Verkuil <hans.verkuil@cisco.com> Acked-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by:
Mauro Carvalho Chehab <mchehab@osg.samsung.com> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6Linus Torvalds authored
Pull crypto fixes from Herbert Xu: "This fixes the following issues: - Crash in caam hash due to uninitialised buffer lengths. - Alignment issue in caam RNG that may lead to non-random output" * git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6: crypto: caam - fix RNG buffer cache alignment crypto: caam - improve initalization for context state saves
-
Hugh Dickins authored
It appears that, at some point last year, XFS made directory handling changes which bring it into lockdep conflict with shmem_zero_setup(): it is surprising that mmap() can clone an inode while holding mmap_sem, but that has been so for many years. Since those few lockdep traces that I've seen all implicated selinux, I'm hoping that we can use the __shmem_file_setup(,,,S_PRIVATE) which v3.13's commit c7277090 ("security: shmem: implement kernel private shmem inodes") introduced to avoid LSM checks on kernel-internal inodes: the mmap("/dev/zero") cloned inode is indeed a kernel-internal detail. This also covers the !CONFIG_SHMEM use of ramfs to support /dev/zero (and MAP_SHARED|MAP_ANONYMOUS). I thought there were also drivers which cloned inode in mmap(), but if so, I cannot locate them now. Reported-and-tested-by:
Prarit Bhargava <prarit@redhat.com> Reported-and-tested-by:
Daniel Wagner <wagi@monom.org> Reported-and-tested-by:
Morten Stevens <mstevens@fedoraproject.org> Signed-off-by:
Hugh Dickins <hughd@google.com> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
- 17 Jun, 2015 1 commit
-
-
Steven Rostedt authored
When the following filter is used it causes a warning to trigger: # cd /sys/kernel/debug/tracing # echo "((dev==1)blocks==2)" > events/ext4/ext4_truncate_exit/filter -bash: echo: write error: Invalid argument # cat events/ext4/ext4_truncate_exit/filter ((dev==1)blocks==2) ^ parse_error: No error ------------[ cut here ]------------ WARNING: CPU: 2 PID: 1223 at kernel/trace/trace_events_filter.c:1640 replace_preds+0x3c5/0x990() Modules linked in: bnep lockd grace bluetooth ... CPU: 3 PID: 1223 Comm: bash Tainted: G W 4.1.0-rc3-test+ #450 Hardware name: Hewlett-Packard HP Compaq Pro 6300 SFF/339A, BIOS K01 v02.05 05/07/2012 0000000000000668 ffff8800c106bc98 ffffffff816ed4f9 ffff88011ead0cf0 0000000000000000 ffff8800c106bcd8 ffffffff8107fb07 ffffffff8136b46c ffff8800c7d81d48 ffff8800d4c2bc00 ffff8800d4d4f920 00000000ffffffea Call Trace: [<ffffffff816ed4f9>] dump_stack+0x4c/0x6e [<ffffffff8107fb07>] warn_slowpath_common+0x97/0xe0 [<ffffffff8136b46c>] ? _kstrtoull+0x2c/0x80 [<ffffffff8107fb6a>] warn_slowpath_null+0x1a/0x20 [<ffffffff81159065>] replace_preds+0x3c5/0x990 [<ffffffff811596b2>] create_filter+0x82/0xb0 [<ffffffff81159944>] apply_event_filter+0xd4/0x180 [<ffffffff81152bbf>] event_filter_write+0x8f/0x120 [<ffffffff811db2a8>] __vfs_write+0x28/0xe0 [<ffffffff811dda43>] ? __sb_start_write+0x53/0xf0 [<ffffffff812e51e0>] ? security_file_permission+0x30/0xc0 [<ffffffff811dc408>] vfs_write+0xb8/0x1b0 [<ffffffff811dc72f>] SyS_write+0x4f/0xb0 [<ffffffff816f5217>] system_call_fastpath+0x12/0x6a ---[ end trace e11028bd95818dcd ]--- Worse yet, reading the error message (the filter again) it says that there was no error, when there clearly was. The issue is that the code that checks the input does not check for balanced ops. That is, having an op between a closed parenthesis and the next token. This would only cause a warning, and fail out before doing any real harm, but it should still not caues a warning, and the error reported should work: # cd /sys/kernel/debug/tracing # echo "((dev==1)blocks==2)" > events/ext4/ext4_truncate_exit/filter -bash: echo: write error: Invalid argument # cat events/ext4/ext4_truncate_exit/filter ((dev==1)blocks==2) ^ parse_error: Meaningless filter expression And give no kernel warning. Link: http://lkml.kernel.org/r/20150615175025.7e809215@gandalf.local.home Cc: Peter Zijlstra <a.p.zijlstra@chello.nl> Cc: Ingo Molnar <mingo@redhat.com> Cc: Arnaldo Carvalho de Melo <acme@kernel.org> Cc: stable@vger.kernel.org # 2.6.31+ Reported-by:
Vince Weaver <vincent.weaver@maine.edu> Tested-by:
Vince Weaver <vincent.weaver@maine.edu> Signed-off-by:
Steven Rostedt <rostedt@goodmis.org>
-
- 16 Jun, 2015 3 commits
-
-
Steve Cornelius authored
The hwrng output buffers (2) are cast inside of a a struct (caam_rng_ctx) allocated in one DMA-tagged region. While the kernel's heap allocator should place the overall struct on a cacheline aligned boundary, the 2 buffers contained within may not necessarily align. Consenquently, the ends of unaligned buffers may not fully flush, and if so, stale data will be left behind, resulting in small repeating patterns. This fix aligns the buffers inside the struct. Note that not all of the data inside caam_rng_ctx necessarily needs to be DMA-tagged, only the buffers themselves require this. However, a fix would incur the expense of error-handling bloat in the case of allocation failure. Cc: stable@vger.kernel.org Signed-off-by:
Steve Cornelius <steve.cornelius@freescale.com> Signed-off-by:
Victoria Milhoan <vicki.milhoan@freescale.com> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au>
-
Steve Cornelius authored
Multiple function in asynchronous hashing use a saved-state block, a.k.a. struct caam_hash_state, which holds a stash of information between requests (init/update/final). Certain values in this state block are loaded for processing using an inline-if, and when this is done, the potential for uninitialized data can pose conflicts. Therefore, this patch improves initialization of state data to prevent false assignments using uninitialized data in the state block. This patch addresses the following traceback, originating in ahash_final_ctx(), although a problem like this could certainly exhibit other symptoms: kernel BUG at arch/arm/mm/dma-mapping.c:465! Unable to handle kernel NULL pointer dereference at virtual address 00000000 pgd = 80004000 [00000000] *pgd=00000000 Internal error: Oops: 805 [#1] PREEMPT SMP Modules linked in: CPU: 0 Not tainted (3.0.15-01752-gdd441b9-dirty #40) PC is at __bug+0x1c/0x28 LR is at __bug+0x18/0x28 pc : [<80043240>] lr : [<8004323c>] psr: 60000013 sp : e423fd98 ip : 60000013 fp : 0000001c r10: e4191b84 r9 : 00000020 r8 : 00000009 r7 : 88005038 r6 : 00000001 r5 : 2d676572 r4 : e4191a60 r3 : 00000000 r2 : 00000001 r1 : 60000093 r0 : 00000033 Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment kernel Control: 10c53c7d Table: 1000404a DAC: 00000015 Process cryptomgr_test (pid: 1306, stack limit = 0xe423e2f0) Stack: (0xe423fd98 to 0xe4240000) fd80: 11807fd1 80048544 fda0: 88005000 e4191a00 e5178040 8039dda0 00000000 00000014 2d676572 e4191008 fdc0: 88005018 e4191a60 00100100 e4191a00 00000000 8039ce0c e423fea8 00000007 fde0: e4191a00 e4227000 e5178000 8039ce18 e419183c 80203808 80a94a44 00000006 fe00: 00000000 80207180 00000000 00000006 e423ff08 00000000 00000007 e5178000 fe20: e41918a4 80a949b4 8c4844e2 00000000 00000049 74227000 8c4844e2 00000e90 fe40: 0000000e 74227e90 ffff8c58 80ac29e0 e423fed4 8006a350 8c81625c e423ff5c fe60: 00008576 e4002500 00000003 00030010 e4002500 00000003 e5180000 e4002500 fe80: e5178000 800e6d24 007fffff 00000000 00000010 e4001280 e4002500 60000013 fea0: 000000d0 804df078 00000000 00000000 00000000 00000000 00000000 00000000 fec0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 fee0: 00000000 00000000 e4227000 e4226000 e4753000 e4752000 e40a5000 e40a4000 ff00: e41e7000 e41e6000 00000000 00000000 00000000 e423ff14 e423ff14 00000000 ff20: 00000400 804f9080 e5178000 e4db0b40 00000000 e4db0b80 0000047c 00000400 ff40: 00000000 8020758c 00000400 ffffffff 0000008a 00000000 e4db0b40 80206e00 ff60: e4049dbc 00000000 00000000 00000003 e423ffa4 80062978 e41a8bfc 00000000 ff80: 00000000 e4049db4 00000013 e4049db0 00000013 00000000 00000000 00000000 ffa0: e4db0b40 e4db0b40 80204cbc 00000013 00000000 00000000 00000000 80204cfc ffc0: e4049da0 80089544 80040a40 00000000 e4db0b40 00000000 00000000 00000000 ffe0: e423ffe0 e423ffe0 e4049da0 800894c4 80040a40 80040a40 00000000 00000000 [<80043240>] (__bug+0x1c/0x28) from [<80048544>] (___dma_single_dev_to_cpu+0x84) [<80048544>] (___dma_single_dev_to_cpu+0x84/0x94) from [<8039dda0>] (ahash_fina) [<8039dda0>] (ahash_final_ctx+0x180/0x428) from [<8039ce18>] (ahash_final+0xc/0) [<8039ce18>] (ahash_final+0xc/0x10) from [<80203808>] (crypto_ahash_op+0x28/0xc) [<80203808>] (crypto_ahash_op+0x28/0xc0) from [<80207180>] (test_hash+0x214/0x5) [<80207180>] (test_hash+0x214/0x5b8) from [<8020758c>] (alg_test_hash+0x68/0x8c) [<8020758c>] (alg_test_hash+0x68/0x8c) from [<80206e00>] (alg_test+0x7c/0x1b8) [<80206e00>] (alg_test+0x7c/0x1b8) from [<80204cfc>] (cryptomgr_test+0x40/0x48) [<80204cfc>] (cryptomgr_test+0x40/0x48) from [<80089544>] (kthread+0x80/0x88) [<80089544>] (kthread+0x80/0x88) from [<80040a40>] (kernel_thread_exit+0x0/0x8) Code: e59f0010 e1a01003 eb126a8d e3a03000 (e5833000) ---[ end trace d52a403a1d1eaa86 ]--- Cc: stable@vger.kernel.org Signed-off-by:
Steve Cornelius <steve.cornelius@freescale.com> Signed-off-by:
Victoria Milhoan <vicki.milhoan@freescale.com> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au>
-
Radim Krčmář authored
lapic.timer_mode was not properly initialized after migration, which broke few useful things, like login, by making every sleep eternal. Fix this by calling apic_update_lvtt in kvm_apic_post_state_restore. There are other slowpaths that update lvtt, so this patch makes sure something similar doesn't happen again by calling apic_update_lvtt after every modification. Cc: stable@vger.kernel.org Fixes: f30ebc31 ("KVM: x86: optimize some accesses to LVTT and SPIV") Signed-off-by:
Radim Krčmář <rkrcmar@redhat.com> Signed-off-by:
Marcelo Tosatti <mtosatti@redhat.com>
-
- 15 Jun, 2015 7 commits
-
-
Linus Torvalds authored
-
git://git.infradead.org/users/vkoul/slave-dmaLinus Torvalds authored
Pull dmaengine fixes from Vinod Koul: "Here are hopefully last set of fixes for 4.1. This time we have: - fixing pause capability reporting on both dmaengine pause & resume support by Krzysztof - locking fix fir at_xdmac by Ludovic - slave configuration fix for at_xdmac by Ludovic" * 'fixes' of git://git.infradead.org/users/vkoul/slave-dma: dmaengine: Fix choppy sound because of unimplemented resume dmaengine: at_xdmac: rework slave configuration part dmaengine: at_xdmac: lock fixes
-
git://github.com/jonmason/ntbLinus Torvalds authored
Pull NTB fixes from Jon Mason: "I apologize for the tardiness of this request. Here are a couple of last minute NTB bug fixes for v4.1: NTB bug fixes to address issues in unmapping the MW reg base and vbase, and an uninitialized variable on Atom platforms" * tag 'ntb-4.1' of git://github.com/jonmason/ntb: ntb: initialize max_mw for Atom before using it ntb: iounmap MW reg and vbase in error path
-
git://git.linux-mips.org/pub/scm/ralf/upstream-linusLinus Torvalds authored
Pull more MIPS fixes from Ralf Baechle: "Another round of 4.1 MIPS fixes, one fix to a MIPS-specific #if condition in lib/mpi, one fix to the MIPS GIC irqchip driver and one SSB fix. Details: - fix handling of clock in chipco SSB driver. - fix two MIPS-specific #if conditions to correctly work for GCC 5.1. - fix damage to R6 pgtable bits done by XPA support. - fix possible crash due to unloading modules that contain statically defined platform devices. - fix disabling of the MSA ASE on context switch to also work correctly when a new thread/process has the CPU for the very first time. This is part of linux-next and has been beaten to death on Imagination's test farm. While things are not looking too grim this pull request also means the rate of fixes for 4.1 remains nearly constant so I'd not be unhappy if you'd delay the release" * 'upstream' of git://git.linux-mips.org/pub/scm/ralf/upstream-linus: MPI: MIPS: Fix compilation error with GCC 5.1 IRQCHIP: mips-gic: Don't nest calls to do_IRQ() MIPS: MSA: bugfix - disable MSA correctly for new threads/processes. MIPS: Loongson: Do not register 8250 platform device from module. MIPS: Cobalt: Do not build MTD platform device registration code as module. SSB: Fix handling of ssb_pmu_get_alp_clock() MIPS: pgtable-bits: Fix XPA damage to R6 definitions.
-
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tipLinus Torvalds authored
Pull irqchip fix from Thomas Gleixner: "A single fix for an off by one bug in the sunxi irqchip driver" * 'irq-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: irqchip: sunxi-nmi: Fix off-by-one error in irq iterator
-
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tipLinus Torvalds authored
Pull lockdep fix from Ingo Molnar: "A lockdep/modules unload race fix that can oops" * 'locking-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: lockdep: Fix a race between /proc/lock_stat and module unload
-
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tipLinus Torvalds authored
Pull perf fixes from Ingo Molnar: "A regression fix for a crash, and a Intel HSW uncore PMU driver fix" * 'perf-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: Revert "perf/x86/intel/uncore: Move uncore_box_init() out of driver initialization" perf/x86/intel/uncore: Fix CBOX bit wide and UBOX reg on Haswell-EP
-
- 14 Jun, 2015 1 commit
-
-
git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/soundLinus Torvalds authored
Pull sound fixes from Takashi Iwai: "Most of commits are regression fixes for HD-audio: a few corner case fixes for regmap transition, and i915 binding issues. In addition, a quirk for another USB-audio device supporting DSD" * tag 'sound-4.1-rc8' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound: ALSA: hda - Abort the probe without i915 binding for HSW/BDW ALSA: hda - Re-add the lost fake mute support ALSA: hda - Continue probing even if i915 binding fails ALSA: hda - Don't actually write registers for caps overwrites ALSA: hda - fix number of devices query on hotplug ALSA: usb-audio: add native DSD support for JLsounds I2SoverUSB
-
- 13 Jun, 2015 3 commits
-
-
Jaedon Shin authored
This patch fixes mips compilation error: lib/mpi/generic_mpih-mul1.c: In function 'mpihelp_mul_1': lib/mpi/longlong.h:651:2: error: impossible constraint in 'asm' Signed-off-by:
Jaedon Shin <jaedon.shin@gmail.com> Cc: Linux-MIPS <linux-mips@linux-mips.org> Patchwork: https://patchwork.linux-mips.org/patch/10546/Signed-off-by:
Ralf Baechle <ralf@linux-mips.org>
-
Rabin Vincent authored
The GIC chained handlers use do_IRQ() to call the subhandlers. This means that irq_enter() calls get nested, which leads to preempt count looking like we're in nested interrupts, which in turn leads to all system time being accounted as IRQ time in account_system_time(). Fix it by using generic_handle_irq(). Since these same functions are used in some systems (if cpu_has_veic) from a low-level vectored interrupt handler which does not go throught do_IRQ(), we need to do it conditionally. Signed-off-by:
Rabin Vincent <rabin.vincent@axis.com> Reviewed-by:
Andrew Bresticker <abrestic@chromium.org> Acked-by:
Thomas Gleixner <tglx@linutronix.de> Cc: linux-mips@linux-mips.org Cc: tglx@linutronix.de Cc: jason@lakedaemon.net Patchwork: https://patchwork.linux-mips.org/patch/10545/Signed-off-by:
Ralf Baechle <ralf@linux-mips.org>
-
git://git.kernel.org/pub/scm/linux/kernel/git/davem/netLinus Torvalds authored
Pull networking fixes from David Miller: 1) Fix uninitialized struct station_info in cfg80211_wireless_stats(), from Johannes Berg. 2) Revert commit attempt to fix ipv6 protocol resubmission, it adds regressions. 3) Endless loops can be created in bridge port lists, fix from Nikolay Aleksandrov. 4) Don't WARN_ON() if sk->sk_forward_alloc is non-zero in sk_clear_memalloc, it is a legal situation during swap deactivation. Fix from Mel Gorman. 5) Fix order of disabling interrupts and unlocking NAPI in enic driver to avoid a race. From Govindarajulu Varadarajan. 6) High and low register writes are swapped when programming the start of periodic output in igb driver. From Richard Cochran. 7) Fix device rename handling in mpls stack, from Robert Shearman. 8) Do not trigger compaction synchronously when optimistically trying to allocate an order 3 page in alloc_skb_with_frags() and skb_page_frag_refill(). From Shaohua Li. 9) Authentication with COOKIE_ECHO is not handled properly in SCTP, fix from Marcelo Ricardo Leitner. * git://git.kernel.org/pub/scm/linux/kernel/git/davem/net: Doc: networking: Fix URL for wiki.wireshark.org in udplite.txt sctp: allow authenticating DATA chunks that are bundled with COOKIE_ECHO net: don't wait for order-3 page allocation mpls: handle device renames for per-device sysctls net: igb: fix the start time for periodic output signals enic: fix memory leak in rq_clean enic: check return value for stat dump enic: unlock napi busy poll before unmasking intr net, swap: Remove a warning and clarify why sk_mem_reclaim is required when deactivating swap bridge: fix multicast router rlist endless loop tipc: disconnect socket directly after probe failure Revert "ipv6: Fix protocol resubmission" cfg80211: wext: clear sinfo struct before calling driver
-
- 12 Jun, 2015 13 commits
-
-
Masanari Iida authored
This patch fix URL (http to https) for wiki.wireshark.org. Signed-off-by:
Masanari Iida <standby24x7@gmail.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Marcelo Ricardo Leitner authored
Currently, we can ask to authenticate DATA chunks and we can send DATA chunks on the same packet as COOKIE_ECHO, but if you try to combine both, the DATA chunk will be sent unauthenticated and peer won't accept it, leading to a communication failure. This happens because even though the data was queued after it was requested to authenticate DATA chunks, it was also queued before we could know that remote peer can handle authenticating, so sctp_auth_send_cid() returns false. The fix is whenever we set up an active key, re-check send queue for chunks that now should be authenticated. As a result, such packet will now contain COOKIE_ECHO + AUTH + DATA chunks, in that order. Reported-by:
Liu Wei <weliu@redhat.com> Signed-off-by:
Marcelo Ricardo Leitner <marcelo.leitner@gmail.com> Acked-by:
Neil Horman <nhorman@tuxdriver.com> Acked-by:
Vlad Yasevich <vyasevich@gmail.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
git://git.kernel.dk/linux-blockLinus Torvalds authored
Pull block layer fixes from Jens Axboe: "Remember about a week ago when I sent the last pull request for 4.1? Well, I lied. Now, I don't want to shift the blame, but Dan, Ming, and Richard made a liar out of me. Here are three small patches that should go into 4.1. More specifically, this pull request contains: - A Kconfig dependency for the pmem block driver, so it can't be selected if HAS_IOMEM isn't availble. From Richard Weinberger. - A fix for genhd, making the ext_devt_lock softirq safe. This makes lockdep happier, since we also end up grabbing this lock on release off the softirq path. From Dan Williams. - A blk-mq software queue release fix from Ming Lei. Last two are headed to stable, first fixes an issue introduced in this cycle" * 'for-linus' of git://git.kernel.dk/linux-block: block: pmem: Add dependency on HAS_IOMEM block: fix ext_dev_lock lockdep report blk-mq: free hctx->ctxs in queue's release handler
-
git://neil.brown.name/mdLinus Torvalds authored
Pull three more md fixes from Neil Brown: "Hasn't been a good cycle for md has it :-( The main issue fixed here is a rare race which can result in two reshape threads running at once, which doesn't end well. Also a minor issue with a write to a sysfs file returning the wrong value. Backports to 4.0-stable are indicated" * tag 'md/4.1-rc7-fixes' of git://neil.brown.name/md: md: make sure MD_RECOVERY_DONE is clear before starting recovery/resync md: Close race when setting 'action' to 'idle'. md: don't return 0 from array_state_store
-
git://git.infradead.org/intel-iommuLinus Torvalds authored
Pull VT-d hardware workarounds from David Woodhouse: "This contains a workaround for hardware issues which I *thought* were never going to be seen on production hardware. I'm glad I checked that before the 4.1 release... Firstly, PASID support is so broken on existing chips that we're just going to declare the old capability bit 28 as 'reserved' and change the VT-d spec to move PASID support to another bit. So any existing hardware doesn't support SVM; it only sets that (now) meaningless bit 28. That patch *wasn't* imperative for 4.1 because we don't have PASID support yet. But *even* the extended context tables are broken — if you just enable the wider tables and use none of the new bits in them, which is precisely what 4.1 does, you find that translations don't work. It's this problem which I thought was caught in time to be fixed before production, but wasn't. To avoid triggering this issue, we now *only* enable the extended context tables on hardware which also advertises "we have PASID support and we actually tested it this time" with the new PASID feature bit. In addition, I've added an 'intel_iommu=ecs_off' command line parameter to allow us to disable it manually if we need to" * git://git.infradead.org/intel-iommu: iommu/vt-d: Only enable extended context tables if PASID is supported iommu/vt-d: Change PASID support to bit 40 of Extended Capability Register
-
David Woodhouse authored
Although the extended tables are theoretically a completely orthogonal feature to PASID and anything else that *uses* the newly-available bits, some of the early hardware has problems even when all we do is enable them and use only the same bits that were in the old context tables. For now, there's no motivation to support extended tables unless we're going to use PASID support to do SVM. So just don't use them unless PASID support is advertised too. Also add a command-line bailout just in case later chips also have issues. The equivalent problem for PASID support has already been fixed with the upcoming VT-d spec update and commit bd00c606 ("iommu/vt-d: Change PASID support to bit 40 of Extended Capability Register"), because the problematic platforms use the old definition of the PASID-capable bit, which is now marked as reserved and meaningless. So with this change, we'll magically start using ECS again only when we see the new hardware advertising "hey, we have PASID support and we actually tested it this time" on bit 40. The VT-d hardware architect has promised that we are not going to have any reason to support ECS *without* PASID any time soon, and he'll make sure he checks with us before changing that. In the future, if hypothetical new features also use new bits in the context tables and can be seen on implementations *without* PASID support, we might need to add their feature bits to the ecs_enabled() macro. Signed-off-by:
David Woodhouse <David.Woodhouse@intel.com>
-
NeilBrown authored
MD_RECOVERY_DONE is normally cleared by md_check_recovery after a resync etc finished. However it is possible for raid5_start_reshape to race and start a reshape before MD_RECOVERY_DONE is cleared. This can lean to multiple reshapes running at the same time, which isn't good. To make sure it is cleared before starting a reshape, and also clear it when reaping a thread, just to be safe. Signed-off-by:
NeilBrown <neilb@suse.de>
-
NeilBrown authored
Checking ->sync_thread without holding the mddev_lock() isn't really safe, even after flushing the workqueue which ensures md_start_sync() has been run. While this code is waiting for the lock, md_check_recovery could reap the thread itself, and then start another thread (e.g. recovery might finish, then reshape starts). When this thread gets the lock md_start_sync() hasn't run so it doesn't get reaped, but MD_RECOVERY_RUNNING gets cleared. This allows two threads to start which leads to confusion. So don't both if MD_RECOVERY_RUNNING isn't set, but if it is do the flush and the test and the reap all under the mddev_lock to avoid any race with md_check_recovery. Signed-off-by:
NeilBrown <neilb@suse.de> Fixes: 6791875e ("md: make reconfig_mutex optional for writes to md sysfs files.") Cc: stable@vger.kernel.org (v4.0+)
-
NeilBrown authored
Returning zero from a 'store' function is bad. The return value should be either len length of the string or an error. So use 'len' if 'err' is zero. Fixes: 6791875e ("md: make reconfig_mutex optional for writes to md sysfs files.") Signed-off-by:
NeilBrown <neilb@suse.de> Cc: stable@vger.kernel (v4.0+)
-
Krzysztof Kozlowski authored
Some drivers implement only pause operation (no resuming). Example is pl330 where pause is needed for getting residuum. pl330 does not support resume operation, transfer must be stopped after pause. However for slaves this is exposed always as "pause and resume" which introduces subtle errors on Odroid U3 board (Exynos4412 with pl330). After adding pause function to pl330 driver the audio playback (utilizing DMA) gets choppy after some time (approximately 24 hours). Fix this by exposing "cmd_pause" if and only if pause and resume are implemented. Signed-off-by:
Krzysztof Kozlowski <k.kozlowski@samsung.com> Reported-by: gabriel@unseen.is Reported-by:
Marek Szyprowski <m.szyprowski@samsung.com> Cc: <stable@vger.kernel.org> Fixes: 88987d2c ("dmaengine: pl330: add DMA_PAUSE feature") Acked-by:
Maxime Ripard <maxime.ripard@free-electrons.com> Signed-off-by:
Vinod Koul <vinod.koul@intel.com>
-
Takashi Iwai authored
The previous patch tried to continue the probe if i915 binding fails. For for simplicity reason, we haven't implemented abort even for controller chips that are dedicated for HDMI/DP on HSW and BDW. However, Mengdong suggested that this can be dangerous; BIOS may disable gfx power well although the PCI entry for HD-audio is left, and this may result in the unexpected behavior, kernel errors, etc. For avoiding this situation, abort the probe at i915 binding failure only for HSW/BDW chips selectively. For other chips, it still continues. Fixes: bf06848b ('ALSA: hda - Continue probing even if i915 binding fails') Reported-by:
Mengdong Lin <mengdong.lin@intel.com> Signed-off-by:
Takashi Iwai <tiwai@suse.de>
-
git://people.freedesktop.org/~airlied/linuxLinus Torvalds authored
Pull drm fixes from Dave Airlie: "i915 and radeon fixes: i915: fix for connector oops regression DDC probing fix radeon: two radeon reverts, along with a freeze workaround and a fix" * 'drm-fixes' of git://people.freedesktop.org/~airlied/linux: drm/radeon: Make sure radeon_vm_bo_set_addr always unreserves the BO Revert "drm/radeon: adjust pll when audio is not enabled" Revert "drm/radeon: don't share plls if monitors differ in audio support" drm/radeon: fix freeze for laptop with Turks/Thames GPU. drm/i915: Fix DDC probe for passive adapters drm/i915: Properly initialize SDVO analog connectors
-
Shaohua Li authored
We saw excessive direct memory compaction triggered by skb_page_frag_refill. This causes performance issues and add latency. Commit 5640f768 introduces the order-3 allocation. According to the changelog, the order-3 allocation isn't a must-have but to improve performance. But direct memory compaction has high overhead. The benefit of order-3 allocation can't compensate the overhead of direct memory compaction. This patch makes the order-3 page allocation atomic. If there is no memory pressure and memory isn't fragmented, the alloction will still success, so we don't sacrifice the order-3 benefit here. If the atomic allocation fails, direct memory compaction will not be triggered, skb_page_frag_refill will fallback to order-0 immediately, hence the direct memory compaction overhead is avoided. In the allocation failure case, kswapd is waken up and doing compaction, so chances are allocation could success next time. alloc_skb_with_frags is the same. The mellanox driver does similar thing, if this is accepted, we must fix the driver too. V3: fix the same issue in alloc_skb_with_frags as pointed out by Eric V2: make the changelog clearer Cc: Eric Dumazet <edumazet@google.com> Cc: Chris Mason <clm@fb.com> Cc: Debabrata Banerjee <dbavatar@gmail.com> Signed-off-by:
Shaohua Li <shli@fb.com> Acked-by:
Eric Dumazet <edumazet@google.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-