- 01 Mar, 2014 1 commit
-
-
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 build fixes for certain distro environments, from Arnaldo Carvalho de Melo: * Problem on recent gcc on x86-32 related to strict alias issue for find_first_bit (Jiri Olsa). * OpenSuSE: BFD detection problems related to not explicitely listing all required libraries (Andi Kleen) Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com> Signed-off-by: Ingo Molnar <mingo@kernel.org>
-
- 28 Feb, 2014 1 commit
-
-
Jiri Olsa authored
When compiling perf tool code with gcc 4.4.7 I'm getting following error: CC util/session.o cc1: warnings being treated as errors util/session.c: In function ‘perf_session_deliver_event’: tools/perf/util/include/linux/bitops.h:109: error: dereferencing pointer ‘p’ does break strict-aliasing rules tools/perf/util/include/linux/bitops.h:101: error: dereferencing pointer ‘p’ does break strict-aliasing rules util/session.c:697: note: initialized from here tools/perf/util/include/linux/bitops.h:101: note: initialized from here make[1]: *** [util/session.o] Error 1 make: *** [util/session.o] Error 2 The aliased types here are u64 and unsigned long pointers, which is safe for the find_first_bit processing. This error shows up for me only for gcc 4.4 on 32bit x86, even for -Wstrict-aliasing=3, while newer gcc are quiet and scream here for -Wstrict-aliasing={2,1}. Looks like newer gcc changed the rules for strict alias warnings. The gcc documentation offers workaround for valid aliasing by using __may_alias__ attribute: http://gcc.gnu.org/onlinedocs/gcc-4.4.0/gcc/Type-Attributes.html Using this workaround for the find_first_bit function. Signed-off-by: Jiri Olsa <jolsa@redhat.com> Cc: Corey Ashford <cjashfor@linux.vnet.ibm.com> Cc: David Ahern <dsahern@gmail.com> Cc: Frederic Weisbecker <fweisbec@gmail.com> Cc: Ingo Molnar <mingo@elte.hu> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Paul Mackerras <paulus@samba.org> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl> Link: http://lkml.kernel.org/r/1393434867-20271-1-git-send-email-jolsa@redhat.comSigned-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
-
- 27 Feb, 2014 4 commits
-
-
Andi Kleen authored
opensuse libbfd requires -lz -liberty to build. Add those to the BFD feature detection. Signed-off-by: Andi Kleen <ak@linux.intel.com> Acked-by: David Ahern <dsahern@gmail.com> Acked-by: Jiri Olsa <jolsa@redhat.com> Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: David Ahern <dsahern@gmail.com> Cc: Frederic Weisbecker <fweisbec@gmail.com> Cc: Ingo Molnar <mingo@kernel.org> Cc: Jiri Olsa <jolsa@redhat.com> Cc: Namhyung Kim <namhyung@kernel.org> Link: http://lkml.kernel.org/r/1389469379-13340-2-git-send-email-andi@firstfloor.orgSigned-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
-
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 fixes from Arnaldo Carvalho de Melo: * Fix annotation on stdio/GTK+ interfaces (Namhyung Kim) * Fix file descriptor leaking while searching DSOs for suitable symtab (Namhyung Kim). Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com> Signed-off-by: Ingo Molnar <mingo@kernel.org>
-
Peter Zijlstra authored
Drew Richardson reported that he could make the kernel go *boom* when hotplugging while having perf events active. It turned out that when you have a group event, the code in __perf_event_exit_context() fails to remove the group siblings from the context. We then proceed with destroying and freeing the event, and when you re-plug the CPU and try and add another event to that CPU, things go *boom* because you've still got dead entries there. Reported-by: Drew Richardson <drew.richardson@arm.com> Signed-off-by: Peter Zijlstra <peterz@infradead.org> Cc: Will Deacon <will.deacon@arm.com> Cc: <stable@vger.kernel.org> Link: http://lkml.kernel.org/n/tip-k6v5wundvusvcseqj1si0oz0@git.kernel.orgSigned-off-by: Ingo Molnar <mingo@kernel.org>
-
Peter Zijlstra authored
Vince "Super Tester" Weaver reported a new round of syscall fuzzing (Trinity) failures, with perf WARN_ON()s triggering. He also provided traces of the failures. This is I think the relevant bit: > pec_1076_warn-2804 [000] d... 147.926153: x86_pmu_disable: x86_pmu_disable > pec_1076_warn-2804 [000] d... 147.926153: x86_pmu_state: Events: { > pec_1076_warn-2804 [000] d... 147.926156: x86_pmu_state: 0: state: .R config: ffffffffffffffff ( (null)) > pec_1076_warn-2804 [000] d... 147.926158: x86_pmu_state: 33: state: AR config: 0 (ffff88011ac99800) > pec_1076_warn-2804 [000] d... 147.926159: x86_pmu_state: } > pec_1076_warn-2804 [000] d... 147.926160: x86_pmu_state: n_events: 1, n_added: 0, n_txn: 1 > pec_1076_warn-2804 [000] d... 147.926161: x86_pmu_state: Assignment: { > pec_1076_warn-2804 [000] d... 147.926162: x86_pmu_state: 0->33 tag: 1 config: 0 (ffff88011ac99800) > pec_1076_warn-2804 [000] d... 147.926163: x86_pmu_state: } > pec_1076_warn-2804 [000] d... 147.926166: collect_events: Adding event: 1 (ffff880119ec8800) So we add the insn:p event (fd[23]). At this point we should have: n_events = 2, n_added = 1, n_txn = 1 > pec_1076_warn-2804 [000] d... 147.926170: collect_events: Adding event: 0 (ffff8800c9e01800) > pec_1076_warn-2804 [000] d... 147.926172: collect_events: Adding event: 4 (ffff8800cbab2c00) We try and add the {BP,cycles,br_insn} group (fd[3], fd[4], fd[15]). These events are 0:cycles and 4:br_insn, the BP event isn't x86_pmu so that's not visible. group_sched_in() pmu->start_txn() /* nop - BP pmu */ event_sched_in() event->pmu->add() So here we should end up with: 0: n_events = 3, n_added = 2, n_txn = 2 4: n_events = 4, n_added = 3, n_txn = 3 But seeing the below state on x86_pmu_enable(), the must have failed, because the 0 and 4 events aren't there anymore. Looking at group_sched_in(), since the BP is the leader, its event_sched_in() must have succeeded, for otherwise we would not have seen the sibling adds. But since neither 0 or 4 are in the below state; their event_sched_in() must have failed; but I don't see why, the complete state: 0,0,1:p,4 fits perfectly fine on a core2. However, since we try and schedule 4 it means the 0 event must have succeeded! Therefore the 4 event must have failed, its failure will have put group_sched_in() into the fail path, which will call: event_sched_out() event->pmu->del() on 0 and the BP event. Now x86_pmu_del() will reduce n_events; but it will not reduce n_added; giving what we see below: n_event = 2, n_added = 2, n_txn = 2 > pec_1076_warn-2804 [000] d... 147.926177: x86_pmu_enable: x86_pmu_enable > pec_1076_warn-2804 [000] d... 147.926177: x86_pmu_state: Events: { > pec_1076_warn-2804 [000] d... 147.926179: x86_pmu_state: 0: state: .R config: ffffffffffffffff ( (null)) > pec_1076_warn-2804 [000] d... 147.926181: x86_pmu_state: 33: state: AR config: 0 (ffff88011ac99800) > pec_1076_warn-2804 [000] d... 147.926182: x86_pmu_state: } > pec_1076_warn-2804 [000] d... 147.926184: x86_pmu_state: n_events: 2, n_added: 2, n_txn: 2 > pec_1076_warn-2804 [000] d... 147.926184: x86_pmu_state: Assignment: { > pec_1076_warn-2804 [000] d... 147.926186: x86_pmu_state: 0->33 tag: 1 config: 0 (ffff88011ac99800) > pec_1076_warn-2804 [000] d... 147.926188: x86_pmu_state: 1->0 tag: 1 config: 1 (ffff880119ec8800) > pec_1076_warn-2804 [000] d... 147.926188: x86_pmu_state: } > pec_1076_warn-2804 [000] d... 147.926190: x86_pmu_enable: S0: hwc->idx: 33, hwc->last_cpu: 0, hwc->last_tag: 1 hwc->state: 0 So the problem is that x86_pmu_del(), when called from a group_sched_in() that fails (for whatever reason), and without x86_pmu TXN support (because the leader is !x86_pmu), will corrupt the n_added state. Reported-and-Tested-by: Vince Weaver <vincent.weaver@maine.edu> Signed-off-by: Peter Zijlstra <peterz@infradead.org> Cc: Paul Mackerras <paulus@samba.org> Cc: Steven Rostedt <rostedt@goodmis.org> Cc: Stephane Eranian <eranian@google.com> Cc: Dave Jones <davej@redhat.com> Cc: <stable@vger.kernel.org> Link: http://lkml.kernel.org/r/20140221150312.GF3104@twins.programming.kicks-ass.netSigned-off-by: Ingo Molnar <mingo@kernel.org>
-
- 25 Feb, 2014 16 commits
-
-
Linus Torvalds authored
Merge misc fixes from Andrew Morton. * emailed patches from Andrew Morton akpm@linux-foundation.org>: MAINTAINERS: change mailing list address for Altera UART drivers Makefile: fix build with make 3.80 again MAINTAINERS: update L: misuses Makefile: fix extra parenthesis typo when CC_STACKPROTECTOR_REGULAR is enabled ipc,mqueue: remove limits for the amount of system-wide queues memcg: change oom_info_lock to mutex mm, thp: fix infinite loop on memcg OOM drivers/fmc/fmc-write-eeprom.c: fix decimal permissions drivers/iommu/omap-iommu-debug.c: fix decimal permissions mm, hwpoison: release page on PageHWPoison() in __do_fault()
-
Tobias Klauser authored
The nios2-dev list has been moved to the RocketBoards infrastructure, so adjust the address accordingly. Signed-off-by: Tobias Klauser <tklauser@distanz.ch> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
-
Jan Beulich authored
According to Documentation/Changes, make 3.80 is still being supported for building the kernel, hence make files must not make (unconditional) use of features introduced only in newer versions. Commit 8779657d ("stackprotector: Introduce CONFIG_CC_STACKPROTECTOR_STRONG") however introduced an "else ifdef" construct which make 3.80 doesn't understand. Also correct a warning message still referencing the old config option name. Apart from that I question the use of "ifdef" here (but it was used that way already prior to said commit): ifeq (,y) would seem more to the point. Signed-off-by: Jan Beulich <jbeulich@suse.com> Acked-by: Kees Cook <keescook@chromium.org> Cc: Ingo Molnar <mingo@kernel.org> Cc: Michal Marek <mmarek@suse.cz> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
-
Joe Perches authored
L: lines are for the email addresses of traditional mailing lists. W: lines are for URLs. Convert two L: misuses to W: links. Signed-off-by: Joe Perches <joe@perches.com> Reported-by: Paul Bolle <pebolle@tiscali.nl> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
-
Fathi Boudra authored
An extra parenthesis typo introduced in 19952a92 ("stackprotector: Unify the HAVE_CC_STACKPROTECTOR logic between architectures") is causing the following error when CONFIG_CC_STACKPROTECTOR_REGULAR is enabled: Makefile:608: Cannot use CONFIG_CC_STACKPROTECTOR: -fstack-protector not supported by compiler Makefile:608: *** missing separator. Stop. Signed-off-by: Fathi Boudra <fathi.boudra@linaro.org> Acked-by: Kees Cook <keescook@chromium.org> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
-
Davidlohr Bueso authored
Commit 93e6f119 ("ipc/mqueue: cleanup definition names and locations") added global hardcoded limits to the amount of message queues that can be created. While these limits are per-namespace, reality is that it ends up breaking userspace applications. Historically users have, at least in theory, been able to create up to INT_MAX queues, and limiting it to just 1024 is way too low and dramatic for some workloads and use cases. For instance, Madars reports: "This update imposes bad limits on our multi-process application. As our app uses approaches that each process opens its own set of queues (usually something about 3-5 queues per process). In some scenarios we might run up to 3000 processes or more (which of-course for linux is not a problem). Thus we might need up to 9000 queues or more. All processes run under one user." Other affected users can be found in launchpad bug #1155695: https://bugs.launchpad.net/ubuntu/+source/manpages/+bug/1155695 Instead of increasing this limit, revert it entirely and fallback to the original way of dealing queue limits -- where once a user's resource limit is reached, and all memory is used, new queues cannot be created. Signed-off-by: Davidlohr Bueso <davidlohr@hp.com> Reported-by: Madars Vitolins <m@silodev.com> Acked-by: Doug Ledford <dledford@redhat.com> Cc: Manfred Spraul <manfred@colorfullife.com> Cc: <stable@vger.kernel.org> [3.5+] Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
-
Michal Hocko authored
Kirill has reported the following: Task in /test killed as a result of limit of /test memory: usage 10240kB, limit 10240kB, failcnt 51 memory+swap: usage 10240kB, limit 10240kB, failcnt 0 kmem: usage 0kB, limit 18014398509481983kB, failcnt 0 Memory cgroup stats for /test: BUG: sleeping function called from invalid context at kernel/cpu.c:68 in_atomic(): 1, irqs_disabled(): 0, pid: 66, name: memcg_test 2 locks held by memcg_test/66: #0: (memcg_oom_lock#2){+.+...}, at: [<ffffffff81131014>] pagefault_out_of_memory+0x14/0x90 #1: (oom_info_lock){+.+...}, at: [<ffffffff81197b2a>] mem_cgroup_print_oom_info+0x2a/0x390 CPU: 2 PID: 66 Comm: memcg_test Not tainted 3.14.0-rc1-dirty #745 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS Bochs 01/01/2011 Call Trace: __might_sleep+0x16a/0x210 get_online_cpus+0x1c/0x60 mem_cgroup_read_stat+0x27/0xb0 mem_cgroup_print_oom_info+0x260/0x390 dump_header+0x88/0x251 ? trace_hardirqs_on+0xd/0x10 oom_kill_process+0x258/0x3d0 mem_cgroup_oom_synchronize+0x656/0x6c0 ? mem_cgroup_charge_common+0xd0/0xd0 pagefault_out_of_memory+0x14/0x90 mm_fault_error+0x91/0x189 __do_page_fault+0x48e/0x580 do_page_fault+0xe/0x10 page_fault+0x22/0x30 which complains that mem_cgroup_read_stat cannot be called from an atomic context but mem_cgroup_print_oom_info takes a spinlock. Change oom_info_lock to a mutex. This was introduced by 947b3dd1 ("memcg, oom: lock mem_cgroup_print_oom_info"). Signed-off-by: Michal Hocko <mhocko@suse.cz> Reported-by: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com> Cc: Johannes Weiner <hannes@cmpxchg.org> Cc: David Rientjes <rientjes@google.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
-
Kirill A. Shutemov authored
Masayoshi Mizuma reported a bug with the hang of an application under the memcg limit. It happens on write-protection fault to huge zero page If we successfully allocate a huge page to replace zero page but hit the memcg limit we need to split the zero page with split_huge_page_pmd() and fallback to small pages. The other part of the problem is that VM_FAULT_OOM has special meaning in do_huge_pmd_wp_page() context. __handle_mm_fault() expects the page to be split if it sees VM_FAULT_OOM and it will will retry page fault handling. This causes an infinite loop if the page was not split. do_huge_pmd_wp_zero_page_fallback() can return VM_FAULT_OOM if it failed to allocate one small page, so fallback to small pages will not help. The solution for this part is to replace VM_FAULT_OOM with VM_FAULT_FALLBACK is fallback required. Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com> Reported-by: Masayoshi Mizuma <m.mizuma@jp.fujitsu.com> Reviewed-by: Michal Hocko <mhocko@suse.cz> Cc: Johannes Weiner <hannes@cmpxchg.org> Cc: Andrea Arcangeli <aarcange@redhat.com> Cc: David Rientjes <rientjes@google.com> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
-
Joe Perches authored
This 444 should have been octal. Signed-off-by: Joe Perches <joe@perches.com> Cc: Alessandro Rubini <rubini@gnudd.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
-
Joe Perches authored
These should have been octal. Signed-off-by: Joe Perches <joe@perches.com> Cc: Joerg Roedel <joro@8bytes.org> Cc: Hiroshi DOYU <Hiroshi.DOYU@nokia.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
-
Kirill A. Shutemov authored
It seems we forget to release page after detecting HW error. Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com> Cc: Mel Gorman <mgorman@suse.de> Cc: Rik van Riel <riel@redhat.com> Cc: Andi Kleen <ak@linux.intel.com> Cc: Matthew Wilcox <matthew.r.wilcox@intel.com> Cc: Dave Hansen <dave.hansen@linux.intel.com> Cc: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
-
Linus Torvalds authored
Merge tag 'dmaengine-fixes-3.14-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/djbw/dmaengine Pull dmaengine fixes from Dan Williams: "Fix tasklet lifetime management in the ioat driver causing ksoftirqd to spin indefinitely. References: https://lkml.org/lkml/2014/1/27/282 https://lkml.org/lkml/2014/2/19/672" * tag 'dmaengine-fixes-3.14-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/djbw/dmaengine: ioat: fix tasklet tear down
-
git://git.infradead.org/linux-mtdLinus Torvalds authored
Pull MTD fixes from Brian Norris: "Two main MTD fixes: 1. Read retry counting was off by one, so if we had a true ECC error (i.e., no retry voltage threshold would give a clean read), we would end up returning -EINVAL on the Nth mode instead of -EBADMSG after then (N-1)th mode 2. The OMAP NAND driver had some of its ECC layouts wrong when introduced in 3.13, causing incompatibilities between the bootloader on-flash layout and the layout expected in Linux. The expected layouts are now documented in the commit messages, and we plan to add this under Documentation/mtd/nand/ eventually" * tag 'for-linus-20140225' of git://git.infradead.org/linux-mtd: mtd: nand: omap: fix ecclayout->oobfree->length mtd: nand: omap: fix ecclayout->oobfree->offset mtd: nand: omap: fix ecclayout to be in sync with u-boot NAND driver mtd: nand: fix off-by-one read retry mode counting
-
git://git.kernel.org/pub/scm/linux/kernel/git/geert/linux-m68kLinus Torvalds authored
Pull m68k update from Geert Uytterhoeven: - More barrier.h consolidation - Sched_[gs]etattr() syscalls * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/geert/linux-m68k: m68k: Wire up sched_setattr and sched_getattr m68k: Switch to asm-generic/barrier.h m68k: Sort arch/m68k/include/asm/Kbuild
-
git://github.com/czankel/xtensa-linuxLinus Torvalds authored
Pull tensa fixes from Chris Zankel: "This series includes fixes for potentially serious bugs in the routines spilling processor registers to stack, as well as other issues and compiler errors and warnings. - allow booting xtfpga on boards with new uBoot and >128MBytes memory - drop nonexistent GPIO32 support from fsf variant - don't select USE_GENERIC_SMP_HELPERS - enable common clock framework support, set up ethoc clock on xtfpga - wire up sched_setattr and sched_getattr syscalls. - fix system call to spill the processor registers to stack. - improve kernel macro to spill the processor registers - export ccount_freq symbol - fix undefined symbol warning" * tag 'xtensa-next-20140224' of git://github.com/czankel/xtensa-linux: xtensa: wire up sched_setattr and sched_getattr syscalls xtensa: xtfpga: set ethoc clock frequency xtensa: xtfpga: use common clock framework xtensa: support common clock framework xtensa: no need to select USE_GENERIC_SMP_HELPERS xtensa: fsf: drop nonexistent GPIO32 support xtensa: don't pass high memory to bootmem allocator xtensa: fix fast_syscall_spill_registers xtensa: fix fast_syscall_spill_registers xtensa: save current register frame in fast_syscall_spill_registers_fixup xtensa: introduce spill_registers_kernel macro xtensa: export ccount_freq xtensa: fix warning '"CONFIG_OF" is not defined'
-
Dan Williams authored
Since commit 77873803 "net_dma: mark broken" we no longer pin dma engines active for the network-receive-offload use case. As a result the ->free_chan_resources() that occurs after the driver self test no longer has a NET_DMA induced ->alloc_chan_resources() to back it up. A late firing irq can lead to ksoftirqd spinning indefinitely due to the tasklet_disable() performed by ->free_chan_resources(). Only ->alloc_chan_resources() can clear this condition in affected kernels. This problem has been present since commit 3e037454 "I/OAT: Add support for MSI and MSI-X" in 2.6.24, but is now exposed. Given the NET_DMA use case is deprecated we can revisit moving the driver to use threaded irqs. For now, just tear down the irq and tasklet properly by: 1/ Disable the irq from triggering the tasklet 2/ Disable the irq from re-arming 3/ Flush inflight interrupts 4/ Flush the timer 5/ Flush inflight tasklets References: https://lkml.org/lkml/2014/1/27/282 https://lkml.org/lkml/2014/2/19/672 Cc: Ingo Molnar <mingo@elte.hu> Cc: Steven Rostedt <rostedt@goodmis.org> Cc: <stable@vger.kernel.org> Reported-by: Mike Galbraith <bitbucket@online.de> Reported-by: Stanislav Fomichev <stfomichev@yandex-team.ru> Tested-by: Mike Galbraith <bitbucket@online.de> Tested-by: Stanislav Fomichev <stfomichev@yandex-team.ru> Reviewed-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Dan Williams <dan.j.williams@intel.com>
-
- 24 Feb, 2014 9 commits
-
-
git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-securityLinus Torvalds authored
Pull SELinux endianness fix from James Morris. * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security: SELinux: bigendian problems with filename trans rules
-
git://git.kernel.org/pub/scm/linux/kernel/git/s390/linuxLinus Torvalds authored
Pull s390 bug fixes from Martin Schwidefsky: "A couple of s390 bug fixes. The PCI segment boundary issue is a nasty one as it can lead to data corruption" * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux: s390/cio: Fix missing subchannels after CHPID configure on s390/pci/dma: use correct segment boundary size s390/compat: fix sys_sched_getattr compat wrapper s390/zcrypt: additional check to avoid overflow in msg-type 6 requests
-
Namhyung Kim authored
Stephane reported that perf report and annotate failed to process data using lots of (> 500) shared libraries. It was because of the limit on number of open files (ulimit -n). Currently when perf loads a DSO, it'll look for normal and dynamic symbol tables. And if it fails to find out both tables, it'll iterate all of possible symtab types. But many of them are useless since they have no additional information and the problem is that it's not closing those files even though they're not used. Fix it. Reported-by: Stephane Eranian <eranian@google.com> Signed-off-by: Namhyung Kim <namhyung@kernel.org> Cc: Cody P Schafer <cody@linux.vnet.ibm.com> Cc: Ingo Molnar <mingo@kernel.org> Cc: Namhyung Kim <namhyung.kim@lge.com> Cc: Paul Mackerras <paulus@samba.org> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl> Link: http://lkml.kernel.org/r/1392859976-32760-2-git-send-email-namhyung@kernel.orgSigned-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
-
Namhyung Kim authored
The TUI of perf report and top support annotation, but stdio and GTK don't. So it should be checked before calling hist_entry__inc_addr_ samples() to avoid wasting resources that will never be used. perf annotate need it regardless of UI and sort keys, so the check of whether to allocate resources should be on the tools that have annotate as an option in the TUI, 'report' and 'top', not on the function called by all of them. It caused perf annotate on ppc64 to produce zero output, since the buckets were not being allocated. Reported-by: Anton Blanchard <anton@samba.org> Signed-off-by: Namhyung Kim <namhyung@kernel.org> Cc: Anton Blanchard <anton@samba.org> Cc: Ingo Molnar <mingo@kernel.org> Cc: Namhyung Kim <namhyung.kim@lge.com> Cc: Paul Mackerras <paulus@samba.org> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl> Link: http://lkml.kernel.org/r/1392859976-32760-1-git-send-email-namhyung@kernel.org [ Renamed (report,top)__needs_annotate() to ui__has_annotation() ] Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
-
Chris Zankel authored
Xtensa fixes for 3.14: - allow booting xtfpga on boards with new uBoot and >128MBytes memory; - drop nonexistent GPIO32 support from fsf variant; - don't select USE_GENERIC_SMP_HELPERS; - enable common clock framework support, set up ethoc clock on xtfpga; - wire up sched_setattr and sched_getattr syscalls. Signed-off-by: Chris Zankel <chris@zankel.net>
-
-
Linus Torvalds authored
-
git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-socLinus Torvalds authored
Pull ARM SoC fixes from Olof Johansson: "A collection of fixes for ARM platforms. Most are fixes for DTS files, mostly from DT conversion on OMAP which is still finding a few issues here and there. There's a couple of small stale code removal patches that we usually queue for the next release instead, but they seemed harmless enough to bring in now. Also, a fix for backlight on some PXA platforms, and a cache configuration fix for Tegra, etc" * tag 'fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc: (25 commits) MAINTAINERS: add additional ARM BCM281xx/BCM11xxx maintainer ARM: tegra: only run PL310 init on systems with one ARM: tegra: Add head numbers to display controllers ARM: imx6: build pm-imx6q.c independently of CONFIG_PM ARM: tegra: fix RTC0 alias for Cardhu ARM: dove: dt: revert PMU interrupt controller node Documentation: dt: OMAP: Update Overo/Tobi ARM: dts: Add support for both OMAP35xx and OMAP36xx Overo/Tobi ARM: dts: omap3-tobi: Use the correct vendor prefix ARM: dts: omap3-tobi: Fix boot with OMAP36xx-based Overo ARM: OMAP2+: Remove legacy macros for zoom platforms ARM: OMAP2+: Remove MACH_NOKIA_N800 ARM: dts: N900: add missing compatible property ARM: dts: N9/N950: fix boot hang with 3.14-rc1 ARM: OMAP1: nokia770: enable tahvo-usb ARM: OMAP2+: gpmc: fix: DT ONENAND child nodes not probed when MTD_ONENAND is built as module ARM: OMAP2+: gpmc: fix: DT NAND child nodes not probed when MTD_NAND is built as module ARM: dts: omap3-gta04: Fix mmc1 properties. ARM: dts: omap3-gta04: Fix 'aux' gpio key flags. ARM: OMAP2+: add missing ARCH_HAS_OPP ...
-
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulatorLinus Torvalds authored
Pull regulator fixes from Mark Brown: "Mostly unexciting driver fixes, plus one fix to lower the severity of the log message when we don't use an optional regulator - the fixes for ACPI system made this come up more often and it was correctly observed that it was causing undue concern for users" * tag 'regulator-v3.14-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator: regulator: max14577: Fix invalid return value on DT parse success regulator: core: Change dummy supplies error message to a warning regulator: s5m8767: Add missing of_node_put regulator: s5m8767: Use of_get_child_by_name regulator: da9063: Bug fix when setting max voltage on LDOs 5-11
-
- 23 Feb, 2014 9 commits
-
-
Pekon Gupta authored
This patch excludes reserved-marker byte-position from oobfree->length calculation. Thus all bytes from oobfree->offset till end of OOB are free. CC: <stable@vger.kernel.org> # 3.13.x+ Signed-off-by: Pekon Gupta <pekon@ti.com> Signed-off-by: Brian Norris <computersforpeace@gmail.com>
-
Pekon Gupta authored
1) In current implementation, ecclayout->oobfree->offset is calculated with respect to ecclayout->eccpos[0] which is incorrect because ECC bytes may not be stored contiguously in OOB. So, this patch calculates ecclayout->oobfree->offset with respect to last ECC byte-position 'eccpos[ecclayout->eccbytes-1]'. 2) ECC layout of some ecc-schemes expects reserved-markers at specific eccpos[] which should not be over-written by any file-system metadata. So this patch aligns oobfree->offset taking into account of such markers. CC: <stable@vger.kernel.org> # 3.13.x+ Tested-by: Enric Balletbo i Serra <eballetbo@gmail.com> Tested-by: Stefan Roese <sr@denx.de> Signed-off-by: Pekon Gupta <pekon@ti.com> Signed-off-by: Brian Norris <computersforpeace@gmail.com>
-
Pekon Gupta authored
Fixes: commit a919e511 mtd: nand: omap2: clean-up BCHx_HW and BCHx_SW ECC configurations in device_probe Fixes ecclayout mismatch introduced in above commit for following ecc-schemes: - OMAP_ECC_BCH4_CODE_HW_DETECTION_SW - OMAP_ECC_BCH8_CODE_HW_DETECTION_SW However, this patch also touches other ecc-schemes as the fix required refactoring common code, into ecc-scheme specific code. This patch aligns ecc-layout for below ecc-schemes as per reference [1],[2],[3] +---+------------+-------------++-------------+-------------+ |OOB|BCH8_CODE_HW|BCH8_CODE_HW_||HAM1_CODE_HW |HAM1_CODE_HW | |pos| | DETECTION_SW||(x8 device) |(x16 device) | +---+------------+-------------++-------------+-------------+ | 0 |BADBLK_MARK | BADBLK_MARK || BADBLK_MARK | BADBLK_MARK | | 1 |BADBLK_MARK | BADBLK_MARK || eccpos[0] | BADBLK_MARK | | 2 | eccpos[0] | eccpos[0] || eccpos[1] | eccpos[0] | | 3 | eccpos[1] | eccpos[1] || eccpos[2] | eccpos[1] | | 4 | eccpos[2] | eccpos[2] || eccpos[3] | eccpos[2] | | 5 | eccpos[3] | eccpos[3] || eccpos[4] | eccpos[3] | | 6 | eccpos[4] | eccpos[4] || eccpos[5] | eccpos[4] | | 7 | eccpos[5] | eccpos[5] || eccpos[6] | eccpos[5] | | 8 | eccpos[6] | eccpos[6] || eccpos[7] | eccpos[6] | | 9 | eccpos[7] | eccpos[7] || eccpos[8] | eccpos[7] | |10 | eccpos[8] | eccpos[8] || eccpos[9] | eccpos[8] | |11 | eccpos[9] | eccpos[9] || eccpos[10] | eccpos[9] | |12 | eccpos[10] | eccpos[10] || eccpos[11] | eccpos[10] | |13 | eccpos[11] | eccpos[11] || oobfree[0] | eccpos[11] | |14 | eccpos[12] | eccpos[12] || oobfree[1] | oobfree[0] | |15 | eccpos[13] | <reserved> || oobfree[2] | oobfree[1] | +---+------------+-------------++-------------+-------------+ |16 | eccpos[14] | eccpos[13] || oobfree[3] | oobfree[2] | |...| [...] | [...] || [...] | [...] | |56 | eccpos[54] | eccpos[51] || oobfree[43] | oobfree[42] | |57 | eccpos[55] | <reserved> || oobfree[44] | oobfree[43] | +===+============+=============+==============+=============+ |58 | oobfree[0] | oobfree[0] || oobfree[45] | oobfree[44] | |59 | oobfree[1] | oobfree[1] || oobfree[46] | oobfree[45] | |60 | oobfree[2] | oobfree[2] || oobfree[47] | oobfree[46] | |61 | oobfree[3] | oobfree[3] || oobfree[48] | oobfree[47] | |62 | oobfree[4] | oobfree[4] || oobfree[49] | oobfree[48] | |63 | oobfree[5] | oobfree[5] || oobfree[50] | oobfree[49] | +---+------------+-------------+--------------+-------------+ [1] ecc-layout expected by ROM code, as specified in SoC TRM under: Chapter="Initialization" Section="Device Initialization by ROM code" Sub-Section="Memory Booting" Heading="NAND" Figure="ECC Locations in NAND Spare Areas" [2] ecc-layout updates in u-boot http://lists.denx.de/pipermail/u-boot/2013-November/167551.html [3] u-boot configurations to match above ecc-layout are documented at https://processors.wiki.ti.com/index.php/Linux_Core_NAND_User%27s_Guide CC: <stable@vger.kernel.org> # 3.13.x+ Reported-by: Enric Balletbo Serra <eballetbo@iseebcn.com> Tested-by: Enric Balletbo i Serra <eballetbo@gmail.com> Tested-by: Stefan Roese <sr@denx.de> Signed-off-by: Pekon Gupta <pekon@ti.com> Signed-off-by: Brian Norris <computersforpeace@gmail.com>
-
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tipLinus Torvalds authored
Pull timer fix from Thomas Gleixner: "Serialize the registration of a new sched_clock in the currently ARM only generic sched_clock facilty to avoid sched_clock havoc" * 'timers-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: sched_clock: Prevent callers from seeing half-updated data
-
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tipLinus Torvalds authored
Pull x86 fixes from Thomas Gleixner: - a bugfix which prevents a divide by 0 panic when the newly introduced try_msr_calibrate_tsc() fails - enablement of the Baytrail platform to utilize the newfangled msr based calibration * 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: x86: tsc: Add missing Baytrail frequency to the table x86, tsc: Fallback to normal calibration if fast MSR calibration fails
-
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tipLinus Torvalds authored
Pull irq fixes from Thomas Gleixner: "Another four fixlets to tame the ARM orion irq chip" * 'irq-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: irqchip: orion: Fix getting generic chip pointer. irqchip: orion: clear stale interrupts in irq_startup irqchip: orion: use handle_edge_irq on bridge irqs irqchip: orion: clear bridge cause register on init
-
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usbLinus Torvalds authored
Pull USB fixes from Greg KH: "Here are a number of USB fixes for reported issues for 3.14-rc4 The majority of these are for USB gadget, phy, and musb driver issues. And there's a few new device ids thrown in for good measure" * tag 'usb-3.14-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb: usb: chipidea: need to mask when writting endptflush and endptprime usb: musb: correct use of schedule_delayed_work() usb: phy: msm: fix compilation errors when !CONFIG_PM_SLEEP usb: gadget: fix NULL pointer dereference usb: gadget: printer: using gadget_is_otg to check otg support at runtime phy: let phy_provider_register be the last step in registering PHY phy-core: Don't allow building phy-core as a module phy-core: Don't propagate -ENOSUPP from phy_pm_runtime_get_sync to caller phy-core: phy_get: Leave error logging to the caller phy,phy-bcm-kona-usb2.c: Add dependency on HAS_IOMEM usb: musb: correct use of schedule_delayed_work() usb: musb: do not sleep in atomic context USB: serial: option: blacklist interface 4 for Cinterion PHS8 and PXS8 USB: EHCI: add delay during suspend to prevent erroneous wakeups usb: gadget: bcm63xx_udc: fix build failure on DMA channel code usb: musb: do not sleep in atomic context usb: gadget: s3c2410_udc: Fix build error usb: musb: core: Fix remote-wakeup resume usb: musb: host: Fix SuperSpeed hub enumeration usb: musb: fix obex in g_nokia.ko causing kernel panic
-
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/ttyLinus Torvalds authored
Pull TTY revert from Greg KH: "Here is a single commit, a revert of a sysfs file change that ended up breaking a userspace tool" * tag 'tty-3.14-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty: Revert "tty: Set correct tty name in 'active' sysfs attribute"
-
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/stagingLinus Torvalds authored
Pull staging tree fix from Greg KH: "Here is a single android driver fix for 3.14-rc4 that fixes a reported problem in the binder driver" * tag 'staging-3.14-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging: staging: binder: Fix death notifications
-