- 25 Feb, 2016 40 commits
-
-
Matthew Wilcox authored
commit 46437f9a upstream. If the indirect_ptr bit is set on a slot, that indicates we need to redo the lookup. Introduce a new function radix_tree_iter_retry() which forces the loop to retry the lookup by setting 'slot' to NULL and turning the iterator back to point at the problematic entry. This is a pretty rare problem to hit at the moment; the lookup has to race with a grow of the radix tree from a height of 0. The consequences of hitting this race are that gang lookup could return a pointer to a radix_tree_node instead of a pointer to whatever the user had inserted in the tree. Fixes: cebbd29e ("radix-tree: rewrite gang lookup using iterator") Signed-off-by:
Matthew Wilcox <willy@linux.intel.com> Cc: Hugh Dickins <hughd@google.com> Cc: Ohad Ben-Cohen <ohad@wizery.com> Cc: Konstantin Khlebnikov <khlebnikov@openvz.org> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Rich Felker authored
commit 114bf37e upstream. Add Yoshinori Sato and Rich Felker as maintainers for arch/sh (SUPERH). Signed-off-by:
Rich Felker <dalias@libc.org> Signed-off-by:
Yoshinori Sato <ysato@users.sourceforge.jp> Acked-by:
D. Jeff Dionne <jeff@uClinux.org> Acked-by:
Rob Landley <rob@landley.net> Acked-by:
Peter Zijlstra (Intel) <peterz@infradead.org> Acked-by:
Simon Horman <horms+renesas@verge.net.au> Acked-by:
Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by:
-
Martijn Coenen authored
commit 6611d8d7 upstream. A spare array holding mem cgroup threshold events is kept around to make sure we can always safely deregister an event and have an array to store the new set of events in. In the scenario where we're going from 1 to 0 registered events, the pointer to the primary array containing 1 event is copied to the spare slot, and then the spare slot is freed because no events are left. However, it is freed before calling synchronize_rcu(), which means readers may still be accessing threshold->primary after it is freed. Fixed by only freeing after synchronize_rcu(). Signed-off-by:
Martijn Coenen <maco@google.com> Cc: Johannes Weiner <hannes@cmpxchg.org> Acked-by:
Michal Hocko <mhocko@suse.com> Cc: Vladimir Davydov <vdavydov@virtuozzo.com> Signed-off-by:
-
Michael Holzheu authored
commit 5c2ff95e upstream. When working with hugetlbfs ptes (which are actually pmds) is not valid to directly use pte functions like pte_present() because the hardware bit layout of pmds and ptes can be different. This is the case on s390. Therefore we have to convert the hugetlbfs ptes first into a valid pte encoding with huge_ptep_get(). Currently the /proc/<pid>/numa_maps code uses hugetlbfs ptes without huge_ptep_get(). On s390 this leads to the following two problems: 1) The pte_present() function returns false (instead of true) for PROT_NONE hugetlb ptes. Therefore PROT_NONE vmas are missing completely in the "numa_maps" output. 2) The pte_dirty() function always returns false for all hugetlb ptes. Therefore these pages are reported as "mapped=xxx" instead of "dirty=xxx". Therefore use huge_ptep_get() to correctly convert the hugetlb ptes. Signed-off-by:
Michael Holzheu <holzheu@linux.vnet.ibm.com> Reviewed-by:
Gerald Schaefer <gerald.schaefer@de.ibm.com> Signed-off-by:
-
Mike Kravetz authored
commit 9aacdd35 upstream. Hillf Danton noticed bugs in the hugetlb_vmtruncate_list routine. The argument end is of type pgoff_t. It was being converted to a vaddr offset and passed to unmap_hugepage_range. However, end was also being used as an argument to the vma_interval_tree_foreach controlling loop. In addition, the conversion of end to vaddr offset was incorrect. hugetlb_vmtruncate_list is called as part of a file truncate or fallocate hole punch operation. When truncating a hugetlbfs file, this bug could prevent some pages from being unmapped. This is possible if there are multiple vmas mapping the file, and there is a sufficiently sized hole between the mappings. The size of the hole between two vmas (A,B) must be such that the starting virtual address of B is greater than (ending virtual address of A << PAGE_SHIFT). In this case, the pages in B would not be unmapped. If pages are not properly unmapped during truncate, the following BUG is hit: kernel BUG at fs/hugetlbfs/inode.c:428! In the fallocate hole punch case, this bug could prevent pages from being unmapped as in the truncate case. However, for hole punch the result is that unmapped pages will not be removed during the operation. For hole punch, it is also possible that more pages than desired will be unmapped. This unnecessary unmapping will cause page faults to reestablish the mappings on subsequent page access. Fixes: 1bfad99a (" hugetlbfs: hugetlb_vmtruncate_list() needs to take a range")Reported-by: Hillf Danton <hillf.zj@alibaba-inc.com> Signed-off-by:
Mike Kravetz <mike.kravetz@oracle.com> Cc: Hugh Dickins <hughd@google.com> Cc: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com> Cc: Davidlohr Bueso <dave@stgolabs.net> Cc: Dave Hansen <dave.hansen@linux.intel.com> Signed-off-by:
-
Sergey Senozhatsky authored
commit 72214a24 upstream. In Python3+ print is a function so the old syntax is not correct anymore: $ ./scripts/bloat-o-meter vmlinux.o vmlinux.o.old File "./scripts/bloat-o-meter", line 61 print "add/remove: %s/%s grow/shrink: %s/%s up/down: %s/%s (%s)" % \ ^ SyntaxError: invalid syntax Fix by calling print as a function. Tested on python 2.7.11, 3.5.1 Signed-off-by:
Sergey Senozhatsky <sergey.senozhatsky@gmail.com> Signed-off-by:
-
Laura Abbott authored
commit ea535e41 upstream. In include/asm-generic/sections.h: /* * Usage guidelines: * _text, _data: architecture specific, don't use them in * arch-independent code * [_stext, _etext]: contains .text.* sections, may also contain * .rodata.* * and/or .init.* sections _text is not guaranteed across architectures. Architectures such as ARM may reuse parts which are not actually text and erroneously trigger a bug. Switch to using _stext which is guaranteed to contain text sections. Came out of https://lkml.kernel.org/g/<567B1176.4000106@redhat.com> Signed-off-by:
Laura Abbott <labbott@fedoraproject.org> Reviewed-by:
Kees Cook <keescook@chromium.org> Cc: Russell King <linux@arm.linux.org.uk> Cc: Arnd Bergmann <arnd@arndb.de> Signed-off-by:
-
Sudip Mukherjee authored
commit 601f1db6 upstream. The build of m32104ut_defconfig for m32r arch was failing for long long time with the error: ERROR: "memory_start" [fs/udf/udf.ko] undefined! ERROR: "memory_end" [fs/udf/udf.ko] undefined! ERROR: "memory_end" [drivers/scsi/sg.ko] undefined! ERROR: "memory_start" [drivers/scsi/sg.ko] undefined! ERROR: "memory_end" [drivers/i2c/i2c-dev.ko] undefined! ERROR: "memory_start" [drivers/i2c/i2c-dev.ko] undefined! As done in other architectures export the symbols to fix the error. Reported-by:
Fengguang Wu <fengguang.wu@intel.com> Signed-off-by:
Sudip Mukherjee <sudip@vectorindia.org> Signed-off-by:
-
Mathias Nyman authored
commit 5c821711 upstream. xhci driver frees data for all devices, both usb2 and and usb3 the first time usb_remove_hcd() is called, including td_list and and xhci_ring structures. When usb_remove_hcd() is called a second time for the second xhci bus it will try to dequeue all pending urbs, and touches td_list which is already freed for that endpoint. Reported-by:
Joe Lawrence <joe.lawrence@stratus.com> Tested-by:
Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by:
-
Mathias Nyman authored
commit a6835090 upstream. This reverts commit e210c422 ("xhci: don't finish a TD if we get a short transfer event mid TD") Turns out that most host controllers do not follow the xHCI specs and never send the second event for the last TRB in the TD if there was a short event mid-TD. Returning the URB directly after the first short-transfer event is far better than never returning the URB. (class drivers usually timeout after 30sec). For the hosts that do send the second event we will go back to treating it as misplaced event and print an error message for it. The origial patch was sent to stable kernels and needs to be reverted from there as well Signed-off-by:
-
David Woodhouse authored
commit 46924008 upstream. According to the VT-d specification we need to clear the PPR bit in the Page Request Status register when handling page requests, or the hardware won't generate any more interrupts. This wasn't actually necessary on SKL/KBL (which may well be the subject of a hardware erratum, although it's harmless enough). But other implementations do appear to get it right, and we only ever get one interrupt unless we clear the PPR bit. Reported-by:
CQ Tang <cq.tang@intel.com> Signed-off-by:
David Woodhouse <David.Woodhouse@intel.com> Signed-off-by:
-
CQ Tang authored
commit fda3bec1 upstream. This is a 32-bit register. Apparently harmless on real hardware, but causing justified warnings in simulation. Signed-off-by:
-
David Woodhouse authored
commit e57e58bd upstream. Holding mm_users works OK for graphics, which was the first user of SVM with VT-d. However, it works less well for other devices, where we actually do a mmap() from the file descriptor to which the SVM PASID state is tied. In this case on process exit we end up with a recursive reference count: - The MM remains alive until the file is closed and the driver's release() call ends up unbinding the PASID. - The VMA corresponding to the mmap() remains intact until the MM is destroyed. - Thus the file isn't closed, even when exit_files() runs, because the VMA is still holding a reference to it. And the MM remains alive… To address this issue, we *stop* holding mm_users while the PASID is bound. We already hold mm_count by virtue of the MMU notifier, and that can be made to be sufficient. It means that for a period during process exit, the fun part of mmput() has happened and exit_mmap() has been called so the MM is basically defunct. But the PGD still exists and the PASID is still bound to it. During this period, we have to be very careful — exit_mmap() doesn't use mm->mmap_sem because it doesn't expect anyone else to be touching the MM (quite reasonably, since mm_users is zero). So we also need to fix the fault handler to just report failure if mm_users is already zero, and to temporarily bump mm_users while handling any faults. Additionally, exit_mmap() calls mmu_notifier_release() *before* it tears down the page tables, which is too early for us to flush the IOTLB for this PASID. And __mmu_notifier_release() removes every notifier from the list, so when exit_mmap() finally *does* tear down the mappings and clear the page tables, we don't get notified. So we work around this by clearing the PASID table entry in our MMU notifier release() callback. That way, the hardware *can't* get any pages back from the page tables before they get cleared. Hardware designers have confirmed that the resulting 'PASID not present' faults should be handled just as gracefully as 'page not present' faults, the important criterion being that they don't perturb the operation for any *other* PASID in the system. Signed-off-by:
-
Baoquan He authored
commit 9b1a12d2 upstream. In below commit alias DTE is set when its peripheral is setting DTE. However there's a code bug here to wrongly set the alias DTE, correct it in this patch. commit e25bfb56 Author: Joerg Roedel <jroedel@suse.de> Date: Tue Oct 20 17:33:38 2015 +0200 iommu/amd: Set alias DTE in do_attach/do_detach Signed-off-by:
Baoquan He <bhe@redhat.com> Tested-by:
Mark Hounschell <markh@compro.net> Signed-off-by:
Joerg Roedel <jroedel@suse.de> Signed-off-by:
-
Jeremy McNicoll authored
commit da972fb1 upstream. Fix a simple typo when disabling IOTLB on PCI(e) devices. Fixes: b16d0cb9 ("iommu/vt-d: Always enable PASID/PRI PCI capabilities before ATS") Signed-off-by:
Jeremy McNicoll <jmcnicol@redhat.com> Reviewed-by:
Alex Williamson <alex.williamson@redhat.com> Signed-off-by:
-
Dmitry Torokhov authored
commit d4f1b06d upstream. We should set device's capabilities first, and then register it, otherwise various handlers already present in the kernel will not be able to connect to the device. Reported-by:
Lauri Kasanen <cand@gmx.com> Signed-off-by:
Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by:
-
James Bottomley authored
commit 564b026f upstream. It was noticed that we lose precision in the final calculation for some inputs. The most egregious example is size=3000 blk_size=1900 in units of 10 should yield 5.70 MB but in fact yields 3.00 MB (oops). This is because the current algorithm doesn't correctly account for all the remainders in the logarithms. Fix this by doing a correct calculation in the remainders based on napier's algorithm. Additionally, now we have the correct result, we have to account for arithmetic rounding because we're printing 3 digits of precision. This means that if the fourth digit is five or greater, we have to round up, so add a section to ensure correct rounding. Finally account for all possible inputs correctly, including zero for block size. Fixes: b9f28d86Signed-off-by:
James Bottomley <JBottomley@Odin.com> Reported-by:
Vitaly Kuznetsov <vkuznets@redhat.com> Signed-off-by:
-
Aurélien Francillon authored
commit dd0d0d4d upstream. Without i8042.nomux=1 the Elantech touch pad is not working at all on a Fujitsu Lifebook U745. This patch does not seem necessary for all U745 (maybe because of different BIOS versions?). However, it was verified that the patch does not break those (see opensuse bug 883192: https://bugzilla.opensuse.org/show_bug.cgi?id=883192). Signed-off-by:
Aurélien Francillon <aurelien@francillon.net> Signed-off-by:
-
Benjamin Tissoires authored
commit 6544a1df upstream. When using a protocol v2 or v3 hardware, elantech uses the function elantech_report_semi_mt_data() to report data. This devices are rather creepy because if num_finger is 3, (x2,y2) is (0,0). Yes, only one valid touch is reported. Anyway, userspace (libinput) is now confused by these (0,0) touches, and detect them as palm, and rejects them. Commit 3c0213d1 ("Input: elantech - fix semi-mt protocol for v3 HW") was sufficient enough for xf86-input-synaptics and libinput before it has palm rejection. Now we need to actually tell libinput that this device is a semi-mt one and it should not rely on the actual values of the 2 touches. Signed-off-by:
Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by:
-
Kirill A. Shutemov authored
commit 48f7df32 upstream. Grazvydas Ignotas has reported a regression in remap_file_pages() emulation. Testcase: #define _GNU_SOURCE #include <assert.h> #include <stdlib.h> #include <stdio.h> #include <sys/mman.h> #define SIZE (4096 * 3) int main(int argc, char **argv) { unsigned long *p; long i; p = mmap(NULL, SIZE, PROT_READ | PROT_WRITE, MAP_SHARED | MAP_ANONYMOUS, -1, 0); if (p == MAP_FAILED) { perror("mmap"); return -1; } for (i = 0; i < SIZE / 4096; i++) p[i * 4096 / sizeof(*p)] = i; if (remap_file_pages(p, 4096, 0, 1, 0)) { perror("remap_file_pages"); return -1; } if (remap_file_pages(p, 4096 * 2, 0, 1, 0)) { perror("remap_file_pages"); return -1; } assert(p[0] == 1); munmap(p, SIZE); return 0; } The second remap_file_pages() fails with -EINVAL. The reason is that remap_file_pages() emulation assumes that the target vma covers whole area we want to over map. That assumption is broken by first remap_file_pages() call: it split the area into two vma. The solution is to check next adjacent vmas, if they map the same file with the same flags. Fixes: c8d78c18 ("mm: replace remap_file_pages() syscall with emulation") Signed-off-by:
Kirill A. Shutemov <kirill.shutemov@linux.intel.com> Reported-by:
Grazvydas Ignotas <notasas@gmail.com> Tested-by:
-
Konstantin Khlebnikov authored
commit 12352d3c upstream. Sequence vma_lock_anon_vma() - vma_unlock_anon_vma() isn't safe if anon_vma appeared between lock and unlock. We have to check anon_vma first or call anon_vma_prepare() to be sure that it's here. There are only few users of these legacy helpers. Let's get rid of them. This patch fixes anon_vma lock imbalance in validate_mm(). Write lock isn't required here, read lock is enough. And reorders expand_downwards/expand_upwards: security_mmap_addr() and wrapping-around check don't have to be under anon vma lock. Link: https://lkml.kernel.org/r/CACT4Y+Y908EjM2z=706dv4rV6dWtxTLK9nFg9_7DhRMLppBo2g@mail.gmail.comSigned-off-by:
Konstantin Khlebnikov <koct9i@gmail.com> Reported-by:
Dmitry Vyukov <dvyukov@google.com> Acked-by:
-
Kirill A. Shutemov authored
commit 7162a1e8 upstream. Tetsuo Handa reported underflow of NR_MLOCK on munlock. Testcase: #include <stdio.h> #include <stdlib.h> #include <sys/mman.h> #define BASE ((void *)0x400000000000) #define SIZE (1UL << 21) int main(int argc, char *argv[]) { void *addr; system("grep Mlocked /proc/meminfo"); addr = mmap(BASE, SIZE, PROT_READ | PROT_WRITE, MAP_ANONYMOUS | MAP_PRIVATE | MAP_LOCKED | MAP_FIXED, -1, 0); if (addr == MAP_FAILED) printf("mmap() failed\n"), exit(1); munmap(addr, SIZE); system("grep Mlocked /proc/meminfo"); return 0; } It happens on munlock_vma_page() due to unfortunate choice of nr_pages data type: __mod_zone_page_state(zone, NR_MLOCK, -nr_pages); For unsigned int nr_pages, implicitly casted to long in __mod_zone_page_state(), it becomes something around UINT_MAX. munlock_vma_page() usually called for THP as small pages go though pagevec. Let's make nr_pages signed int. Similar fixes in 6cdb18ad ("mm/vmstat: fix overflow in mod_zone_page_state()") used `long' type, but `int' here is OK for a count of the number of sub-pages in a huge page. Fixes: ff6a6da6 ("mm: accelerate munlock() treatment of THP pages") Signed-off-by:
Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Tested-by:
-
Dan Williams authored
commit e07ecd76 upstream. When btt devices were re-worked to be child devices of regions this routine was overlooked. It mistakenly attempts to_nd_namespace_pmem() or to_nd_namespace_blk() conversions on btt and pfn devices. By luck to date we have happened to be hitting valid memory leading to a uuid miscompare, but a recent change to struct nd_namespace_common causes: BUG: unable to handle kernel NULL pointer dereference at 0000000000000001 IP: [<ffffffff814610dc>] memcmp+0xc/0x40 [..] Call Trace: [<ffffffffa0028631>] is_uuid_busy+0xc1/0x2a0 [libnvdimm] [<ffffffffa0028570>] ? to_nd_blk_region+0x50/0x50 [libnvdimm] [<ffffffff8158c9c0>] device_for_each_child+0x50/0x90 Signed-off-by:
Dan Williams <dan.j.williams@intel.com> Signed-off-by:
-
Naoya Horiguchi authored
commit d96b339f upstream. I saw the following BUG_ON triggered in a testcase where a process calls madvise(MADV_SOFT_OFFLINE) on thps, along with a background process that calls migratepages command repeatedly (doing ping-pong among different NUMA nodes) for the first process: Soft offlining page 0x60000 at 0x700000600000 __get_any_page: 0x60000 free buddy page page:ffffea0001800000 count:0 mapcount:-127 mapping: (null) index:0x1 flags: 0x1fffc0000000000() page dumped because: VM_BUG_ON_PAGE(atomic_read(&page->_count) == 0) ------------[ cut here ]------------ kernel BUG at /src/linux-dev/include/linux/mm.h:342! invalid opcode: 0000 [#1] SMP DEBUG_PAGEALLOC Modules linked in: cfg80211 rfkill crc32c_intel serio_raw virtio_balloon i2c_piix4 virtio_blk virtio_net ata_generic pata_acpi CPU: 3 PID: 3035 Comm: test_alloc_gene Tainted: G O 4.4.0-rc8-v4.4-rc8-160107-1501-00000-rc8+ #74 Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 task: ffff88007c63d5c0 ti: ffff88007c210000 task.ti: ffff88007c210000 RIP: 0010:[<ffffffff8118998c>] [<ffffffff8118998c>] put_page+0x5c/0x60 RSP: 0018:ffff88007c213e00 EFLAGS: 00010246 Call Trace: put_hwpoison_page+0x4e/0x80 soft_offline_page+0x501/0x520 SyS_madvise+0x6bc/0x6f0 entry_SYSCALL_64_fastpath+0x12/0x6a Code: 8b fc ff ff 5b 5d c3 48 89 df e8 b0 fa ff ff 48 89 df 31 f6 e8 c6 7d ff ff 5b 5d c3 48 c7 c6 08 54 a2 81 48 89 df e8 a4 c5 01 00 <0f> 0b 66 90 66 66 66 66 90 55 48 89 e5 41 55 41 54 53 48 8b 47 RIP [<ffffffff8118998c>] put_page+0x5c/0x60 RSP <ffff88007c213e00> The root cause resides in get_any_page() which retries to get a refcount of the page to be soft-offlined. This function calls put_hwpoison_page(), expecting that the target page is putback to LRU list. But it can be also freed to buddy. So the second check need to care about such case. Fixes: af8fae7c ("mm/memory-failure.c: clean up soft_offline_page()") Signed-off-by:
Naoya Horiguchi <n-horiguchi@ah.jp.nec.com> Cc: Sasha Levin <sasha.levin@oracle.com> Cc: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com> Cc: Vlastimil Babka <vbabka@suse.cz> Cc: Jerome Marchand <jmarchan@redhat.com> Cc: Andrea Arcangeli <aarcange@redhat.com> Cc: Hugh Dickins <hughd@google.com> Cc: Dave Hansen <dave.hansen@intel.com> Cc: Mel Gorman <mgorman@suse.de> Cc: Rik van Riel <riel@redhat.com> Cc: Steve Capper <steve.capper@linaro.org> Cc: Johannes Weiner <hannes@cmpxchg.org> Cc: Michal Hocko <mhocko@suse.cz> Cc: Christoph Lameter <cl@linux.com> Cc: David Rientjes <rientjes@google.com> Signed-off-by:
-
Ravi Bangoria authored
commit 3caeaa56 upstream. While recording guest samples in host using perf kvm record, it will populate unprocessable sample error, though samples will be recorded properly. While generating report using perf kvm report, no samples will be processed and same error will populate. We have seen this behaviour with upstream perf(4.4-rc3) on x86 and ppc64 hardware. Reason behind this failure is, when it tries to fetch machine from rb_tree of machines, it fails. As a part of tracing a bug, we figured out that this code was incorrectly refactored in commit 54245fdc ("perf session: Remove wrappers to machines__find"). This patch will change the functionality such that if it can't fetch machine in first trial, it will create one node of machine and add that to rb_tree. So next time when it tries to fetch same machine from rb_tree, it won't fail. Actually it was the case before refactoring of code in aforementioned commit. This patch is generated from acme perf/core branch. Below I've mention an example that demonstrate the behaviour before and after applying patch. Before applying patch: [Note: One needs to run guest before recording data in host] ravi@ravi-bangoria:~$ ./perf kvm record -a Warning: 5903 unprocessable samples recorded. Do you have a KVM guest running and not using 'perf kvm'? [ perf record: Captured and wrote 1.409 MB perf.data.guest (285 samples) ] ravi@ravi-bangoria:~$ ./perf kvm report --stdio Warning: 5903 unprocessable samples recorded. Do you have a KVM guest running and not using 'perf kvm'? # To display the perf.data header info, please use --header/--header-only options. # # Total Lost Samples: 0 # # Samples: 285 of event 'cycles' # Event count (approx.): 88715406 # # Overhead Command Shared Object Symbol # ........ ....... ............. ...... # # (For a higher level overview, try: perf report --sort comm,dso) # After applying patch: ravi@ravi-bangoria:~$ ./perf kvm record -a [ perf record: Captured and wrote 1.188 MB perf.data.guest (17 samples) ] ravi@ravi-bangoria:~$ ./perf kvm report --stdio # To display the perf.data header info, please use --header/--header-only options. # # Total Lost Samples: 0 # # Samples: 17 of event 'cycles' # Event count (approx.): 700746 # # Overhead Command Shared Object Symbol # ........ ....... ................ ...................... # 34.19% :5758 [unknown] [g] 0xffffffff818682ab 22.79% :5758 [unknown] [g] 0xffffffff812dc7f8 22.79% :5758 [unknown] [g] 0xffffffff818650d0 14.83% :5758 [unknown] [g] 0xffffffff8161a1b6 2.49% :5758 [unknown] [g] 0xffffffff818692bf 0.48% :5758 [unknown] [g] 0xffffffff81869253 0.05% :5758 [unknown] [g] 0xffffffff81869250 Signed-off-by:
Ravi Bangoria <ravi.bangoria@linux.vnet.ibm.com> Cc: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com> Fixes: 54245fdc ("perf session: Remove wrappers to machines__find") Link: http://lkml.kernel.org/r/1449471302-11283-1-git-send-email-ravi.bangoria@linux.vnet.ibm.comSigned-off-by:
Arnaldo Carvalho de Melo <acme@redhat.com> Signed-off-by:
-
Greg Kurz authored
commit b4d7f161 upstream. The get and set operations got exchanged by mistake when moving the code from book3s.c to powerpc.c. Fixes: 3840edc8Signed-off-by:
Greg Kurz <gkurz@linux.vnet.ibm.com> Signed-off-by:
Paul Mackerras <paulus@samba.org> Signed-off-by:
-
Thomas Huth authored
commit 760a7364 upstream. In the old DABR register, the BT (Breakpoint Translation) bit is bit number 61. In the new DAWRX register, the WT (Watchpoint Translation) bit is bit number 59. So to move the DABR-BT bit into the position of the DAWRX-WT bit, it has to be shifted by two, not only by one. This fixes hardware watchpoints in gdb of older guests that only use the H_SET_DABR/X interface instead of the new H_SET_MODE interface. Signed-off-by:
Thomas Huth <thuth@redhat.com> Reviewed-by:
Laurent Vivier <lvivier@redhat.com> Reviewed-by:
David Gibson <david@gibson.dropbear.id.au> Signed-off-by:
-
Andre Przywara authored
commit b3aff6cc upstream. Commit 4b4b4512 ("arm/arm64: KVM: Rework the arch timer to use level-triggered semantics") brought the virtual architected timer closer to the VGIC. There is one occasion were we don't properly check for the VGIC actually having been initialized before, but instead go on to check the active state of some IRQ number. If userland hasn't instantiated a virtual GIC, we end up with a kernel NULL pointer dereference: ========= Unable to handle kernel NULL pointer dereference at virtual address 00000000 pgd = ffffffc9745c5000 [00000000] *pgd=00000009f631e003, *pud=00000009f631e003, *pmd=0000000000000000 Internal error: Oops: 96000006 [#2] PREEMPT SMP Modules linked in: CPU: 0 PID: 2144 Comm: kvm_simplest-ar Tainted: G D 4.5.0-rc2+ #1300 Hardware name: ARM Juno development board (r1) (DT) task: ffffffc976da8000 ti: ffffffc976e28000 task.ti: ffffffc976e28000 PC is at vgic_bitmap_get_irq_val+0x78/0x90 LR is at kvm_vgic_map_is_active+0xac/0xc8 pc : [<ffffffc0000b7e28>] lr : [<ffffffc0000b972c>] pstate: 20000145 .... ========= Fix this by bailing out early of kvm_timer_flush_hwstate() if we don't have a VGIC at all. Reported-by:
Cosmin Gorgovan <cosmin@linux-geek.org> Acked-by:
Marc Zyngier <marc.zyngier@arm.com> Signed-off-by:
Andre Przywara <andre.przywara@arm.com> Signed-off-by:
-
Marek Szyprowski authored
commit 722ec35f upstream. This patch ensures that devices, which got registered before arch_initcall will be handled correctly by IOMMU-based DMA-mapping code. Fixes: 13b8629f ("arm64: Add IOMMU dma_ops") Acked-by:
Robin Murphy <robin.murphy@arm.com> Signed-off-by:
Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by:
Will Deacon <will.deacon@arm.com> Signed-off-by:
-
Tony Lindgren authored
commit 4da597d1 upstream. We don't want to write to .text so let's move ppa_zero_params and ppa_por_params to .data and access them via pointers. Note that I have not been able to test as we I don't have a HS omap4 to test with. The code has been changed in similar way as for omap3 though. Cc: Kees Cook <keescook@chromium.org> Cc: Laura Abbott <labbott@redhat.com> Cc: Nishanth Menon <nm@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com> Cc: Russell King <linux@arm.linux.org.uk> Cc: Tero Kristo <t-kristo@ti.com> Acked-by:
Nicolas Pitre <nico@linaro.org> Fixes: 1e6b4811 ("ARM: mm: allow non-text sections to be non-executable") Signed-off-by:
Tony Lindgren <tony@atomide.com> Signed-off-by:
-
Tony Lindgren authored
commit a5311d4d upstream. We don't want to write to .text and we can move save_secure_ram_context into .data as it all gets copied into SRAM anyways. Cc: Kees Cook <keescook@chromium.org> Cc: Laura Abbott <labbott@redhat.com> Cc: Nishanth Menon <nm@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com> Cc: Russell King <linux@arm.linux.org.uk> Cc: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com> Cc: Tero Kristo <t-kristo@ti.com> Acked-by:
-
Tony Lindgren authored
commit eeaf9646 upstream. We don't want to write to .text section. Let's move l2dis_3630 to .data and access it via a pointer. For calculating the offset, let's optimize out the add and do it in ldr/str as suggested by Nicolas Pitre <nicolas.pitre@linaro.org>. Cc: Kees Cook <keescook@chromium.org> Cc: Laura Abbott <labbott@redhat.com> Cc: Nishanth Menon <nm@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com> Cc: Russell King <linux@arm.linux.org.uk> Cc: Tero Kristo <t-kristo@ti.com> Acked-by:
-
Tony Lindgren authored
commit 0a0b1327 upstream. We don't want to write to .text, so let's move l2_inv_api_params to .data and access it via a pointer. Cc: Kees Cook <keescook@chromium.org> Cc: Laura Abbott <labbott@redhat.com> Cc: Nishanth Menon <nm@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com> Cc: Russell King <linux@arm.linux.org.uk> Cc: Tero Kristo <t-kristo@ti.com> Acked-by:
-
Tony Lindgren authored
commit d9db5910 upstream. We don't want to be writing to .text so it can be set rodata. Fix error "Unable to handle kernel paging request at virtual address c012396c" in wait_dll_lock_timed if CONFIG_DEBUG_RODATA is selected. As these counters are for debugging only and unused, we can just remove them. Cc: Kees Cook <keescook@chromium.org> Cc: Laura Abbott <labbott@redhat.com> Cc: Nishanth Menon <nm@ti.com> Cc: Richard Woodruff <r-woodruff2@ti.com> Cc: Russell King <linux@arm.linux.org.uk> Cc: Tero Kristo <t-kristo@ti.com> Acked-by:
-
Wenyou Yang authored
commit aae6b18f upstream. On SAMA5D4EK board, the Ethernet doesn't work after resuming from the suspend state. Signed-off-by:
Wenyou Yang <wenyou.yang@atmel.com> [nicolas.ferre@atmel.com: adapt to newer kernel] Fixes: 38153a01 ("ARM: at91/dt: sama5d4: add dts for sama5d4 xplained board") Signed-off-by:
Nicolas Ferre <nicolas.ferre@atmel.com> Signed-off-by:
-
Nicolas Ferre authored
commit e873cc02 upstream. For phy0 KSZ8081, the type of GPIO IRQ should be "level low" instead of "edge falling". Signed-off-by:
-
Mohamed Jamsheeth Hajanajubudeen authored
commit 929e883f upstream. Change instance id of DBGU to 45. Signed-off-by:
Mohamed Jamsheeth Hajanajubudeen <mohamedjamsheeth.hajanajubudeen@atmel.com> Fixes: 7c661394 ("ARM: at91: dt: add device tree file for SAMA5D4 SoC") Signed-off-by:
-
Alexandre Belloni authored
commit f505dba7 upstream. No interrupt were received from the phy because PIOE 1 may not be properly muxed. It prevented proper link detection, especially since commit 321beec5 ("net: phy: Use interrupts when available in NOLINK state") disables polling. Signed-off-by:
Alexandre Belloni <alexandre.belloni@free-electrons.com> Signed-off-by:
-
H. Nikolaus Schaller authored
commit c08659d4 upstream. tested on OMP5432 EVM Signed-off-by:
H. Nikolaus Schaller <hns@goldelico.com> Signed-off-by:
-
Tony Lindgren authored
commit af756bbc upstream. The palmas PMIC has two control lines that need to be muxed properly for things to work. The sys_nirq pin is used for interrupts, and msecure pin is used for enabling writes to some PMIC registers. Without these pins configured properly things can fail in mysterious ways. For example, we can't update the RTC registers on palmas PMIC unless the msecure pin is configured. And this is probably the reason why we had RTC missing from the omap5 dts file. According to "OMAP5430 ES2.0 Data Manual [Public] VErsion A (Rev. F)" swps052f.pdf, mux mode 1 is for sys_drm_msecure so in theory there's should be no need to configure it as a GPIO pin. However, it seems there are some reliability issues using the msecure mux mode. And the TI trees configure the msecure pin as GPIO out high instead. As the PMIC only cares that the msecure line is high to allow access to the RTC registers, let's use a GPIO hog as suggested by Nishanth Menon <nm@ti.com>. Also the use of the internal pull was considered but supposedly that may not be capable of keeping the line high in a noisy environment. If we ever see high security omap5 products in the mainline tree, those need to skip the msecure pin muxing and ignore setting the GPIO hog. Chances are the related pin mux registers are locked in that case and the msecure pin is managed by whatever software may be running in the ARM TrustZone. Who knows what the original intention of the msecure pin was. Maybe it was supposed to prevent the system time to be set back for some game demo modes to time out? Anyways, it seems that later PMICs like tps659037 have recycled this pin for "powerhold" and devices like beagle-x15 do not need changes to the msecure pin configuration. To avoid further confusion with TWL variant PMICs, beagle-x15 does not have a back-up battery for RTC palmas. Instead the mcp79410 RTC is used with rtc-ds1307 driver. There is a "powerhold" jumper j5 holes near the palmas PMIC, and shorting it seems to power up beagle-x15 automatically. It is unknown if it also has other side effects to the beagle-x15 power up sequence. Signed-off-by:
-
