1. 02 Oct, 2015 9 commits
    • Petr Mladek's avatar
      kprobes: use _do_fork() in samples to make them work again · 54aea454
      Petr Mladek authored
      Commit 3033f14a ("clone: support passing tls argument via C rather
      than pt_regs magic") introduced _do_fork() that allowed to pass @tls
      parameter.
      
      The old do_fork() is defined only for architectures that are not ready
      to use this way and do not define HAVE_COPY_THREAD_TLS.
      
      Let's use _do_fork() in the kprobe examples to make them work again on
      all architectures.
      Signed-off-by: default avatarPetr Mladek <pmladek@suse.com>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Thiago Macieira <thiago.macieira@intel.com>
      Cc: Jiri Kosina <jkosina@suse.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      54aea454
    • Andrew Morton's avatar
      drivers/input/joystick/Kconfig: zhenhua.c needs BITREVERSE · 09a59a9d
      Andrew Morton authored
      It uses bitrev8(), so it must ensure that lib/bitrev.o gets included in
      vmlinux.
      
      Cc: Fengguang Wu <fengguang.wu@gmail.com>
      Cc: yalin wang <yalin.wang2010@gmail.com>
      Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      09a59a9d
    • Greg Thelen's avatar
      memcg: make mem_cgroup_read_stat() unsigned · 484ebb3b
      Greg Thelen authored
      mem_cgroup_read_stat() returns a page count by summing per cpu page
      counters.  The summing is racy wrt.  updates, so a transient negative
      sum is possible.  Callers don't want negative values:
      
       - mem_cgroup_wb_stats() doesn't want negative nr_dirty or nr_writeback.
         This could confuse dirty throttling.
      
       - oom reports and memory.stat shouldn't show confusing negative usage.
      
       - tree_usage() already avoids negatives.
      
      Avoid returning negative page counts from mem_cgroup_read_stat() and
      convert it to unsigned.
      
      [akpm@linux-foundation.org: fix old typo while we're in there]
      Signed-off-by: default avatarGreg Thelen <gthelen@google.com>
      Cc: Johannes Weiner <hannes@cmpxchg.org>
      Acked-by: default avatarMichal Hocko <mhocko@suse.com>
      Cc: <stable@vger.kernel.org>	[4.2+]
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      484ebb3b
    • Greg Thelen's avatar
      memcg: fix dirty page migration · 0610c25d
      Greg Thelen authored
      The problem starts with a file backed dirty page which is charged to a
      memcg.  Then page migration is used to move oldpage to newpage.
      
      Migration:
       - copies the oldpage's data to newpage
       - clears oldpage.PG_dirty
       - sets newpage.PG_dirty
       - uncharges oldpage from memcg
       - charges newpage to memcg
      
      Clearing oldpage.PG_dirty decrements the charged memcg's dirty page
      count.
      
      However, because newpage is not yet charged, setting newpage.PG_dirty
      does not increment the memcg's dirty page count.  After migration
      completes newpage.PG_dirty is eventually cleared, often in
      account_page_cleaned().  At this time newpage is charged to a memcg so
      the memcg's dirty page count is decremented which causes underflow
      because the count was not previously incremented by migration.  This
      underflow causes balance_dirty_pages() to see a very large unsigned
      number of dirty memcg pages which leads to aggressive throttling of
      buffered writes by processes in non root memcg.
      
      This issue:
       - can harm performance of non root memcg buffered writes.
       - can report too small (even negative) values in
         memory.stat[(total_)dirty] counters of all memcg, including the root.
      
      To avoid polluting migrate.c with #ifdef CONFIG_MEMCG checks, introduce
      page_memcg() and set_page_memcg() helpers.
      
      Test:
          0) setup and enter limited memcg
          mkdir /sys/fs/cgroup/test
          echo 1G > /sys/fs/cgroup/test/memory.limit_in_bytes
          echo $$ > /sys/fs/cgroup/test/cgroup.procs
      
          1) buffered writes baseline
          dd if=/dev/zero of=/data/tmp/foo bs=1M count=1k
          sync
          grep ^dirty /sys/fs/cgroup/test/memory.stat
      
          2) buffered writes with compaction antagonist to induce migration
          yes 1 > /proc/sys/vm/compact_memory &
          rm -rf /data/tmp/foo
          dd if=/dev/zero of=/data/tmp/foo bs=1M count=1k
          kill %
          sync
          grep ^dirty /sys/fs/cgroup/test/memory.stat
      
          3) buffered writes without antagonist, should match baseline
          rm -rf /data/tmp/foo
          dd if=/dev/zero of=/data/tmp/foo bs=1M count=1k
          sync
          grep ^dirty /sys/fs/cgroup/test/memory.stat
      
                             (speed, dirty residue)
                   unpatched                       patched
          1) 841 MB/s 0 dirty pages          886 MB/s 0 dirty pages
          2) 611 MB/s -33427456 dirty pages  793 MB/s 0 dirty pages
          3) 114 MB/s -33427456 dirty pages  891 MB/s 0 dirty pages
      
          Notice that unpatched baseline performance (1) fell after
          migration (3): 841 -> 114 MB/s.  In the patched kernel, post
          migration performance matches baseline.
      
      Fixes: c4843a75 ("memcg: add per cgroup dirty page accounting")
      Signed-off-by: default avatarGreg Thelen <gthelen@google.com>
      Reported-by: default avatarDave Hansen <dave.hansen@intel.com>
      Acked-by: default avatarMichal Hocko <mhocko@suse.com>
      Acked-by: default avatarJohannes Weiner <hannes@cmpxchg.org>
      Cc: <stable@vger.kernel.org>	[4.2+]
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      0610c25d
    • Ross Zwisler's avatar
      dax: fix NULL pointer in __dax_pmd_fault() · 8346c416
      Ross Zwisler authored
      Commit 46c043ed ("mm: take i_mmap_lock in unmap_mapping_range() for
      DAX") moved some code in __dax_pmd_fault() that was responsible for
      zeroing newly allocated PMD pages.  The new location didn't properly set
      up 'kaddr', so when run this code resulted in a NULL pointer BUG.
      
      Fix this by getting the correct 'kaddr' via bdev_direct_access().
      Signed-off-by: default avatarRoss Zwisler <ross.zwisler@linux.intel.com>
      Reported-by: default avatarDan Williams <dan.j.williams@intel.com>
      Reviewed-by: default avatarDan Williams <dan.j.williams@intel.com>
      Cc: Alexander Viro <viro@zeniv.linux.org.uk>
      Cc: Matthew Wilcox <willy@linux.intel.com>
      Cc: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
      Cc: Dave Chinner <david@fromorbit.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      8346c416
    • Mel Gorman's avatar
      mm: hugetlbfs: skip shared VMAs when unmapping private pages to satisfy a fault · 2f84a899
      Mel Gorman authored
      SunDong reported the following on
      
        https://bugzilla.kernel.org/show_bug.cgi?id=103841
      
      	I think I find a linux bug, I have the test cases is constructed. I
      	can stable recurring problems in fedora22(4.0.4) kernel version,
      	arch for x86_64.  I construct transparent huge page, when the parent
      	and child process with MAP_SHARE, MAP_PRIVATE way to access the same
      	huge page area, it has the opportunity to lead to huge page copy on
      	write failure, and then it will munmap the child corresponding mmap
      	area, but then the child mmap area with VM_MAYSHARE attributes, child
      	process munmap this area can trigger VM_BUG_ON in set_vma_resv_flags
      	functions (vma - > vm_flags & VM_MAYSHARE).
      
      There were a number of problems with the report (e.g.  it's hugetlbfs that
      triggers this, not transparent huge pages) but it was fundamentally
      correct in that a VM_BUG_ON in set_vma_resv_flags() can be triggered that
      looks like this
      
      	 vma ffff8804651fd0d0 start 00007fc474e00000 end 00007fc475e00000
      	 next ffff8804651fd018 prev ffff8804651fd188 mm ffff88046b1b1800
      	 prot 8000000000000027 anon_vma           (null) vm_ops ffffffff8182a7a0
      	 pgoff 0 file ffff88106bdb9800 private_data           (null)
      	 flags: 0x84400fb(read|write|shared|mayread|maywrite|mayexec|mayshare|dontexpand|hugetlb)
      	 ------------
      	 kernel BUG at mm/hugetlb.c:462!
      	 SMP
      	 Modules linked in: xt_pkttype xt_LOG xt_limit [..]
      	 CPU: 38 PID: 26839 Comm: map Not tainted 4.0.4-default #1
      	 Hardware name: Dell Inc. PowerEdge R810/0TT6JF, BIOS 2.7.4 04/26/2012
      	 set_vma_resv_flags+0x2d/0x30
      
      The VM_BUG_ON is correct because private and shared mappings have
      different reservation accounting but the warning clearly shows that the
      VMA is shared.
      
      When a private COW fails to allocate a new page then only the process
      that created the VMA gets the page -- all the children unmap the page.
      If the children access that data in the future then they get killed.
      
      The problem is that the same file is mapped shared and private.  During
      the COW, the allocation fails, the VMAs are traversed to unmap the other
      private pages but a shared VMA is found and the bug is triggered.  This
      patch identifies such VMAs and skips them.
      Signed-off-by: default avatarMel Gorman <mgorman@techsingularity.net>
      Reported-by: default avatarSunDong <sund_sky@126.com>
      Reviewed-by: default avatarMichal Hocko <mhocko@suse.com>
      Cc: Andrea Arcangeli <aarcange@redhat.com>
      Cc: Hugh Dickins <hughd@google.com>
      Cc: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
      Cc: David Rientjes <rientjes@google.com>
      Reviewed-by: default avatarNaoya Horiguchi <n-horiguchi@ah.jp.nec.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      2f84a899
    • Joonsoo Kim's avatar
      mm/slab: fix unexpected index mapping result of kmalloc_size(INDEX_NODE+1) · 03a2d2a3
      Joonsoo Kim authored
      Commit description is copied from the original post of this bug:
      
        http://comments.gmane.org/gmane.linux.kernel.mm/135349
      
      Kernels after v3.9 use kmalloc_size(INDEX_NODE + 1) to get the next
      larger cache size than the size index INDEX_NODE mapping.  In kernels
      3.9 and earlier we used malloc_sizes[INDEX_L3 + 1].cs_size.
      
      However, sometimes we can't get the right output we expected via
      kmalloc_size(INDEX_NODE + 1), causing a BUG().
      
      The mapping table in the latest kernel is like:
          index = {0,   1,  2 ,  3,  4,   5,   6,   n}
           size = {0,   96, 192, 8, 16,  32,  64,   2^n}
      The mapping table before 3.10 is like this:
          index = {0 , 1 , 2,   3,  4 ,  5 ,  6,   n}
          size  = {32, 64, 96, 128, 192, 256, 512, 2^(n+3)}
      
      The problem on my mips64 machine is as follows:
      
      (1) When configured DEBUG_SLAB && DEBUG_PAGEALLOC && DEBUG_LOCK_ALLOC
          && DEBUG_SPINLOCK, the sizeof(struct kmem_cache_node) will be "150",
          and the macro INDEX_NODE turns out to be "2": #define INDEX_NODE
          kmalloc_index(sizeof(struct kmem_cache_node))
      
      (2) Then the result of kmalloc_size(INDEX_NODE + 1) is 8.
      
      (3) Then "if(size >= kmalloc_size(INDEX_NODE + 1)" will lead to "size
          = PAGE_SIZE".
      
      (4) Then "if ((size >= (PAGE_SIZE >> 3))" test will be satisfied and
          "flags |= CFLGS_OFF_SLAB" will be covered.
      
      (5) if (flags & CFLGS_OFF_SLAB)" test will be satisfied and will go to
          "cachep->slabp_cache = kmalloc_slab(slab_size, 0u)", and the result
          here may be NULL while kernel bootup.
      
      (6) Finally,"BUG_ON(ZERO_OR_NULL_PTR(cachep->slabp_cache));" causes the
          BUG info as the following shows (may be only mips64 has this problem):
      
      This patch fixes the problem of kmalloc_size(INDEX_NODE + 1) and removes
      the BUG by adding 'size >= 256' check to guarantee that all necessary
      small sized slabs are initialized regardless sequence of slab size in
      mapping table.
      
      Fixes: e3366016 ("slab: Use common kmalloc_index/kmalloc_size...")
      Signed-off-by: default avatarJoonsoo Kim <iamjoonsoo.kim@lge.com>
      Reported-by: default avatarLiuhailong <liu.hailong6@zte.com.cn>
      Acked-by: default avatarChristoph Lameter <cl@linux.com>
      Cc: Pekka Enberg <penberg@kernel.org>
      Cc: David Rientjes <rientjes@google.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      03a2d2a3
    • Andre Przywara's avatar
      userfaultfd: remove kernel header include from uapi header · 9ff42d10
      Andre Przywara authored
      As include/uapi/linux/userfaultfd.h is a user visible header file, it
      should not include kernel-exclusive header files.
      
      So trying to build the userfaultfd test program from the selftests
      directory fails, since it contains a reference to linux/compiler.h.  As
      it turns out, that header is not really needed there, so we can simply
      remove it to fix that issue.
      Signed-off-by: default avatarAndre Przywara <andre.przywara@arm.com>
      Cc: Andrea Arcangeli <aarcange@redhat.com>
      Cc: Shuah Khan <shuahkh@osg.samsung.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      9ff42d10
    • Andrey Ryabinin's avatar
      arch/x86/include/asm/efi.h: fix build failure · a523841e
      Andrey Ryabinin authored
      With KMEMCHECK=y, KASAN=n:
      
        arch/x86/platform/efi/efi.c:673:3: error: implicit declaration of function `memcpy' [-Werror=implicit-function-declaration]
        arch/x86/platform/efi/efi_64.c:139:2: error: implicit declaration of function `memcpy' [-Werror=implicit-function-declaration]
        arch/x86/include/asm/desc.h:121:2: error: implicit declaration of function `memcpy' [-Werror=implicit-function-declaration]
      
      Don't #undef memcpy if KASAN=n.
      
      Fixes: 769a8089 ("x86, efi, kasan: #undef memset/memcpy/memmove per arch")
      Signed-off-by: default avatarAndrey Ryabinin <ryabinin.a.a@gmail.com>
      Reported-by: default avatarIngo Molnar <mingo@kernel.org>
      Reported-by: default avatarSedat Dilek <sedat.dilek@gmail.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      a523841e
  2. 01 Oct, 2015 2 commits
  3. 30 Sep, 2015 4 commits
  4. 29 Sep, 2015 4 commits
    • shengyong's avatar
      UBI: return ENOSPC if no enough space available · 7c7feb2e
      shengyong authored
      UBI: attaching mtd1 to ubi0
      UBI: scanning is finished
      UBI error: init_volumes: not enough PEBs, required 706, available 686
      UBI error: ubi_wl_init: no enough physical eraseblocks (-20, need 1)
      UBI error: ubi_attach_mtd_dev: failed to attach mtd1, error -12 <= NOT ENOMEM
      UBI error: ubi_init: cannot attach mtd1
      
      If available PEBs are not enough when initializing volumes, return -ENOSPC
      directly. If available PEBs are not enough when initializing WL, return
      -ENOSPC instead of -ENOMEM.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarSheng Yong <shengyong1@huawei.com>
      Signed-off-by: default avatarRichard Weinberger <richard@nod.at>
      Reviewed-by: default avatarDavid Gstir <david@sigma-star.at>
      7c7feb2e
    • Richard Weinberger's avatar
      UBI: Validate data_size · 281fda27
      Richard Weinberger authored
      Make sure that data_size is less than LEB size.
      Otherwise a handcrafted UBI image is able to trigger
      an out of bounds memory access in ubi_compare_lebs().
      
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarRichard Weinberger <richard@nod.at>
      Reviewed-by: default avatarDavid Gstir <david@sigma-star.at>
      281fda27
    • Richard Weinberger's avatar
      UBIFS: Kill unneeded locking in ubifs_init_security · cf6f54e3
      Richard Weinberger authored
      Fixes the following lockdep splat:
      [    1.244527] =============================================
      [    1.245193] [ INFO: possible recursive locking detected ]
      [    1.245193] 4.2.0-rc1+ #37 Not tainted
      [    1.245193] ---------------------------------------------
      [    1.245193] cp/742 is trying to acquire lock:
      [    1.245193]  (&sb->s_type->i_mutex_key#9){+.+.+.}, at: [<ffffffff812b3f69>] ubifs_init_security+0x29/0xb0
      [    1.245193]
      [    1.245193] but task is already holding lock:
      [    1.245193]  (&sb->s_type->i_mutex_key#9){+.+.+.}, at: [<ffffffff81198e7f>] path_openat+0x3af/0x1280
      [    1.245193]
      [    1.245193] other info that might help us debug this:
      [    1.245193]  Possible unsafe locking scenario:
      [    1.245193]
      [    1.245193]        CPU0
      [    1.245193]        ----
      [    1.245193]   lock(&sb->s_type->i_mutex_key#9);
      [    1.245193]   lock(&sb->s_type->i_mutex_key#9);
      [    1.245193]
      [    1.245193]  *** DEADLOCK ***
      [    1.245193]
      [    1.245193]  May be due to missing lock nesting notation
      [    1.245193]
      [    1.245193] 2 locks held by cp/742:
      [    1.245193]  #0:  (sb_writers#5){.+.+.+}, at: [<ffffffff811ad37f>] mnt_want_write+0x1f/0x50
      [    1.245193]  #1:  (&sb->s_type->i_mutex_key#9){+.+.+.}, at: [<ffffffff81198e7f>] path_openat+0x3af/0x1280
      [    1.245193]
      [    1.245193] stack backtrace:
      [    1.245193] CPU: 2 PID: 742 Comm: cp Not tainted 4.2.0-rc1+ #37
      [    1.245193] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.7.5-0-ge51488c-20140816_022509-build35 04/01/2014
      [    1.245193]  ffffffff8252d530 ffff88007b023a38 ffffffff814f6f49 ffffffff810b56c5
      [    1.245193]  ffff88007c30cc80 ffff88007b023af8 ffffffff810a150d ffff88007b023a68
      [    1.245193]  000000008101302a ffff880000000000 00000008f447e23f ffffffff8252d500
      [    1.245193] Call Trace:
      [    1.245193]  [<ffffffff814f6f49>] dump_stack+0x4c/0x65
      [    1.245193]  [<ffffffff810b56c5>] ? console_unlock+0x1c5/0x510
      [    1.245193]  [<ffffffff810a150d>] __lock_acquire+0x1a6d/0x1ea0
      [    1.245193]  [<ffffffff8109fa78>] ? __lock_is_held+0x58/0x80
      [    1.245193]  [<ffffffff810a1a93>] lock_acquire+0xd3/0x270
      [    1.245193]  [<ffffffff812b3f69>] ? ubifs_init_security+0x29/0xb0
      [    1.245193]  [<ffffffff814fc83b>] mutex_lock_nested+0x6b/0x3a0
      [    1.245193]  [<ffffffff812b3f69>] ? ubifs_init_security+0x29/0xb0
      [    1.245193]  [<ffffffff812b3f69>] ? ubifs_init_security+0x29/0xb0
      [    1.245193]  [<ffffffff812b3f69>] ubifs_init_security+0x29/0xb0
      [    1.245193]  [<ffffffff8128e286>] ubifs_create+0xa6/0x1f0
      [    1.245193]  [<ffffffff81198e7f>] ? path_openat+0x3af/0x1280
      [    1.245193]  [<ffffffff81195d15>] vfs_create+0x95/0xc0
      [    1.245193]  [<ffffffff8119929c>] path_openat+0x7cc/0x1280
      [    1.245193]  [<ffffffff8109ffe3>] ? __lock_acquire+0x543/0x1ea0
      [    1.245193]  [<ffffffff81088f20>] ? sched_clock_cpu+0x90/0xc0
      [    1.245193]  [<ffffffff81088c00>] ? calc_global_load_tick+0x60/0x90
      [    1.245193]  [<ffffffff81088f20>] ? sched_clock_cpu+0x90/0xc0
      [    1.245193]  [<ffffffff811a9cef>] ? __alloc_fd+0xaf/0x180
      [    1.245193]  [<ffffffff8119ac55>] do_filp_open+0x75/0xd0
      [    1.245193]  [<ffffffff814ffd86>] ? _raw_spin_unlock+0x26/0x40
      [    1.245193]  [<ffffffff811a9cef>] ? __alloc_fd+0xaf/0x180
      [    1.245193]  [<ffffffff81189bd9>] do_sys_open+0x129/0x200
      [    1.245193]  [<ffffffff81189cc9>] SyS_open+0x19/0x20
      [    1.245193]  [<ffffffff81500717>] entry_SYSCALL_64_fastpath+0x12/0x6f
      
      While the lockdep splat is a false positive, becuase path_openat holds i_mutex
      of the parent directory and ubifs_init_security() tries to acquire i_mutex
      of a new inode, it reveals that taking i_mutex in ubifs_init_security() is
      in vain because it is only being called in the inode allocation path
      and therefore nobody else can see the inode yet.
      
      Cc: stable@vger.kernel.org # 3.20-
      Reported-and-tested-by: default avatarBoris Brezillon <boris.brezillon@free-electrons.com>
      Reviewed-and-tested-by: default avatarDongsheng Yang <yangds.fnst@cn.fujitsu.com>
      Signed-off-by: default avatarRichard Weinberger <richard@nod.at>
      Signed-off-by: dedekind1@gmail.com
      cf6f54e3
    • James Morris's avatar
      Merge tag 'keys-fixes-20150925' of... · 02667151
      James Morris authored
      Merge tag 'keys-fixes-20150925' of git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs into for-linus
      
      Keyrings fixes from David Howells, for current Linus.
      02667151
  5. 28 Sep, 2015 6 commits
  6. 27 Sep, 2015 15 commits
    • Linus Torvalds's avatar
      Merge branch 'upstream' of git://git.linux-mips.org/pub/scm/ralf/upstream-linus · 097f70b3
      Linus Torvalds authored
      Pull MIPS fixes from Ralf Baechle:
       - Properly setup irq handling for ATH79 platforms
       - Fix bootmem mapstart calculation for contiguous maps
       - Handle little endian and older CPUs correct in BPF
       - Fix console for Fulong 2E systems
       - Handle FTLB correctly on R6 CPUs
       - Fixes for CM, GIC and MAAR support code
      
      * 'upstream' of git://git.linux-mips.org/pub/scm/ralf/upstream-linus:
        MIPS: Initialise MAARs on secondary CPUs
        MIPS: print MAAR configuration during boot
        MIPS: mm: compile maar_init unconditionally
        irqchip: mips-gic: Fix pending & mask reads for MIPS64 with 32b GIC.
        irqchip: mips-gic: Convert CPU numbers to VP IDs.
        MIPS: CM: Provide a function to map from CPU to VP ID.
        MIPS: Fix FTLB detection for R6
        MIPS: cpu-features: Add cpu_has_ftlb
        MIPS: ATH79: Add irq chip ar7240-misc-intc
        MIPS: ATH79: Set missing irq ack handler for ar7100-misc-intc irq chip
        MIPS: BPF: Fix build on pre-R2 little endian CPUs
        MIPS: BPF: Avoid unreachable code on little endian
        MIPS: bootmem: Fix mapstart calculation for contiguous maps
        MIPS: Fix console output for Fulong2e system
      097f70b3
    • Linus Torvalds's avatar
      Merge branch 'perf-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip · e3be4266
      Linus Torvalds authored
      Pull perf fixes from Thomas Gleixner:
       "Another pile of fixes for perf:
      
         - Plug overflows and races in the core code
      
         - Sanitize the flow of the perf syscall so we error out before
           handling the more complex and hard to undo setups
      
         - Improve and fix Broadwell and Skylake hardware support
      
         - Revert a fix which broke what it tried to fix in perf tools
      
         - A couple of smaller fixes in various places of perf tools"
      
      * 'perf-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
        perf tools: Fix copying of /proc/kcore
        perf intel-pt: Remove no_force_psb from documentation
        perf probe: Use existing routine to look for a kernel module by dso->short_name
        perf/x86: Change test_aperfmperf() and test_intel() to static
        tools lib traceevent: Fix string handling in heterogeneous arch environments
        perf record: Avoid infinite loop at buildid processing with no samples
        perf: Fix races in computing the header sizes
        perf: Fix u16 overflows
        perf: Restructure perf syscall point of no return
        perf/x86/intel: Fix Skylake FRONTEND MSR extrareg mask
        perf/x86/intel/pebs: Add PEBS frontend profiling for Skylake
        perf/x86/intel: Make the CYCLE_ACTIVITY.* constraint on Broadwell more specific
        perf tools: Bool functions shouldn't return -1
        tools build: Add test for presence of __get_cpuid() gcc builtin
        tools build: Add test for presence of numa_num_possible_cpus() in libnuma
        Revert "perf symbols: Fix mismatched declarations for elf_getphdrnum"
        perf stat: Fix per-pkg event reporting bug
      e3be4266
    • Linus Torvalds's avatar
      Merge branch 'sched-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip · 73f479b2
      Linus Torvalds authored
      Pull scheduler fix from Thomas Gleixner:
       "A single bug fix for the scheduler to prevent dequeueing of the idle
        task when setting the cpus allowed mask"
      
      * 'sched-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
        sched: Fix crash trying to dequeue/enqueue the idle thread
      73f479b2
    • Linus Torvalds's avatar
      Merge branch 'locking-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip · fc11a9c5
      Linus Torvalds authored
      Pull locking fix from Thomas Gleixner:
       "A single bugfix for lockdep to preserve the pinning counter when
        rebuilding the lock stack"
      
      * 'locking-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
        locking/lockdep: Fix hlock->pin_count reset on lock stack rebuilds
      fc11a9c5
    • Paul Burton's avatar
      MIPS: Initialise MAARs on secondary CPUs · e060f6ed
      Paul Burton authored
      MAARs should be initialised on each CPU (or rather, core) in the system
      in order to achieve consistent behaviour & performance. Previously they
      have only been initialised on the boot CPU which leads to performance
      problems if tasks are later scheduled on a secondary CPU, particularly
      if those tasks make use of unaligned vector accesses where some CPUs
      don't handle any cases in hardware for non-speculative memory regions.
      Fix this by recording the MAAR configuration from the boot CPU and
      applying it to secondary CPUs as part of their bringup.
      Reported-by: default avatarDoug Gilmore <doug.gilmore@imgtec.com>
      Signed-off-by: default avatarPaul Burton <paul.burton@imgtec.com>
      Cc: linux-mips@linux-mips.org
      Cc: Rusty Russell <rusty@rustcorp.com.au>
      Cc: Steven J. Hill <Steven.Hill@imgtec.com>
      Cc: Andrew Bresticker <abrestic@chromium.org>
      Cc: Bjorn Helgaas <bhelgaas@google.com>
      Cc: David Hildenbrand <dahi@linux.vnet.ibm.com>
      Cc: linux-kernel@vger.kernel.org
      Cc: Aaro Koskinen <aaro.koskinen@iki.fi>
      Cc: James Hogan <james.hogan@imgtec.com>
      Cc: Ingo Molnar <mingo@kernel.org>
      Cc: Markos Chandras <markos.chandras@imgtec.com>
      Cc: Hemmo Nieminen <hemmo.nieminen@iki.fi>
      Cc: Alex Smith <alex.smith@imgtec.com>
      Cc: Peter Zijlstra (Intel) <peterz@infradead.org>
      Patchwork: https://patchwork.linux-mips.org/patch/11239/Signed-off-by: default avatarRalf Baechle <ralf@linux-mips.org>
      e060f6ed
    • Paul Burton's avatar
      MIPS: print MAAR configuration during boot · 651ca7f4
      Paul Burton authored
      Verifying that the MAAR configuration is as expected is useful when
      debugging the performance of a system. Print out the memory regions
      configured via MAAR along with their attributes.
      Signed-off-by: default avatarPaul Burton <paul.burton@imgtec.com>
      Cc: linux-mips@linux-mips.org
      Cc: Steven J. Hill <Steven.Hill@imgtec.com>
      Cc: David Hildenbrand <dahi@linux.vnet.ibm.com>
      Cc: linux-kernel@vger.kernel.org
      Cc: Peter Zijlstra (Intel) <peterz@infradead.org>
      Patchwork: https://patchwork.linux-mips.org/patch/11238/Signed-off-by: default avatarRalf Baechle <ralf@linux-mips.org>
      651ca7f4
    • Paul Burton's avatar
      MIPS: mm: compile maar_init unconditionally · def3ab5d
      Paul Burton authored
      maar_init was previously only compiled when CONFIG_NEED_MULTIPLE_NODES
      was not set, which has been fine since it is only called from the
      standard implementation of mem_init which has the same condition. In
      preparation for calling it from the SMP startup code on secondary CPUs,
      move maar_init outside of the #ifndef such that it is always compiled.
      Signed-off-by: default avatarPaul Burton <paul.burton@imgtec.com>
      Cc: Markos Chandras <markos.chandras@imgtec.com>
      Cc: linux-mips@linux-mips.org
      Cc: Steven J. Hill <Steven.Hill@imgtec.com>
      Cc: David Hildenbrand <dahi@linux.vnet.ibm.com>
      Cc: linux-kernel@vger.kernel.org
      Cc: Ingo Molnar <mingo@kernel.org>
      Patchwork: https://patchwork.linux-mips.org/patch/11237/Signed-off-by: default avatarRalf Baechle <ralf@linux-mips.org>
      def3ab5d
    • Paul Burton's avatar
      irqchip: mips-gic: Fix pending & mask reads for MIPS64 with 32b GIC. · d77d5ac9
      Paul Burton authored
      gic_handle_shared_int reads the GIC interrupt pending & mask registers
      directly into a bitmap, which is defined as an array of unsigned longs.
      The GIC pending registers may be 32 bits wide if the CM is older than
      CM3, regardless of the bit width of the CPU, but for MIPS64 kernels
      the unsigned longs in the bitmap will be 64 bits wide. In this case we
      need to perform 2 x 32 bit reads per 64 bit unsigned long in order to
      avoid missing interrupts.
      Signed-off-by: default avatarPaul Burton <paul.burton@imgtec.com>
      Acked-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Cc: linux-mips@linux-mips.org
      Cc: Marc Zyngier <marc.zyngier@arm.com>
      Cc: Jason Cooper <jason@lakedaemon.net>
      Cc: linux-kernel@vger.kernel.org
      Patchwork: https://patchwork.linux-mips.org/patch/11213/Signed-off-by: default avatarRalf Baechle <ralf@linux-mips.org>
      d77d5ac9
    • Paul Burton's avatar
      irqchip: mips-gic: Convert CPU numbers to VP IDs. · ab41f6c8
      Paul Burton authored
      Make use of the mips_cm_vp_id function to convert from Linux CPU numbers
      to the VP IDs used by hardware, which are not identical in all systems.
      Without doing so we map interrupts to incorrect VP(E)s.
      Signed-off-by: default avatarPaul Burton <paul.burton@imgtec.com>
      Acked-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Cc: linux-mips@linux-mips.org
      Cc: Paul Burton <paul.burton@imgtec.com>
      Cc: Marc Zyngier <marc.zyngier@arm.com>
      Cc: Jason Cooper <jason@lakedaemon.net>
      Cc: linux-kernel@vger.kernel.org
      Patchwork: https://patchwork.linux-mips.org/patch/11212/Signed-off-by: default avatarRalf Baechle <ralf@linux-mips.org>
      ab41f6c8
    • Paul Burton's avatar
      MIPS: CM: Provide a function to map from CPU to VP ID. · 7573b94e
      Paul Burton authored
      The VP ID of a given CPU may not match up with the CPU number used by
      Linux. For example, if the width of the VP part of the VP ID is wider
      than log2(number of VPs per core) and the system has multiple cores then
      this will be the case. Alternatively, if a pre-r6 system implements the
      MT ASE with multiple VPEs per core and Linux is built without support
      for the MT ASE then the numbers won't match up either. Provide a
      function to convert from CPU number to VP ID.
      Signed-off-by: default avatarPaul Burton <paul.burton@imgtec.com>
      Acked-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Cc: linux-mips@linux-mips.org
      Cc: linux-kernel@vger.kernel.org
      Cc: James Hogan <james.hogan@imgtec.com>
      Cc: Markos Chandras <markos.chandras@imgtec.com>
      Patchwork: https://patchwork.linux-mips.org/patch/11211/Signed-off-by: default avatarRalf Baechle <ralf@linux-mips.org>
      7573b94e
    • Linus Torvalds's avatar
      Linux 4.3-rc3 · 9ffecb10
      Linus Torvalds authored
      9ffecb10
    • Linus Torvalds's avatar
      Merge branch 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip · 162e6df4
      Linus Torvalds authored
      Pull x86 fixes from Thomas Gleixner:
       "Two bugfixes from Andy addressing at least some of the subtle NMI
        related wreckage which has been reported by Sasha Levin"
      
      * 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
        x86/nmi/64: Fix a paravirt stack-clobbering bug in the NMI code
        x86/paravirt: Replace the paravirt nop with a bona fide empty function
      162e6df4
    • Linus Torvalds's avatar
      Merge branch 'irq-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip · 5a6bdf06
      Linus Torvalds authored
      Pull irq fix from Thomass Gleixner:
       "A bugfix for the atmel aic5 irq chip driver which caches the wrong
        data and thereby breaking resume"
      
      * 'irq-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
        irqchip/atmel-aic5: Use per chip mask caches in mask/unmask()
      5a6bdf06
    • Linus Torvalds's avatar
      Merge branch 'fixes' of git://ftp.arm.linux.org.uk/~rmk/linux-arm · c905929a
      Linus Torvalds authored
      Pull ARM fixes from Russell King:
       "Just two fixes: wire up the new system calls added during the last
        merge window, and fix another user access site"
      
      * 'fixes' of git://ftp.arm.linux.org.uk/~rmk/linux-arm:
        ARM: alignment: fix alignment handling for uaccess changes
        ARM: wire up new syscalls
      c905929a
    • Linus Torvalds's avatar
      Merge tag 'armsoc-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc · 685b5f1d
      Linus Torvalds authored
      Pull ARM SoC fixes from Olof Johansson:
       "Our first real batch of fixes this release cycle.  Nothing really
        concerning, and diffstat is a bit inflated due to some DT contents
        moving around on STi platforms.
      
        There's a collection of them here:
      
         - A fixup for a build breakage that hits on arm64 allmodconfig in
           QCOM SCM firmware drivers
         - MMC fixes for OMAP that had quite a bit of breakage this merge
           window.
         - Misc build/warning fixes on PXA and OMAP
         - A couple of minor fixes for Beagleboard X15 which is now starting
           to see a few more users in the wild"
      
      * tag 'armsoc-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc: (31 commits)
        ARM: sti: dt: adapt DT to fix probe/bind issues in DRM driver
        ARM: dts: fix omap2+ address translation for pbias
        firmware: qcom: scm: Add function stubs for ARM64
        ARM: dts: am57xx-beagle-x15: use palmas-usb for USB2
        ARM: omap2plus_defconfig: enable GPIO_PCA953X
        ARM: dts: omap5-uevm.dts: fix i2c5 pinctrl offsets
        ARM: OMAP2+: AM43XX: Enable autoidle for clks in am43xx_init_late
        ARM: dts: am57xx-beagle-x15: Update Phy supplies
        ARM: pxa: balloon3: Fix build error
        ARM: dts: Fixup model name for HP t410 dts
        ARM: dts: DRA7: fix a typo in ethernet
        ARM: omap2plus_defconfig: make PCF857x built-in
        ARM: dts: Use ti,pbias compatible string for pbias
        ARM: OMAP5: Cleanup options for SoC only build
        ARM: DRA7: Select missing options for SoC only build
        ARM: OMAP2+: board-generic: Remove stale of_irq macros
        ARM: OMAP4+: PM: erratum is used by OMAP5 and DRA7 as well
        ARM: dts: omap3-igep: Move eth IRQ pinmux to IGEPv2 common dtsi
        ARM: dts: am57xx-beagle-x15: Add wakeup irq for mcp79410
        ARM: dts: am335x-phycore-som: Fix mpu voltage
        ...
      685b5f1d